One Step Backward

It vexes me that some browsers today still assign the "back one page" function to the backspace/delete key. Even in the auto-draft-save era, accidental page backs are still an issue as partially-filled form fields are often out of focus. There are ways to disable it in some browsers, though it's debatable whether such a crucial key should be dual-purpose.

Backspace back-deletes text when form fields in the page are in focus, but goes back a page otherwise. These fields frequently come in and out of focus, which just increases the likelihood of the mishap of losing unsaved form data that much more. (Not every browser remembers unsaved form data when returning forward one page.)

Did someone think it was a good idea to use "backspace" because it reminded them of "back"? Backspace/delete keys suggest something destructive - it doesn't just move the cursor in a text context, but removes characters along its way too. Navigating back one page is not a destructive act. It's navigation, much like moving a cursor with the left arrow key.

All we have now are website-implemented safeguards - your auto-drafts, or perhaps JS detection of the "back" key to prompt the user when forms are on the page. But these aren't solutions because you can't depend on every site to be designed well to begin with.

There has to be a better way.

In-Browser Search Engine Switching

When I first used Firefox under the Firebird name, one of my favorite features was the ability to quickly add and switch search plugins for other sites. In the case of Firefox, you could type one query, and any other search engine or site search was just a click away. Or for keyboard shortcut aficionados, ctrl+k/cmd+k > ctrl/cmd + up/down > enter.

Safari didn't offer this feature, but years back, I discovered a third party Safari plugin called Inquisitor, at the time the work of an independent developer. Among the features it offered, it also allowed users to also add and switch between search engines with a single query.

But what I loved most was how easy he made it to add search plugins. You see, for Firefox, I wrote several search plugins starting at the end of 2004 and beginning of 2005, using the Sherlock format. Some of these (Yahoo! Movies, Yahoo! Widgets) have been replaced by OpenSearch versions uploaded by other people, but some of the early ones remain in case you want to see what I'm talking about (Cal Berkeley plugin from February 15, 2005).

With Inquisitor, on the other hand, we could simply use a variable representing the query within the URL parameter used in any given site search. For example, if I searched IMDB for "Memento", the URL ended up looking like this: "http://www.imdb.com/find?q=memento;s=all". At that point, I would be able to replace the "memento" search query with a variable in the Inquisitor settings to get this: "http://www.imdb.com/find?q=%@;s=all", where %@ just happened to be the variable used by Inquisitor.

Suddenly, I could add just about anything site within seconds, from Finance quote searches to torrent sites to corporate intranet searches.

It didn't cross my mind that someone could easily top this, but Google did just that with Chrome. When typing a domain like imdb.com into the hybrid URL-search bar, the right side of the bar hints that you can hit the "tab" key to type a search query for a search within that site (in this case, imdb.com).


Most major dedicated search engines try to facilitate site-specific searches these days, but for times when you want to perform a site search, the browser has evolved to help get you there.

Inline Autocompletion

Inline autocompletion is a common part of search bars, but for the longest time, autocompletion was anchored to the beginning of the URL in a web browser address bar. In the middle of last year, Firefox included an "awesome bar" in version 3, which allowed us to type: "lunar" to bring up a past history or bookmark of "http://en.wikipedia.org/wiki/Penumbral_lunar_eclipse", whereas other browsers required typing, "en.wiki..." (not even flexible enough to allow "wikipedia" to yield results). Over a year onward, and this still hasn't spread to other browsers.

Inline autocompletion

Anchored autocompletion

Seeing as most web browsers haven't integrated their search and URL bars entirely as Chrome has, this is one handicap of most browsers that maintain discreet address bars, as they miss out on one of the top usability benefits of unanchored autocompletion - lessening the requirement on the user to remember URLs.

From Tabs to Thumbnails, and Back

The screenshots tell it all. The Opera 10 beta browser has a vertically resizable tab bar that turns into page thumbnails as they are expanded. To me, this is the most graceful approach I've seen towards representing open pages as thumbnails because it doesn't interrupt the view of the current page beyond what you control, in contrast to a full page grid of thumbs. I'm curious to see whether this takes off beyond the web browser into other tabbed applications.

Am I the only one who noticed this? Safari 4's Tabs Bar Lost Multitasking

I previously mentioned how Safari 4 Beta had stepped up their spillover tabs menu oversight by moving you to the area of the tab bar where your active tab sits, so that you could see its neighboring tabs. Suddenly, tabs that didn't fit on the visible part of the tab bar weren't segregated into an inaccessible menu.

This was what the Safari team gave us with Safari 4 Beta:


(To jog your memory, notice that wherever you are, the whiter part of the contextual menu shows which part of the tab bar is visible, and it would move you to that section of the tab bar.)

This is what happened when Safari 4 officially came out:


(Now we're back to being fixed at the front of the tab bar, and only one tab from the contextual menu can show up in the visible part of the tab bar at a time - at the very end of the tab bar. So if I selected the hidden spilled-over 16th "Flickr" tab, it would appear at the end of the visible tab section, beside the 10th "Google" tab. That misrepresents the sequence of the tabs, and reduces what we can do with it when moving tabs around.)

They quietly removed it, and while the blogosphere and media seem to be talking about the Safari 4 official release version, nobody seems to be talking about this. Am I the only one who noticed this? Surely I'm not the only detail-oriented person around here. Maybe all the designers out there just haven't noticed this yet. What a step backwards. My only redemption is that we now have access to the Chrome developer preview for OS X.

When Browser Tabs Spill

In the olden days, web browsers didn't provide us any real solution for tabs spilling off the edge of a tab bar filled with open tabbed pages. In the past few years, we saw multiple angles from the main Webkit/Gecko/Presto/Trident browsers. In the near future, these different approaches will likely merge, although you may be surprised by the results over which browser seems the closest there.

Safari 4 Beta: Menu of Visible and Hidden Tabs

Firefox 3.x/3.1-3.5 Beta: Scrolling Carousel Tab Bar + Menu of All Tabs

Chrome 1/2: Compact as Many Tabs in View As Possible (a.k.a. No Solution)

Opera 9/10 Alpha: Compact as Many Tabs in View As Possible (a.k.a. No Solution)

Internet Explorer 7: Scrolling Carousel Tab Bar + Menu of Visible and Hidden Tabs

Camino 1.x: Menu of Visible and Hidden Tabs

Surprisingly, Internet Explorer, the last of the current big browsers to implement tabs and generally seen as playing catchup with the rest, has shown the most complete system today for managing tabs in version 7, which naturally carries over to the recently released version 8. It allows both scrolling of tabs left and right, while distinguishing the visible and hidden portions of the tab bar in the tab list menu. Although it strikes me as odd that they decided to place the menu on the left, when tabs are created and spilled over on the right.

On top of that, it also offers a grid of thumbnails of the open pages, all out of the box. I'm not accounting for extensions or plugins for any of these browser comparisons because I'm concerned with what comes out of the box, which is generally what most users will use, and what you and I will use on a computer with restricted privileges, or a computer we're using as a guest.

Organizing Groups of Tabs in Windows

In the past few years, we saw browsers answer our micromanagement desires by finally giving us the option to drag tabs to rearrange their order. Some browsers took it a step further and allowed us to tear tabs off a window and onto another. Most mainstream browsers seem to have taken cues from each other and implemented this functionality more or less the same way.

Safari (3 and) 4 Beta: Draggable, Tearable Tabs with Preview

* The difference was that with Safari 4 Beta, the tabs could now only be dragged from the edges because of their new location at the top as both tabs and titlebar, contrary to Chrome.

Opera 9 (and 10 Alpha): Draggable, Tearable Tabs

* The behavior in version 10 Alpha is still the same. It remains to be seen whether the future beta and release versions will add previews.

Firefox 3.1/3.5 Beta: Draggable, Tearable Tabs with Preview

* Tabs could only be dragged within the same window in and before version 3.0.x.

Chrome 1 and 2: Draggable, Tearable Tabs with Preview

Internet Explorer 7: Draggable Tabs

Camino 1.x: Nothing

We'll see whether this will change with Camino 2.x Alpha.

Chrome and Firefox have the best approaches, as they allow tabs to be dragged or torn off from the full area of the tab. Safari 4 Beta introduced an oddball by doubling the tabs as a titlebar and draggable, tearable tabs. That meant that from 3 to 4 Beta, the draggable area shrunk to the right corner, leaving the us to awkwardly drag the window by the "titlebar" area in the tiny center of the tab, avoiding the drag area to the right and the [x] close button to the left. Firefox and Chrome provide distinct draggable areas to move the window alone, and to place it in and out of focus. Opera and Internet Explorer 7 are missing previews of tabs as they're being dragged, and IE 7 doesn't provide tab tearing. Camino 1.x offers nothing.

Conclusion

By now, most of the modern browsers (and probably many of the unmentioned browsers) have addressed the problem of what to do with tabs when heavily multitasking. To recap, there seems to be two major approaches - provide a contextual menu listing active tabs from left to the right, with grayed out items above or below for hidden items to the left or right respectively; or allow a carousel-like horizontal scrolling of the tabs in the bar to access the hidden tabs on either side. For moving tabs between windows, tearing off tabs (with previews) from one window to another is the most comprehensive form of a common approach.

What ever happens, the fact that we are in the middle of a second golden age of browsers with healthy competition means a lot of good for all of us users and developers.