Ever since Google Chrome’s introduction, every other web browser has been enviously aping its user interface minimalism. Firefox has gotten on the tabs in the title bar bandwagon, switched to a Chrome style status bar, and turned the menu bar into a menu. Internet Explorer has gone even further, and merged the tab bar with the address bar.
Minimal user interfaces are clearly the vogue in the web browser world but has the user interface on a diet trend gone too far?
Not at all! By the end of this article, we will work through a web browser user interface (an implementation for Firefox is provided) that utilizes no more screen space than Google Chrome’s Omnibox but packs an order of magnitude more functionality.
Google Chrome’s Omnibox
Packing in more functionality is easy if one disregards usability, but the new design is an order of magnitude more usable as well. The core of the new design is a user interface widget that allows listing/searching of data source data, and seamless switching between different data sources. The data sources may be internal such as bookmarks, and browser history; or they can be external such as the various publicly available search APIs. The combination list/search interface and the uniform treatment of data sources adds consistency to the design and enhances usability.
Earlier, I mentioned an implementation. Below is a screenshot from the implementation. It shows the new design:
A Better Omnibox?
The design makes no modifications to the tab bar so it is not shown. It combines the address bar, the search bar, and the bookmarks bar into one unified toolbar.
Apparently, the new design has no text boxes for the user to type queries. Can you guess where the user types? Below is a more revealing screenshot:A search menu showing search results for a query
Search results are shown in search menus. Search menus are popup menus that contain search boxes. Search menus are hidden out of view until the user clicks a search button. This arrangement lets the user view search results in the browser interface instead of having to view them at a search engine website.
The new design eliminates the need to navigate away from the current webpage in cases where the answer to a query is embedded in the search results.A case where the query is answered in the search results
The hidden search boxes may suggest that this user interface is slower to use than Google Chrome’s Omnibox, but this is not the case. The user can click a search button (or press a keyboard shortcut) and start typing immediately. This is no slower than clicking a search box to focus and typing.
Below is a third screenshot. It is a repeat of the search shown in the earlier screenshot via a different data source.
The Shop search menu shows prices
The interesting thing about this screenshot is that we got to it from the state depicted in the earlier screenshot by exactly one additional mouse click. Can you see the magic of the design now? Repeating searches via a different data sources is effortless. (The black toolbar shared by Google search pages does something similar but it is limited to Google websites only.)
The News search menu searches news
The really neat thing about the design is that it is data source neutral. It does not prefer one data source over any other. You can have Google, Bing, Blekko, Wolfram Alpha, and whatever else you want as search buttons, and the interface will treat them all equally. Searches via any of the data sources require just one click. There is no default search engine of the traditional browser user interface. There is no need for one.
Even better, all data sources complement one another. Failed to find something in the Bookmarks? No problem, Google is just a click away. Google failed as well? No need to worry, Bing is there, and so is Blekko. Search engines instead of shutting one another out, shore up each other’s weaknesses in this design.
The new design gives even niche data sources such as Wolfram Alpha a chance. A user can try them because now she knows that if the search fails a regular search engine is just a click away.
Another magical feature is the ability to turn text selection into searches. This too takes a single button press. With this feature, a user can lookup the definition of a word with just three clicks: a double click for the word selection and a search button click for the lookup. The screenshots below show how selection searches work:
First, select the text you want to search
Second, click on a search button of your choice
Want to see the next page of search results? That is easy too:
Two pages of search results
Being popup based, the new design encourages a different search workflow than the traditional workflow. Under the traditional search workflow, a user opens a search engine results page (SERP) and visits interesting links one by one. She uses the browser back button to get back to the SERP after every link visit.
The new design does not have a SERP to come back to, so it encourages a workflow where the user opens all interesting links in tabs before closing the search menu. This ends up requiring a tab focus change (this cost can be eliminated by opening new tabs in foreground) but saves the user waiting time on slow loading links.
Opened links shown in red. Clicking a red link closes the search menu
Another interesting feature of the new design is that it is modal. It has two modes, one for listing/searching different data sources (referred to as searching in the rest of this article) and one for browsing the web. Under this design, the browser starts in browse mode. It shifts to search mode when the user presses a search button. It stays in search mode if the user presses another search button while in search mode. Finally, it moves back to browse mode when the user hides all search menus.
This design lets the browser reset search boxes to their default state after a user is done searching. In simple words, it lets the browser automatically clear the search boxes. Traditional browser user interfaces do not have this capability as they intermix browsing with searching.
This property allows the web browser to associate a default search with every search button. The web browser presents the results of the default search to the user if a search menu on opening is in its default state.
For instance, for the Bookmarks button, the default search lists the most recent bookmarks. For the search button, the default search lists the most popular pages (as returned by the Bing API) from the website the user is at.
Default Bookmarks Search
The default search is not the same as autocompletion. Autocompletion suggests potential search text completions to the user, but the default search presents search results to the user. For many data sources, the default search eliminates the need for having separate interfaces for listing and searching data from a data source. It greatly adds to the usability of the new design by allowing the new design to perform the tasks traditional user interfaces perform via two separate interfaces.
The next screen shot takes us to the address bar:
Address bar search menu
The new design treats the address bar as another search button with an associated search menu. This choice leads to greater consistency in the design but beyond that it solves a very nasty problem with the traditional address bar.
The traditional address bar suffers from a problem that is best described as peeing in your drinking cup. Basically, it uses the same text box for output and also for input. It updates the text box’s current value whenever the current webpage changes but also lets the user replace that value with something different. Once this is allowed the user cannot always be sure if the current value in the address bar is the address of the current website or a value she entered earlier.
Firefox address bar showing google.com as yahoo.com
The new design has none of that confusion. The address of the current website always shows as the label of the address bar, and the user types in the address bar’s search menu.
Address bar search menu with label google.com but search text yahoo.com
As an added benefit, the new design allows a default search for the address bar too. The default search for the address bar can list the most frequently typed website addresses, the most visited websites, or something equally useful.
As search menus are so important to the new design, a conscious decision was made to increase their utility by adding the ability to edit items directly in the menus. For instance, some search menus indicate the bookmarked status of an item by a star and the user can click the star to bookmark an item or to edit a bookmark. Other search menus allow the user to tag items.
In the next screenshot, we have shifted to the bookmarks data source. Notice, you can directly tag bookmarks via the tag icons to the right of each bookmark.
Bookmarks search menu with several items opened
A user may also sort and filter search menu items in various ways. For instance, you can setup a Reading List by filtering the bookmarks data source by the unread tag and sort it by title. This combines with the tagging capability of the search menus to let you take things off the Reading List directly. You can even add more items to the Reading List by turning the unread filter off and tagging additional bookmarks unread. Traditional user interfaces special case such functionality, but here the experience is smooth, uniform and seamless.
Bookmarks filtered by unread tag
Still skeptical? Want to try the interface for yourself? If you use Firefox, start by downloading the add-on Categorize. It contains a working implementation of the design outlined here.
Notes on the Implementation:
The implementation only supports Bing and Amazon APIs. Other search engines either do not provide any APIs or their API usage terms are too restrictive. Also, the results yielded by the APIs are much poorer than those provided by regular search engines. In fact, the Amazon API results are so poor that a search button for it is not included in the default setup. The poor results are not a problem with the user interface but a deliberate choice by API providers to treat API users as second class.
The implementation does not follow the design outlined in this article strictly, and many features do not work as outlined. These issues are due to the implementation being a Firefox add-on and can be circumvented.
By Usman Latif
Published: July 29, 2012