Re: [public-webapps] SearchBox API

On Sun, Mar 20, 2011 at 5:26 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> On 03/21/2011 01:23 AM, Adam Barth wrote:
>> 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.
>
> One of the problems with this API I have is that
> either browser implements the UI the API expects
> (rectangular dropdown list) or just doesn't support the API.

AFAIK, every user agent occludes the content area with a rectangular
(or roughly rectangular) region as part of the search field
interaction.  If you've got examples of non-rectangular occlusion, I
suspect Tony would be willing to update the API to support other
geometries.

Of course, you could implement the API to always report no occlusion
and still make use of the other features.

>>> 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.
>
> Sure, but that isn't still the reasoning for the API design.
> (Btw, I sure hope the API is still somehow prefixed.)

Perhaps I misunderstood your question.  As described on
http://dev.chromium.org/searchbox, the API is exposed on the
window.chrome object, but likely a better long-term place for the API
is on window.navigator.  So, yes, it is currently vendor-prefixed.

>>> 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).
>
> The only difference I can see when enabling instant search in Chrome and
> typing "potato" is that the current web page gets dimmed somehow.
> The web page is not updated in any way (it doesn't matter if the current
> web page is the default search or some other page).
> The dropdown list under omnibox contains exactly the same entries with
> and without instant search.
> (Using 11.0.696.12 dev)
>
> 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.
>
> Unfortunately I'm not seeing any of this :(

Olli and I discussed this a bit in #whatwg.  We think he's
experiencing some sort of bug.

> I assume that (if instant search worked for me the way you described)
> if I have some random web page open and I start "instant search", the
> default search page is loaded somewhere to show the results. What is
> that somewhere?

Yes.  The results are loaded in the main content area.

> Or
> Does this feature work only if the default search is already loaded
> to the current tab?

Nope, it works whenever you start typing in the browser's search field.

Olli points out that there's a lot about the API that isn't currently
specified.  I definitely agree, but hopefully that's something we can
improve.

Adam

Received on Monday, 21 March 2011 00:50:23 UTC