Fulfilling the promise of tabbed browsing

Some Men See Tabbed Browsing As It Is

Let's face it: tabbed browsing is the greatest thing since sliced bread. It's hard to imagine I used to have to open and juggle a new window for every single page. God bless the Firefox team.

But as groundbreaking as Firefox's original version of tabbed browsing was, the Google Chrome browser has managed to improve it in some pretty impressive ways. To name just a few:

• Tabs are located at the top of the window and are much more aesthetically pleasing.
• You can see tabs move as you drag them to rearrange them, giving you something closer to the experience of moving around regular windows.
• Also, when you drag tabs, they snap handily into place in a swift but smooth motion. Nifty.
• Links opened from one window in a new tab open to the right of that tab, not at the end of the tab row. This stack- rather than queue-oriented ordering makes it much easier to keep track of your tabs.
• Tabs can be dragged out of a group to create a new tab group in a new window.
• Similarly, a floating tab in its own window can be dragged and merged into another tab group.

I See Tabbed Browsing As It Never Was...

But there is still much room for improvement. When you're doing heavy browsing or researching, tabs can become difficult to manage as they crowd together on the top bar. This is particularly problematic if you are browsing for several distinct purposes at once. Breaking tabs off into new windows is possible but not easy. There is no way to save a large collection of tabs except to create a new folder and bookmark them all individually into it, or else to force a browser crash and hope the restore point works when you reopen it later.

Google Chrome, then, is actually too attached to the tab as the primary locus of page organization, and hasn't given enough attention to the usefulness of the window. (The same goes for Firefox, but it's far less functional even than Chrome at the moment.) My proposal is that the window should be understood as a means of organizing related groups of tabs, and tabbed browsing should be accommodated to better support the reorganization of tabs into window groups.

The specific features I would like to see in the next version of Chrome tabbed browsing:

1. The drag controls need to be made less sensitive and jerky. I frequently have the experience of tabs popping out of their windows after I click them, as if I had been dragging them when I was not.

2. A first step toward better tab management would be to permit the tabs to be organized into more than one row. The user should be able to drag the bottom border of the tab row like you can on the Windows Taskbar (or optionally have this happen automatically). Instant alleviation of much tab pain. Imagine if you could easily change this:

Into this (visual approximation, of course):

3. There should be a one-click mechanism for saving and reopening an entire window of tabs. Currently you have to create a new folder and invidually bookmark each tab. An added bonus would be if it stored not just a collection of links (as in URLs) but any session state associated with the open tabs. (Chrome may already have this capacity built-in for recently closed tabs.) This would make the function closer to that of preserving an open window without having to leave it open, which would be useful and interwebs-sanity-friendly.

4. It should be very easy to break off groups of tabs into a new window. This is a big pain to do right now, requiring several clicks to drag off each tab and rejoin it to another window. You should be able to:

• Right-click a tab and select "Break this tab into a new window".
• Right-click a tab and select "Break this and tabs to the right into a new window" (or something more succinct).
• Use Ctrl and Shift to select multiple tabs, and either drag them all at once into a new window, or right-click them as a group and select an option to break them into a new window.
• Have tabs broken off from another window start either maximized or not maximized according to their parent. (Currently all broken-off tabs start off non-maximized because they've been dragged.)

5. Similarly, it should be very easy to merge groups of tabs. You should be able to select a single tab, an entire window, or an arbitrary group of tabs and merge it into another window by dragging or through a right-click option.

..And I ask, why not?

"How to Lose Traffic and Alienate People"

A nice piece outlining one writer's most-hated web UI practices, from intrusive advertising to dumb searches.

(Hat tip: Adam Keiper)

Tennessee Department of Transportation 511

I haven't posted in over a week as I've been moving across the country from Austin, Texas to Washington, DC, and then waiting for the cable company to hook up my internet connection here. The trip itself took considerably longer than I had planned, due in no small part to my being stuck in this without moving more than a few feet for nearly four hours. I called my father to see if he could find out what was going on, and he directed me to the Tennessee Department of Transportation's 511 travel conditions service.

Speech Recognition
The service was terribly designed. First of all, it often could not recognize my speech. I would say in a clear voice, "Interstate 40 East", and it would say, "Sure, where do you want weather conditions?" Then there was no way for me to tell it it had misunderstood and I wanted to go back to traffic conditions. I had to just hang up and try again.

When I could get it to recognize the correct highway, it asked me which region of the highway I wanted conditions for: near Memphis, between Memphis and Nashville, near Nashville, or between Nashville and Knoxville. It didn't specify the boundaries between "near" and "between", and when I guessed wrong, I had to start over. You would think they could make rich use of speech recognition for such a program with such well-defined parameters: you specify a single route, or a single intersection, and it tells you any and all conditions in that area. Even something where they split the state into a series of regions and played regularly updated human-recorded voice messages for each one would have been far more useful.

Non-epochal Date Displays

The 511 line is poorly designed in general, but one particular problem is all too common in other systems. When I finally did get to a list of traffic conditions, they were listed in a format like this: "First incident [pause] reported July [pause] Seventh [pause] Two thousand nine [pause] Eight O'clock P.M. [pause] I-40, all lanes closed in both directions, at [pause] Exit 132 [pause] will clear at [pause] July [pause] Seventh [pause] Two thousand nine [pause] Eleven O'Clock P.M."

This system uses the ridiculous default assumption that the information you're listening to might be from some arbitrary time in which not only the month and date but the year are relevant. This assumption ought to be questioned in any new system today, but particularly for a system whose entire purpose is to provide up-to-the-minute information, it is absurd. There is no reason for this system to report any more information than the times at which the incident was reported and is expected to be cleared.

This is one of the areas where Facebook and Gmail are really ahead of the game. They avoid the problem of too much information by displaying dates in a current-time-aware mode. Dates from today display as "xx minutes ago" and after a while as "xx:xx PM". Dates from a few days ago display the month and day but not the time. Only when more than a year has passed is the year displayed. Date formats that assume they are not being rendered at some arbitrary time are incredibly easy to program, and should be a basic principle for UIs meant to display any sort of regularly updated information.

Forbes slide show

I intend for this blog to have roughly two types of posts: rather long ones in which I really detail design principles through some particular example; and shorter ones where I just briefly describe a particular feature that works well or poorly. One of my friends, upon seeing my new blog, told me, "I'm not going to lie to you, Ari, this is the longest blog post ever written." So today I think I'll do one of those shorter (or at least, more digestible) types of posts.

Happy Fourth of July, folks! In honor of our country's economic situation, today's topic is about the failure of the wealth-creating industry. Specifically, their failure to make good websites.

I'm talking specifically about the Forbes slide show feature (example). Forbes, like many other journalism sites, is in love with slide shows. But they've managed to create just about the worst slide show feature I've ever seen on an allegedly non-amateur website. Rather than forming a narrative about this, I'm just going to list all of the problems with it that I can think of in bullet-point form:

· Slide shows are an unnecessary feature in the first place. Unless you're only displaying a series of pictures with minimal accompanying text that forms some sort of sequential narrative, the format has no purpose. What Forbes displays as slide shows are all essentially text lists accompanied by illustrations. A single page should suffice for these, or at least a format where 5-10 frames are placed on each page.

· Because slides have to be viewed in sequence, they introduce an unnecessary burden on the user. Random-access slide shows are an exception, but neither Forbes nor many other sites do this.

· The Forbes slide show automatically forwards to the next frame. The only other slide show I can think of that does this is PowerPoint, and that's only if you explicitly tell it to.

· Not only does the slide show automatically forward, but the time it stays on each frame is around ten seconds, often not enough to read the text even for fast readers.

· The show allows you to stop it, but as soon as you manually forward to the next slide, the automatic feature resumes. Failure to remember when a user changes a setting is a big problem.

· There are manual controls for going forward and back, but, as noted, they do not override the automatic feature.

· Furthermore, on the first slide, only the 'next' button is displayed, and it looks exactly like the 'play' button on most music players. Along with the 'stop' button, these look like 'stop' and 'play' buttons. Typically when a computer feature has manual forward/backward buttons, the arrows are either double-headed, tailed, angled, or otherwise differentiated from the common isosceles triangle of the 'play' button.

· Yes, there is a speed adjustment control, but it's pointless. Why not simply allow the user to manully forward when they are done with a slide? Unless all of the slides take almost exactly the same amount of time to read, you will either miss content or be waiting for a while for the next one to load.

· When the next slide is loaded, an entire new page loads. This is a perfect example of when AJAX should be used to allow the next frame to display without reloading the entire page. Part of the purpose of a slide show is to be able to move through it quickly when you're done with a slide. The load time should and could be a tenth of a second or less. (Many web slide shows use Flash. I think this is an extraneous use of the plugin, but it works as long as it is not so graphics-heavy that it impedes rapidly moving to the next slide.)

· Consistent with the slide show's general principle of unnecessarily taking control from the user, the middle button-click does not work on the manual forward/backward links. The middle-button click should open a link in a new tab or window, but Forbes has unnecessarily used Javascript to implement the links instead of hard-coding them into the HTML. (The Javascript link implementation could still be set up to work with middle-clicks, but almost no developers bother with this, and Forbes is no exception.) What you end up getting is the button being clicked as normal, plus a new window or tab opening with a Javascript command as a URL, that the browser doesn't know what to do with. Google Chrome, however, brilliantly designed their browser to handle such links, although there are some cases where it doesn't work.

· The slide show starts automatically. When you open it up, you had better be ready to read it. This is not good news for users such as myself, who open up many links and often don't start reading them right away. This also largely prevents you from sending someone a link to an individual slide.

The bottom line is this is a poor implementation of an antiquated feature that should not be used on the type of content it is displaying. Plain ol' HTML displaying several elements at once and allowing you to navigate at your will would be far superior. If they want to keep the slideshow, it should be implemented with AJAX or Flash so that you do not have to load a new page for each frame. And it should be embedded or included in the articles that link to it, rather than standing alone as it does now.

The only reason I can think of for Forbes to have this format of slideshow is to increase their ad revenue by forcing the user to load many pages to view a small amount of content. This isn't a particularly smart idea, because it's just as likely to annoy users (such as myself) who, after having viewed unnecessarily many pages, will just decide not to return to the site.

Blog posting will be scant for the next several days as I move from Austin, Texas to Washington, DC.

Huffington Post and the "Quick" Read

Burdensome User-Friendliness and Inconvenient Convenience

Once this blog is really on its feet, I will only be updating every two or three days. But I'm going to be posting a bit more frequently at first, because right now it needs a little more of what's known as "content".

It's something of a truism now (my last post notwithstanding) that our world is moving at an ever-faster pace and our attention is demanded by more and more sources. Nicholas Carr writes:

As people’s minds become attuned to the crazy quilt of Internet media, traditional media have to adapt to the audience’s new expectations. Television programs add text crawls and pop-up ads, and magazines and newspapers shorten their articles, introduce capsule summaries, and crowd their pages with easy-to-browse info-snippets. When, in March of this year, The New York Times decided to devote the second and third pages of every edition to article abstracts, its design director, Tom Bodkin, explained that the “shortcuts” would give harried readers a quick “taste” of the day’s news, sparing them the “less efficient” method of actually turning the pages and reading the articles.

This is not a particularly heartening trend (to be addressed later), but there are at least better and worse ways of doing this from a design perspective. There is a trend in software design, beginning at the start of this decade and peaking with the Web 2.0 craze, of making interfaces that are supposed to be very warm, inviting, user-friendly, and convenient. I suspect this is motivated by developers watching too many high-tech and futuristic movies and TV shows in which all interaction with computers takes the form of big flashing red warning signs, slick-sounding beeps, and large single buttons that do things like launch nuclear wars. (See: the Season 4 premiere of 24, in which a "hacker" is sitting at his computer watching lines of black-and-white text and code whizz by, Matrix-style, when a flashing red box pops up on his screen, and he calls his friend at the Counterterrorist Unit and says, "There's been a corruption on the internet!" Oh, sure.)

Examples of this in real life include Windows ME and XP, and just about anything made by Yahoo. What are supposed to be friendly and easy interfaces end up having two predominant features. The first is that they are ridiculously graphics-laden without being particularly attractive, so that, despite the constant increase in computer speeds, you often get the feeling that computers are far slower than they used to be. And the second is that the new interfaces are so good at thinking they know you what you want to do that they can't listen when you try to tell them what you really want.

Huffington Post and the "Quick" Read

The Huffington Post manages to combine the worst of all these trends: "easy-to-browse" "info-snippets" that are graphics-laden and obstruct you from actually reading the article. For example, if you visit the site today and look under "Most Popular on HuffPost", you will see this picture and headline:

"Say, that sounds enlightening," you think to yourself. You click the link, but instead of the riveting piece of prose you're expecting, you see:

Some may find this a convenience, but I have a hard time believing that this is really meant as a convenience or seen as such by many people. First of all, the preview itself is not a condensed piece of content. It only shortens the article, but still has a great deal of other content, including several links to other articles, and an ad larger than the snippet itself. The purpose is obviously to encourage rapid browsing and increase ad revenue.

But the aspect of the Quick Read that makes it all but pointless is that this "preview" itself takes a few seconds to load -- not even noticeably faster than loading an entire new page. The preview is simply too content-laden. This becomes more clear if you notice what happens in the few seconds after you click a post: the page grays, and a box appears saying, "Your request is being processed." That request is actually an entire new page being requested from the server, processed by the browser, and loaded onto your screen, without opening a new window. The reason there is no noticeable difference in the time involved between the Quick Read and just opening the article itself is that there really is no significant difference as far as the amount of network traffic and processing involved.

What a Useful Preview Might Look Like

If you buy the idea that previews really are a good idea, it seems that there is one basic principle that would make them useful: dramatically shortening the amount of time you have to spend absorbing new content. A major facet of this is making it much faster to access that content. Loading an entire new tab with a new article can take 5-20 seconds. It would be nice if you could first browse a preview that takes substantially less time to load -- say, a fraction of a second.

The key here is, first, to make the preview actually be condensed, meaning it should just be a short snippet of the article along with a link to continue on to the full version. Most of the time involved with loading new pages (and therefore also the Quick Read) is not in fetching the data from the website, but in processing it into something visual and interactive. This is why AJAX has become the cornerstone of Web 2.0 technology: it can take a page that is already loaded, fetch some new data, and use that to invoke minor changes on a page that has already been rendered. The most time-consuming component of accessing new information is removed. There are numerous other web apps suffering from the same problem. The lesson to designers: don't use Javascript to alter page structure that has been rendered -- just alter content, and only what has actually changed.

But in the case of the HuffPost QuickRead and similar features on other sites, even the extra fetching stage is unnecessary. Unless the data you're displaying will increase the page size by several times, or unless it might have changed between the time the user loads the page and the time they access to scripted feature, all of the data can be included in the page itself and simply hidden. This is actually remarkably straightforward: the previews can be put in a hidden element, which the "Quick Read" button then displays. This can occur in just a few milliseconds, or the designer can add snazzy effects like having it fade in over a few tenths of a second, without having to worry about the effect being jerky. I make liberal use of both of these principles in my own web projects.

Making Convenience Convenient

The other crucial flaw with the HuffPost Quick Read feature is that it intrudes on normal use of the site. The scenario that the designers should first have in mind is how the site would work without this feature, and then aim to make it so that the user can use the new feature without having to think about it, but so that they can still use the old functionality easily if they want to.

There are two reasons the current HuffPost layout violates this principle. The most significant is that it is not clear without some deliberate poking around as to which links will result in a "Quick Read" and which will take you to a new page with a full article. It seems, after clicking around a bit, that only the "Most Popular on HuffPost" links result in a Quick Read. Other links may or may not provide a separate Quick Read option below the main link. The problem with this is that there is not a sharp stylistic or functional distinction between "Most Popular" links and the myriad other types of article links on the main page. Here are nine of the different article title/summary/link styles that are to be found on the main page:

And these are only the links to specific articles hosted on their own site; this doesn't include the link styles for the various feeds, aggregates, splash pages, external feeds, and so on featured on the main page. Can you tell just from looking at this what is going to happen when you click each of these types of different links? Can you discern a good reason why the behavior should differ among them? They should either be the same by default, or clearly differentiated if there is to be some functional difference between them.

It would seem sensible enough for all of the links to behave in the same way -- opening a new article in a new window -- and then offer the Quick Read option and let the user decide to use it if they want to. This would preserve the principle of allowing for new functionality while not making the interface actually more difficult to use by forcing the user to spend more time thinking about how to use it.

Very closely along these lines, the Quick Read should be made to be compatible with my best friend, the mouse middle click button, which is supposed to force a link to open in a new tab. This is particularly important on a site like HuffPost, where there may be many links on the home page that you want to open without getting navigated away from the home page. Currently, if you middle-click a Quick Read link, you don't get the article opening in a new window. This is only true in Google Chrome, but both Chrome and HuffPost can and should change this.

Summarizing Aggregates

Finally, of course, one might question the desirability and usefulness of the snippet trend to begin with. Although it seems problematic to encourage it, this at least makes sense for a publication like The New York Times: their prose is well worth reading in full, and really shouldn't be summarized if it is to be read at all. But it's true that many people don't have time to read all of it, and arguably there is some value in having a pre-condensed version if people are just going to skim it anyway.

But The Huffington Post is already a site of summarized and largely pirated content anyway (not to mention all of the softcore porn and just flat-out insane content). For example, not only is it laughable that this bulleted list (apparently pound signs are passing for bullets these days) of five items copied from another publication merits an entire article of its own, but the Quick Read version of this article is no shorter than the actual article. This is the exception rather than the rule, but the rule is not so far off. How much time is HuffPost really saving us by offerring us one-paragraph versions of two-paragraph articles? There is perhaps some virtue in the concept of the summary or snippet for very long and very important articles. But must we really introduce hierarchies of summaries and snippets -- links to summaries of abstracts of excerpts of snippets of erstwhile articles?

Give me salacious celebrity gossip and sanctimonious know-nothingness on childhood vaccines, HuffPost, but give it quick!

Gmail: delay send (or, Lucy and Ethel in the Chocolate Factory)

Gmail

For the inaugural non-introductory post, I thought it would be appropriate to discuss an application likely to be used by nearly all readers, and deservedly so: Gmail.

The main purpose of this blog is to offer constructive criticism both of specific applications and of general software trends, so I'll generally only go into what works in applications in order to offer contrast and suggestions for aspects that don't work. To that end, I will forego for now an extensive discussion of Gmail and just say that I think it is one of the finest examples of current software and web design. The interface offers sophisticated functionality, yet manages to be extremely clean and intuitive. And all this with a level of robustness -- both cross-browser compatibility and resilience to crashes and bugs -- so remarkable that you take it completely for granted until you use other Web 2.0 apps.

That said, there is always room for improvement (and that aside from a couple bugs that I've noticed and reported to the proper authorities, as any responsible citizen should). In this post I'll consider the one that is particularly important.

Technology Mitigating Technology

In general, I have some worry about the blinding pace of technological progress today. Although there are endless new gadgets and services that give us valuable new abilities, many of these also deprive us of important aspects of living, in ways that can be difficult to recognize in the midst of that enamoration with the new. This is particularly true of many new internet technologies, which give us a level of anxiety at being constantly connected and having our attention demanded and our time obligated by feeds and overflowing inboxes.

However, sometimes technology can be used to mitigate its own ill effects. One of the reasons I switched to Gmail from my clunky old mail client, Eudora, was the prospect of spending less time managing my mail. One way Gmail facilitates this is by making mailboxes optional (giving you a 'filter' option instead). Now when I'm done with a message, instead of having to figure out which of the hundreds of mailboxes I'd accumulated to put it in, I simply archive it, and can easily find it later with the powerful and intuitive search function.

No feeling is more rare, longed after, and fleetingly blissful for the modern than the serenity of an empty inbox.

Gmail made leaps and bounds in this direction with its archive feature. It made it even better with the currently-experimental "Send & Archive" feature (which you can enable in Labs). When you're done replying to a message, you can send it, archive the thread, and get back to your inbox with the single click of a button:

Glorious.

Delay Send

But there's a problem. Whether I'm responding to many emails at once, or replying to an email as soon as I get it, it's often the case that I simply want to write my response and clear it out of my inbox. But to do that, I have to send it immediately, which will prompt the recipient to think I'm available to keep quickly responding. Typically when I respond to 20 messages, by the time I'm done, I already have new replies to five of them. Unless this is a time-sensitive issue, or a series of short interchanges, I'd often rather write my response and just have it sent some time later.

The advantages are obvious: email stays just as fast and useful as you as you need it to be, but not so fast as to make you into Lucy and Ethel in the Chocolate Factory. When you're reducing the rate at which you send messages, you'll reduce the rate at which you receive them. You can choose to get a message replied to and off of your mind, and know that you won't need to deal with it again until you've decided to. It will allow for the ethic of immediately dealing with messages -- something I strive for simply for the purposes of time-management and sanity -- without the need to further the ever-increasing pace of communication. This would also be useful for concealing from professional contacts the ridiculous hours at which I respond to emails.

So, my proposal to you, dear Gmail, is to add a little "Delay Send" button next to the Send button. It could have a default setting -- say, 6 hours -- and a dropdown menu to offer other delays and specific times.

Why They Haven't Done It (But Should)

I am certainly not the first to suggest this feature. It's been floating around their suggestion forums for a while. There are a number of potential problems, mostly the possibility of being abused for spam and denial of service attacks. The scenario is simple: someone sets up a hundred accounts and queues each to send ten thousand messages to the same recipient at the same time. They then successfully crash the recipient's mail account and server, and do some harm to Gmail's own servers and reputation.

There are similar spamming concerns. And you can imagine some more bizarre scenarios: someone decides to go on a rampage or kill themselves, and sets Gmail to send suicide or revenge notes after they do it.

The techniques for averting these possibilities are pretty straightforward: simply limit the number of messages a user can queue, the length between subsequent messages to be sent, and the time they can be delayed for being sent. I would think it would be reasonable to impose limits of, say, no more than 100 messages in the queue at a time, no more than one sent per minute (those queued to send at the same time would just have to wait a few extra minutes), and no more than a week allowed for a message to sit in the queue. These, or even more conservative limits, would certainly be sensible to implement when the feature is in the experimental phase, and could be tweaked as necessary. It's hard to foresee much harm that could come with such limits imposed.

You can even imagine some additional benefits that might come from such a system. I, for example, can certainly appreciate the appeal of running off into the wilderness for a while without telling anyone where you're going or even that you're going at all. But in case something goes wrong and you don't want to have to amputate your arm and drink your own urine, you might set a message to send not long after you intend to return, asking someone to send help, and then just delete it if you do return as expected.

The only other objection I can think to is a perceived level of disrespect that might come from thinking that someone sent you a delayed message. You couldn't entirely trust the times you saw on the messages anymore. Maybe someone has deemed you second-class and delayed you for fear of excess of conversation. Or maybe the opposite might happen too. (I can see it now: "He emailed you two days after your date? That sounds good -- he was interested but not overeager. Ooh, or maybe he wrote it as soon as he got home and just delayed it!") But I wouldn't anticipate using this for any personal messages (the sort of thing some people still quaintly drop in the mailbox) or matters of urgency. On the whole, the harmony brought about by empty inboxes with staunched inlets would make this feature usher in a new era of tranquility in human history.

Black Box Blog

Welcome to Black Box Blog! The purpose of this blog is to examine and critique computer interfaces. Among software developers, interfaces are sometimes known as "black boxes", because they show their external workings to users but hide their internal workings. In other words, they show what they do, but hide how they do it. Our interactions with these black boxes increasingly constitute our interaction with the modern world. This blog is dedicated to examining the ways that current popular interfaces work and don't work, and particularly to suggesting ways that they might be improved.

I am both a writer and software developer by trade, and I intend to bring my inside-the-box knowledge to this blog, but to write it from the perspective of the user on the outside. The end goal is to help build better black boxes.

Feel free to send me your suggestions for software you'd like to see reviewed.