Re: SearchBox API

[Re-sending to the correct list.]

On Sun, Mar 20, 2011 at 2:34 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> On 03/20/2011 01:36 AM, Tony Gentilcore wrote:
>> Back in October I proposed the SearchBox API to the whatwg [1]. It
>> enables "instant" style interaction between the user agent's search
>> box and the default search provider's results page.
>
> When I tried instant search on Chrome, it did something only when
> I was typing an url. It preloaded possibly right url before
> I pressed enter. It didn't seem to utilize the coordinate
> information of SearchBox API at all. (Perhaps I wasn't testing it correctly)
> A browser could certainly preload pages similarly even
> without the API.

The "instant search" feature has a bunch of different components.  One
aspect is URL preloading, which happens when the browser thinks you're
typing something "navigational" (like a URL) into the omnibox and is
not related to the SearchBox API.  Another aspect is what happens when
the browser thinks you're tying something "search-like" (like potato)
into the omnibox.  In that case, the browser displays a search engine
results page.

> So, why does the search page need any data?

The SearchBox API has a two-way flow of information between the search
engine results page (SERP) and the browser's search field.  (In
Chrome's case, that's the omnibox, but it would work just as sensibly
for browsers with a dedicated search box.)  Essentially, the browser
tells the SERP various information about what the user has typed in
the search field (much like the web site would learn if the user typed
into a text input field in the web site) and the SERP tells the
browser some suggested completions for what the user has typed so far
(e.g., so the browser can display those suggestions to the user).

Additionally, the browser can tell the SERP about the geometry of the
search field (if it overlaps the SERP), which lets the SERP move its
UI out from underneath the search field, if desired.

> Couldn't browser interact with the web search in the
> background and show (and possibly preload) results the
> way it wants to. That way there wouldn't be an API which
> fits in to only one kind of UI.

I wasn't involved in the design, but I suspect there are latency and
synchronization challenges with that approach.  Most modern browsers
use that approach for showing search suggestions in their search
fields today, but with this UI, it's important to synchronize the
browser's search field with the SERP.  Using JavaScript events to
communicate removes some of the network latency.

> I think I'm missing some of the reasoning for the API.
> Could you perhaps clarify why Google ended up with such
> API?

As a general principle, Chrome shouldn't have an "special"
integrations with google.com.  For example, bing.com should be able to
use any Chrome feature, and other browsers, such as Safari and
Firefox, should be able to use any google.com feature.  Now, the
project doesn't always live up to that principle, but that's the
reasoning behind implementing and specifying a general-purpose API.

> Also, would be great to see some examples where all of
> features of the API are being used.

My understanding is that Google's SERP uses all the features of the
API.  Tony designed the API in coordination with the folks who work on
Google's SERP.  For example, if you enable the "instant" feature in
Chrome and type "potato" in the omnibox, you should see similar search
suggestions in the autocomplete dropdown as you'd see if you typed
"potato" into the google.com search box (assuming you have Google set
as your default search provider).  Similarly, if you type a character,
the SERP should react immediately to the "change" event instead of
waiting for network latency.  Finally, you'll notice that the
autocomplete dropdown does not overlap with the search results because
of the geometry information provided by the SearchBox API.

Adam

Received on Sunday, 20 March 2011 23:39:11 UTC