--- breadcrumbs: - - /user-experience - User Experience page_name: omnibox title: Omnibox --- [TOC] ## Introduction Most modern browsers are equipped with a toolbar, featuring both a URL and a search field. While straightforward, this UI configuration can lead to some confusion and a general feeling of unnecessary complexity. The purpose of Chromium's omnibox is to merge both location and search fields while offering the user some highly relevant suggestions and / or early results. There were two trains of thought on what the omnibox should offer. Some reviewers felt that current browsers currently try to guess what the user is typing and offer suggestions. These reviewers would like some better accelerators and some more satisfying shortcuts, these two approaches are detailed below: > Accelerate my typing > The omnibox should focus on augmenting the user's commands - all of the tools > it provides should be oriented around making the user's input 'better', and > sending them to a destination. > Show me results > If some highly likely results exist for the user action, these results should > be visible in the omnibox. For example, we could show very probable results > which are coming from web search or history. Chromium focuses on the 'accelerate my typing' system - while showing results was powerful for certain navigational tasks, the designs we tested generally had too much cognitive overhead to be useful in normal situations. Additional details on the philosophy, architecture and implementation details [are available here](https://docs.google.com/document/d/1Dk_U-zXiMFynKOYYKrS6VKUXrON_ta2mYnAyHa-Uvc0/edit). ## Design Principles > ### Reduce cognitive overhead > > An early motivator of combining the search and address bars was a conviction > > that, even for users who understood the difference between the two, having > > to make a choice of where to input text was a small (generally subconscious) > > cognitive load. Combining the two does not just serve novice users, it > > reduces cognitive load for more advanced users. Similarly, the rest of the > > omnibox design seeks to minimize cognitive load. > > One example of this is the graphical design of the dropdown. Items are > > displayed very simply, with a minimum of iconography, bright colors, font > > changes, and other eye-catching elements. This makes the dropdown less > > distracting for cases where users are simply trying to enter text in the > > edit field and get where they want to go, at the cost of conveying less > > information about each item when users are carefully scanning their various > > options. We believe that users ignore the dropdown most of the time, and so > > this tradeoff is the right one. Even when users look at the dropdown, this > > design makes it simple to rapidly scan the available choices rather than > > having to carefully read each one. > ### Stability and predictability > > In a control with as many heuristics as the omnibox, users can easily feel > > out-of-control. Accordingly, both the edit field and dropdown seek to be as > > stable and predictable as possible. Inline autocomplete is designed to > > operate synchronously to avoid flickering or race conditions, and triggers > > on very simple conditions (for most sites, after typing the hostname once) > > so that its behavior doesn't suddenly change after long usage. The > > top-ranked item in the dropdown should not change as more results come in. > > The dropdown itself is always open while users edit, and always has a > > selected entry, so that the action Chromium takes on hitting <enter> > > can always be predicted. Asynchronous background queries stop when users > > begin arrowing through the dropdown so the results don't change as users > > attempt to select desired items. A highlight marks the hovered row as users > > mouse over the dropdown so it will be clear which selection will be used if > > they click. ## Input Types and Examples > The biggest challenge faced by the omnibox is figuring out what the user wants > - the various input types are detailed below: > ### Single word > > Example (Search): cheese > > Example (URL): localhost > > Single-word searches are hard for us to distinguish from single-word URLs - > > previous solutions have relied on synchronous DNS lookups to figure out if a > > user was typing a single-word URL, but such lookups add an unreasonable > > overhead to the search experience and don't always lead to an expected > > result. For example, if you wish to look up what 'localhost' means, but you > > have a local webserver running, the result can be infuriating. > > In Chromium, we decided that consistency and speed was best, and given that > > the range of 'single-word inputs meant as searches' dwarfs the number of > > 'single-word inputs meant as URLs', we default to displaying web search > > results while doing a background DNS lookup to figure out if a local host > > exists - if it does, we display a "Did you mean http://input/" infobar as > > show below: > > image > > If a user accepts the 'did you mean' suggestion, the auto-complete system > > will ensure that subsequent entries of the given term will go to that URL. > > A user can override the search-first behavior by making the search term look > > like a URL fragment - typically adding a slash to the end of the input is > > the easiest way of accomplishing this (eg. "cheese/"). > > If a single-word input is in-progress and matches an URL in the user's > > autocomplete database, we may autocomplete to that full URL. > ### URL (or URL Fragment) > > Example: www.google.com > > Example: www.blues > > Example: http://localhost > > Example: pie/ > > Items that look like URLs will be treated as such. There is a range of logic > > for determining whether something looks like a URL, as there are cases where > > multiple-word input can still be intended as a URL (editing of query > > parameters without using '+' or '%20' instead of spaces, for example). > ### Multiple words > > Example: where can I buy meat pies? > > Example: XKCD meaning > > Multiple-word input is generally treated as search input, unless the first > > word matches one of the user's keywords. > ### Search Keyword > > Example: images.google.com ponies > > Example: g fastidious > > If a user has search keyword, the default action may be to activate that > > keyword using the terms following the keyword as input. ## Tab to Search > If a user is partway through typing something that auto-completes to a > keyword, we allow the user to press **Tab** to jump to the end of the > auto-completion and begin their keyword search term input. This is powerful > when combined with our automatic keyword creation - a user who does a search > on amazon.com in the course of their normal browsing will be presented with > the option of pressing **Tab** to do an Amazon search the next time they type > something that auto-completes to amazon.com, leading to the ability to type > 'ama \[tab to complete\] pies'. We call this functionality 'tab to search'. > [image src="/user-experience/omnibox/keyword.png">](/user-experience/omnibox/keyword.png) ## Result Types > [image src="/user-experience/omnibox/omnibox_results.png">](/user-experience/omnibox/omnibox_results.png) > ### Search for... > This searches for the typed query - this will be the topmost and default item > if the input looks like a search string. > ### URL > If the input (after auto-complete, if applicable) looks like a URL, this will > repeat the user's input and be the default, top-most item. > ### Previous URLs > If the input matches a previous URL, those URLs will be shown here. > ### Nav Suggest > Uses the user's default search provider to suggest URLs based on the user's > input. > ### Search Suggest > Uses the user's default search provider to suggest search terms based on the > user's input. > ### History Results > Shows the number of entries in the user's history that match the given input - > selecting this item will take the user to the history results page for their > given search term.