Browser search bars: unused potential?
What do you use your browser for? Reading weblogs? Watching photo albums? Trading on ebay? Finding information for school? One thing that all these activities have in common is that you’re searching for things. Searching is hot, just look at google, the planned features of WinFS and MacOS’ Spotlight — all products that aim at finding the information you’re looking for just by entering some keywords and doing a couple of mouse clicks.
Another place where search functions have become increasingly common is on individual web sites. As an example, you can search this blog: you can search for keywords just like you can on forums, the latter oftenly offering the possibility to narrow down the results by specifying time frames, posters, etc. As nice as it may be, it has one serious downside: to make use of the search functions, one needs to load up an entirely new page with the search forms. Browsers like Firefox and Safari may have this partly covered by their search bars, but still this is not ideal. Searches are limited to entering values into one single field, the results are presented on a page that takes up the whole browser window and adding search engines is quite cumbersome, nor does the search engine adapt intelligently to the page that is currently being viewed. This could be done better.
A prerequisite for enhancing the search capabilities of browsers is a means to make browsers aware of what can be searched on a certain web site. An excellent way to do this may be by using an xml document (which may be referred to in something like a <link> tag) which contains information of the available search fields and the URI at which the sent values will be processed. (One may also opt for using the same type of xml document for returning the search results, but more about this later). While such an xml document may seem quite useless to the average user, it has one great advantage: it provides the browser with search form information for the particular web site, regardless of which page of that site you’re viewing. With this, it is possible to do a search on the site by, let’s say, clicking a button on the top right of the browser screen, which then folds out an overlay with all relevant search field and a submit button. You’d have instant access to this search form, which would also be far more discreet and less disturbing than an entire new web page for the same purpose. And because the search form is on the web in xml, it’d be a piece of cake to add the form to the list of forms available to the browser, pretty much like one can add search engines to Firefox now. The only difference here is that the proposed engine is determined by which page is being viewed.
While the abovementioned enhancement may sound “just nice”, using the same xml format for returning the search results may make things even better. Just like the search form, they may be displayed in a tiny overlay in some corner of the browser window, clear enough for examining them, yet small and discreet enough not to disturb the page you’re viewing. And of course the viewer still has the option to go to the actual page if things seem interesting enough. You’d be able to convert currencies while browsing ebay items, you’d be able to look up phone numbers while composing an email with a web based service, you could easily compare prices while shopping… the possibilities are endless. Of course one could argue that the same is already possible using multiple browser windows (or tabs), but that just could not compete with a dedicated search user interface with its own history (which could be attached to browser windows/tabs) which is stripped of anything you don’t need to do simple searches and which doesn’t clutter your screen (or tab bar) with needless browser windows. And when this enhanced search bar would seamlessly utilize local resources like address books, things would really get interesting…
In my view, a browser’s purpose is viewing pages. Feed readers already are an example of light-weight programs that take burdens from the user and light-weight searching may very well be a logical next step.