I’ve been wanting to write this post for a few years now. During the development of Firefox 3, I worked on the design of the awesome bar (iteration 1, iteration 2), and on the design of Places (an internal name for History and Bookmarks in Firefox). This post details what I’ve imagined as the next chapter for both, but here’s the interesting part: it’s actually the same story.
The Fundamentals: Search vs. Browse Interactions
Searching and browsing are completely different styles of interaction. Search-based interfaces (like Google, Quicksilver, or the awesome bar), are very fast, they rely heavily on keyboard interaction, and they require you to know for the most part what it is that you are looking for. By contrast, browse-based interfaces (like Yahoo’s Directory, DMOZ, or Firefox’s Bookmarks Sidebar) are slow, rely heavily on mouse interaction, and are most effective when you only have a general idea what it is that you are looking for.
User interface designers usually differentiate between which interface, search or browse, is better suited for a particular task with the terms “recall” and “recognition,” referring to what is going on in the user’s mind. If the user is relying on recall, they are able to proactively retrieve what it is they want out of their memory. For instance, the traditional command line, is a recall, or search (with tab completion), based interface. In contrast, if the user is relying on recognition, they need to be able to see particular terms or objects on the screen before they are able to make a decision on what to do next. For instance, the standard GUI is fundamentally a recognition, or browse-based interface.
Often people focus more on the examples given than the fundamentally different aspects of the two types of interfaces, and assume that one type of UI is better than the other:
I used to use the command line, but then the GUI became popular, I hate remembering stuff, browse is better! Recognition beats recall!
I used to use the Yahoo Directory to find stuff on the Web, but then Google came out, I can quickly get to stuff, search is superior! Fast beats slow!
Or, in the case of the Firefox UI: I used to use the bookmarks sidebar to access things, but now I just use the awesome bar, it’s so much faster, search is the future!
But battling the different interface examples against each other somewhat misses the point. It isn’t about which interface, search or browse, is better than the other, it’s about which is a better match for the user’s particular task, and which is a better match for the user’s mind. So it is critical to provide the user with both, and to make sure that both are extremely well designed.
In Firefox 3 we spent most of our time focusing on improving search to navigate to specific bookmarks and history, with the introduction of changes to the location bar that a lot of people felt were awesome. The awesome bar redefined how we handled search in our UI, allowing users to match any part of the title or URL, monitoring the rate that users revisited sites, and learning to adapt to which search results they were most likely to select for particular search queries. After a little while you and your awesome bar started to know each other really well: in many cases you could type in a single letter, and it would serve up the exact page you were looking for. We pretty much nailed search.
But for user interfaces and information retrieval, getting search right is really only the first half the story.
Bookmarks == Files?
Historically Web browsers have handled bookmarks and history with an interface similar to the OS file system (and in some cases browsers have literally used the file system). Web pages are usually cast as little 16×16 files, and you can move them around using a traditional two pane window with folders. Perhaps because computer scientists were involved, there are a lot of hierarchical structures to expand broadly or deeply.
What’s really ironic is that these interfaces are always completely removed from direct act of browsing the Web. Sometimes they are in a totally separate window, sometimes they are sort of tacked onto the side of the browser in a sidebar, and sometimes they are layered over the browser in a tab. But these browse-based interfaces never really leverage the fact that the user is interacting with an application whose sole purpose is to browse things.
Browsing Your Personal Web
The Web browser UI has a lot of useful core controls for browsing information, a home control to take you back to the beginning, back and forward to explore a timeline of recent navigation, and a location bar lets you jump directly to an entirely new destination. These controls could be really useful for browsing history and bookmarks, in addition to browsing Web pages. So I believe we should fully integrate bookmarks and history into the Web browser interface.
Here is what this means specifically:
1. You can start to dive into history and bookmarks from the Home Tab
A lot of browsers have provided access to commonly visited pages. That’s great since it is a zero-configuration interface, and it’s something that we are looking into doing on our home tab as well. But in addition to viewing commonly visited pages, we want users to be able to navigate from the home tab into the bookmark folders and tags that they have specifically created. So for instance users can click through the chain of Home > Bookmarks > Recipes > Salmon with Mustard and Brown Sugar Glaze. You might be thinking, this seems slow, why not just type “salmon” into the awesome bar? Perhaps the user wasn’t able to recall (or perhaps even decide) what they wanted to cook for dinner. Or, perhaps they didn’t even realize that it was time to cook dinner until they recognized their recipes folder and it triggered the thought.
On a side note: recognition interfaces always have the potentially dangerous side effect of influencing and manipulating the user’s behavior. Perhaps the user was headed to “research” but then redirected to “recipes” instead. Or in the case of commonly visited pages being displayed on a new tab (Safari, Chrome): “I was going to get work done, but instead I went to slashdot and digg.” This is one of the reasons that we want to have a home tab. The home tab lets us have an interface that is entirely recognition based, rich, functional, but distracting as hell. And the new tab can remain purely recall based, a blank zen sea of perfect nothingness, but by itself completely useless.
2. History and Bookmarks are displayed in the content area
Perhaps the most obvious way in which bookmarks and history can be fully integrated into the Web browsing experience is by rendering them not in a sidebar or separate window, but in the content area itself. The content area has a lot of nice properties: This gives us enough space to display thumbnails of bookmarks and history which allows users to quickly identify pages that they have seen before with a broad glance (we have an uncanny ability to remember colors and images and lizards). Additionally, the content area can be combined with a hierarchical sidebar for a traditional two pane organization interface.
3. These content area pages are part of your back/forward navigation queue
Another nice property of displaying bookmarks and history ranges in the content area is that these locally hosted meta-pages can enter into the user’s back and forward queue. So for instance, you can go to your folder of bills, pay the first bill, and then return back to the bills folder to pay the next one. Or if you are scanning your favorite sources of news, you can use the back button to take you to the page that contains the rest of the sites you like to read.
4. You can navigate directly to a collection of bookmarks, or a range of history…
Of all of the aspects of integration, this is the one that I am the most excited about…
Search + Browse Operations: the Best of Both Worlds
Above I stated that it isn’t about which interface is better, search or browse, but which is the most effective for the particular task. Does the user need recognition-based, but slow, or recall-based, but fast. But there is also a third option, which is to seamlessly merge the search and browse interfaces, and create a UI that is perfectly optimized with the user’s ability to recall specific or general information, while minimizing the time spent navigating!
Here is what I mean: even if you can’t recall the information you want down to the most specific level of detail, you search on the slightly more general information that you do remember, and then browse from one step out.
So, ideally I would remember all of the different companies that I pay bills to each month, and I could enter each of them into the location bar (recall, fastest).
But instead, currently I have them all in a folder, which I access by displaying the Bookmarks sidebar, expanding the “bookmarks menu” folder, finding the “apartment” folder, expanding the “bills” folder… (recognition, slow).
However by fully integrating bookmarks and history into the Web browser UI, I can use the location bar to navigate immediately to my bills folder, and then start paying my specific bills (recall, followed by recognition, fast-ish):
In this example “bills” happens to be a folder, but it could just as easily have been one of the user’s tags.
This hybrid interface also makes our history UI a lot faster. If someone is using the history sidebar, it’s usually because they can only remember partial information about what they are looking for (if they had all the information they would just use the awesome bar to navigate straight there), but they can recall the time range to search.
So instead of a small and clunky tree view, why not just let the user navigate straight to the time range they want to view:
This of course means a lot of potential history range terms and string localization, but this is a considerably more efficient way to locate a page out of your history, especially when it is combined with viewing thumbnails in the full content area and leveraging your visual memory.
Introducing the Not-So-Universal URL
Using the Web browser’s location bar to navigate your personal Web somewhat breaks the current nature of URLs. While the user is using the location bar to navigate to pages that have Resource Locators, these Resource Locators are certainly not Universal. However, I think there are two interesting caveats:
When you sync your bookmarks and history with Weave, and log in to any instance of Firefox (4?), you will now be able to navigate your personal Web. So while not completely global (that would be a massive privacy violation), these bookmark and history pages are more universal than being stored only on a single machine.
Additionally, while Weave locally encrypts all of your data before transmitting it to guarantee total privacy, it would be interesting if users could choose to publicly share a particular folder or tag of bookmarks, which would subsequently give the page an actual URL, which is of course Universal and shareable.
Very Early Design Mockups
Here is the current set of mockups to document the new functionality. This project is still in a very early conceptual phase, and as always we would love to hear your feedback.
Accessing Bookmarks with the Location Bar
Accessing History Ranges with the Location Bar
Viewing Bookmarks in the Content Area (in progress)
Viewing History in the Content Area (coming soon)