Manas Tungare

A Proposal to Integrate Site-Specific Search Boxes into Browser Chrome

Why do I have to search for the search box on any site I visit, before I can type my query into it? Given that almost every well-designed site has a search field, and it has been recommended as a good usability practice since 2001, why is it sometimes hidden deep inside the layout? Here is a suggestion for a change in the browser UI that will enable users to find the search box faster. Even faster than other suggestions so far. It only involves a little semantic markup on part of page authors and some redesign on part of browser makers.

The search box within the browser is underused.

The search box is one of the few basic design patterns omnipresent on the Web. It is also a de facto usability practice to place this search box towards the top right corner of the page. Yet, every site has it at a slightly different location (and some, even towards the bottom.) The user needs to search visually for the search box, or at least glance around until she finds it.

During this entire time, the search box within the browser chrome typically lies unused. It has a default search engine defined where it directs all queries typed into it. Why can’t the currently loaded website take advantage of this in-built search field for its own site-restricted search?

How it would work:

When a user is browsing a site that supports this feature, any searches conducted using the browser search box will send the queries to the site in question, and be able to display search results directly. When no site is loaded, the queries are directed to the user’s default search engine, just as it is now.

This proposal does not require any significant changes to any markup language — all that is needed is to enhance the markup with semantic knowledge, and microformats are just the answer! Simply marking up a <form> element with the CSS class "search" should be enough to tell the browser that this is a search form that should be promoted to the browser’s search box chrome.

Prior work on similar problems

HTML 3.2 (yes, 3.2) defines a link relationship type for search pages. Adding <a href="/search" rel="search"> indicates that the outgoing link is to a search page. Browsers currently don’t do much with this information (please correct me if you are aware of a browser that does something intelligent with this information). OpenSearch is (in their words) a simple format for the sharing of search results. Useful as it is, OpenSearch is more geared towards large-scale general search engines, and browser makers are adopting it as a standard for letting their users pick and install search plugins in browsers.

However, being able to customize the search field on a per-site basis with zero configuration on part of the user is not addressed by any of these proposals.

Addressing Potential Criticism

A few critics might argue that such usage dilutes the purpose of the search field (“It’s meant for searching via a search engine, not on a per-site basis”) or be concerned about possible user confusion (“Is my query being sent to a search engine or to the site I’m now visiting?”).

Considering an intentionality-driven approach to design, this UI is perfectly aligned with the user’s intentions. If a page has been rendered in a browser window, the user’s intention is likely to search within that site. If the user wanted to perform a search using a search engine, there is always the possibility of loading a new tab and then searching via the same field.

Issues of Mode

This also brings up the question of whether such a UI is inherently mode-based. (Modes in a User Interface are said to exist when a single input can result in two or more possible outcomes, depending upon the state of the UI at that point. It is generally considered bad design to employ modes in a UI because it invariably leads to user confusion.) In this case, it is arguable whether or not this UI employs modes.

The user task is “to search”, and the current site can be considered a specialized search engine (the specialization is that they only search within their own site). Given that a lot of sites employ site-limited versions of generalized search engines (e.g. Google’s Custom Search Engines), this notion is not very hard to think of. Hence, I argue that these are not two different modes, but two different search providers for the same box, just as current implementations offer users a choice among Google, Yahoo, Altavista and others.

Indicating the currently active search providers in browser chrome

It is also easy to indicate the destination of the search queries in a visually accessible format. Safari (for example) displays the word “Google” in the search field. When a site-search box is displayed in its place, it is trivial to display the name of the site instead of the word “Google”. It is also trivial to reuse the favicon for the same purpose.

Why not?

What do you think about this idea? Comments, suggestions, enhancements appreciated!

Comments

  1. Cool idea Manas,

    so far the “Site search” in Google toolbar might do for you…. of course the implementation that you showed in safari is neater

    Yannick — May 14, 2007

  2. I for one want the “normal” search box to always go to the same place (which, for me, is Google). I only rarely want to search a site, but I frequently finish with one page, want to go on to something different, and do Control-K+[search term] to move on.

    Kaitlin Duck Sherwood — May 14, 2007

  3. I recently found out about the type=”search” field that works only in Safari. I’m going to use it when I revamp my blog for Safari support.

    Brad Touesnard — May 16, 2007

  4. Hi Yannick, yes, the Google Toolbar goes part of the way, though not entirely. Sometimes I’d like to be able to use site-specific search engines for non-public information. For example, I might be at a photography store website, or at Amazon.com and would want to be able to use their search engine instead of Google.

    Hi Ducky, good to see your reply on my blog! :) The current behavior (always search using Google) can stay the default, but users should also be able to choose and pick the current site’s search engine to replace it. Happy medium between both approaches?

    Hi Brad, great tip! I’m using to use that for my next redesign too; it solves at least part of the problem.

    Manas — May 19, 2007

  5. Hi,

    I saw your blogs, and I thought they were interesting to read. I’m thinking of starting blogs too. And your website is pretty cool too. Mine however needs work :) I will be starting as a Ph.D student at Vtech in August. Maybe we’ll meet there. I just wanted to compliment your site. I came across your site from orkut.

    Emma

    Emma — June 4, 2007

Leave a comment

 

Popular Posts