rich results for searches
Myk Melez
discuss here.]
Summary
Here's a proposal for implementing functionality into Firefox which
gives users a quicker path to specific information they are looking for
(called "rich results") when they type something into the search box.
Examples
When a user searches for "YHOO", which is a stock symbol for Yahoo Inc.,
they probably want a stock report for that company.
When a user searches for "Casino Royale", which is the title of a film
currently playing in the theaters, they probably want show times at
nearby theaters, a synopsis, reviews, and/or to purchase tickets online.
When a user searches for the word "weather" and a zip code or city, they
probably want a weather report for that locality.
And when a user searches for an address, they probably want a map of it.
Implementation
To give users the information they are likely to be looking for, I
propose that we build an API for a piece of code to register itself as a
rich result provider. When a user types terms into the search box, we
query registered providers to see which has a rich result for the terms,
then we provide an item in the Search History/Suggestions menu for each
available result.
If the user selects a rich result from the menu, we display the result
in some appropriate part of the interface. In the current proposal for
improvements to search
<http://wiki.mozilla.org/Search#The_Plan_.28So_Far.29>, this is a popup
submenu, but we could put it elsewhere (f.e. in the content pane) if
another location turned out to make the most sense.
Providers might use a variety of mechanisms to determine whether they
can provide a result, including evaluating a regular expression against
the search terms, looking up the terms in a hash table, or querying a
server. And they might provide the result itself in a number of ways,
generating it themselves (perhaps using data downloaded from a web site)
or just constructing a URL at which the result can be found.
We should ship with a set of high-quality providers but also provide a
mechanism for web sites to publish add-ons which users can install to
extend the set of available results. This mechanism could simply be
regular extensions which register themselves as rich result providers,
or we could create a new kind of add-on specifically for this purpose.
Related Feature - Search Suggestions
Firefox's Search Suggestions feature implements something like this for
mathematical calculations and unit conversions. If you type "1+1" into
the search box, the first suggestion will be "= 2", and if you type "1
inch to centimeters" into the box, the first suggestion will be "= 2.54
centimeters".
The primary limitation of this functionality as compared to rich results
is that a single menu item provides very limited real estate for
displaying results. A secondary limitation is that it only consults the
default search provider.
Related Feature - Keyword Bookmarks
Firefox's Bookmarks feature also allows you to set up a "keyword"
bookmark which you can trigger by entering the keyword into the location
bar. If the bookmark URL contains "%s", and you type terms after the
keyword when invoking the bookmark, "%s" will be replaced by the terms.
So you can invoke requests for specific information with the appropriate
keyword. For example, if you have a "weather" keyword bookmark to a
weather.com page showing the weather for a specific zip code, and the
URL contains "%s" in place of the zip code, then entering "weather
94043" into the location bar will load the weather.com page showing the
weather for Mountain View.
The primary limitation of this functionality as compared to rich results
is that users have to manually construct keyword bookmarks, including
editing complicated URLs and understanding how templates work.
A secondary limitation is that such bookmarks can only be invoked via a
single keyword that precedes the search terms, so "94043 weather"
wouldn't trigger the example in the previous paragraph (because the
keyword succeeds the term), and "forecast 94043" also wouldn't work
because the bookmark doesn't recognize "forecast" as a synonym for
"weather".
A tertiary limitation is that such bookmarks can only be invoked in the
location bar, although users mostly search using the search bar.
Related Feature - Search Engine Results
Google and Yahoo! both provide rich result-like information at the top
of their search results pages for certain search terms. Yahoo! calls
the functionality Yahoo! Shortcuts
<http://tools.search.yahoo.com/shortcuts/>, while Google calls it Google
Web Search Features <http://www.google.com/intl/en/help/features.html>.
The primary limitation of these server-side implementations as compared
to rich results is that users have to load an entire search results page
to see the information. A secondary limitation is that there is no
mechanism for web sites to extend the set of available results and for
users to take advantage of those extensions.
Alex Faaborg
of a larger API for data detection. For instance, if I write a
little regular expression that finds UPS tracking numbers, or a
detection list of common movie names, these detectors should be able
to also scan the current Web page, as well as the text in the search
box.
The UI for locating detected information on the page should probably
be similar to whatever we end up using for microformated content.
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Myk Melez
> I love this idea. I think we should consider making this idea part of a
> larger API for data detection. For instance, if I write a little
> regular expression that finds UPS tracking numbers, or a detection list
> of common movie names, these detectors should be able to also scan the
> current Web page, as well as the text in the search box.
Indeed, it sounds like there are some significant similarities between
data detection in content and rich result detection in search terms. I
would only suggest that we not make implementation of the two features
dependent on each other, since we might build them on different
schedules and with different folks involved.
But we should certainly write common code where appropriate and
implement APIs with an eye to reuse in both features so that the same
piece of code can easily serve as both a rich result provider and a data
detection provider.
-myk
Robert Sayre
>
> Related Feature - Search Engine Results
>
> Google and Yahoo! both provide rich result-like information at the top
> of their search results pages for certain search terms. Yahoo! calls
> the functionality Yahoo! Shortcuts
> <http://tools.search.yahoo.com/shortcuts/>, while Google calls it Google
> Web Search Features <http://www.google.com/intl/en/help/features.html>.
>
> The primary limitation of these server-side implementations as compared
> to rich results is that users have to load an entire search results page
> to see the information.
I'm not convinced that loading a highly-optimized page containing 10
results is a limitation of any consequence, especially when clicking on
the link is likely to lead to a result that downloads something of
significant size.
> A secondary limitation is that there is no
> mechanism for web sites to extend the set of available results and for
> users to take advantage of those extensions.
I don't understand this part. Even so, this doesn't seem like a good
tradeoff, since it adds to the noise of the suggestions, it would take a
lot of engineering effort, and users can already add engines that do
very customized queries.
-Rob
Myk Melez
> Myk Melez wrote:
>>
>> Related Feature - Search Engine Results
>>
>> Google and Yahoo! both provide rich result-like information at the top
>> of their search results pages for certain search terms. Yahoo! calls
>> the functionality Yahoo! Shortcuts
>> <http://tools.search.yahoo.com/shortcuts/>, while Google calls it
>> Google Web Search Features
>> <http://www.google.com/intl/en/help/features.html>.
>>
>> The primary limitation of these server-side implementations as
>> compared to rich results is that users have to load an entire search
>> results page to see the information.
>
> I'm not convinced that loading a highly-optimized page containing 10
> results is a limitation of any consequence, especially when clicking on
> the link is likely to lead to a result that downloads something of
> significant size.
The comparison isn't 10 results vs. rich results but rather 10+rich
results vs. rich results, since search provider implementations include
rich results in their regular search results pages. So the thing of
"significant size" that we download would be just as significant on
search results pages as it would in a submenu of the suggestions menu.
Nevertheless, the primary issue from my perspective is the user
experience. On search results pages, rich results are wedged into an
interface which also offers a bunch of other info that the user isn't
looking for, while rich results in Firefox appear by themselves.
>> A secondary limitation is that there is no mechanism for web sites to
>> extend the set of available results and for users to take advantage of
>> those extensions.
>
> I don't understand this part.
Search providers show rich results from a limited set of sources. When
Firefox users search for "weather 94043" on Google, for example, Google
includes a weather forecast from a single unidentified source in its
search results page.
There are many providers of weather forecasts on the Internet. Some,
like weather.com and wunderground.com, may be popular with Firefox users.
But despite their popularity, and their unique advantages over the
Google forecast, there is no way for those sites to provide their own
forecasts as rich results in Google search results pages, and there's no
way for users to choose those forecasts instead of the Google forecasts.
In Firefox, the rich results feature will bundle a set of high-quality
providers for common kinds of searches (like weather forecasts), but web
sites will be able to provide their own rich results, and users will be
able to choose them over the Firefox defaults.
> Even so, this doesn't seem like a good tradeoff,
> since it adds to the noise of the suggestions,
By default, rich results would add a single item to the suggestions
dropdown, and only when the rich result is likely to be what the user is
looking for, so the signal to noise ratio of this additional suggestion
is high.
> it would take a lot of engineering effort,
The primary engineering effort required of Firefox engineers is in
designing the API and the service that supports it. The actual work of
writing algorithms to parse search terms and provide rich result content
would be the job of content providers, so the effort would be highly
leveraged.
Obviously it depends on one's definition of "a lot", but I think the
effort required is reasonable given the user experience benefits (and
the benefits to sites) which would accrue.
> and users can already add engines that do very customized queries.
Sure, and such engines do provide rich results-like targeted content.
But only for users who install them, and only once users select them for
applicable searches.
A rich results feature would not only give rich results to users without
any need for them to install specialized engines, it would also provide
results from the most relevant engine installed rather than making users
select the engine themselves (which, given the many potential providers
of specialized results, would be burdensome).
-myk
Robert Sayre
>
> The comparison isn't 10 results vs. rich results but rather 10+rich
> results vs. rich results, since search provider implementations include
> rich results in their regular search results pages. So the thing of
> "significant size" that we download would be just as significant on
> search results pages as it would in a submenu of the suggestions menu.
I meant that loading a page of Google results is peanuts compared to
loading a weather.com page, for instance. Cutting out the results page
is not a big win.
> Nevertheless, the primary issue from my perspective is the user
> experience. On search results pages, rich results are wedged into an
> interface which also offers a bunch of other info that the user isn't
> looking for,
I don't think that's always true. Offering a page of varied
HTML-formatted results in response to a short query is why search
engines work.
In the general case, they're much more usable than chrome menus with
cryptic doodads in chrome menus, and adding to the number of indicators
in the chrome has a non-zero usability cost. It's possible users would
enter queries that are longer than necessary to avoid the DWIM dropdown.
>
> The primary engineering effort required of Firefox engineers is in
> designing the API and the service that supports it.
Basically a command line parser, right?
> The actual work of
> writing algorithms to parse search terms and provide rich result content
> would be the job of content providers, so the effort would be highly
> leveraged.
>
> Obviously it depends on one's definition of "a lot", but I think the
> effort required is reasonable given the user experience benefits (and
> the benefits to sites) which would accrue.
I don't think the benefits are obvious, and the feature sets off my
bloat alarm, at least. Why not do this as a Labs project? I definitely
think it's /possible/ this feature could work out well. Why not prove it
first?
- Rob
Myk Melez
> I meant that loading a page of Google results is peanuts compared to
> loading a weather.com page, for instance.
True, but a good weather.com rich result should be much simpler than a
standard weather.com page, although it would probably include a link to
the more detailed page for users who want more info.
> Offering a page of varied
> HTML-formatted results in response to a short query is why search
> engines work.
That's true in general. The idea behind rich results is to provide
direct access to more specific content only when we can determine that
the user is likely to be looking for it.
> In the general case, they're much more usable than chrome menus with
> cryptic doodads in chrome menus, and adding to the number of indicators
> in the chrome has a non-zero usability cost.
Agreed about the non-zero usability cost. That's true of all changes to
chrome, and it's always important to consider, although it's no reason
not to consider and experiment with changes.
But note that, in the general case, we won't be adding any doodads. The
proposal is to only add a doodad in high-value specific cases, and then
only an (arguably) non-cryptic doodad.
> It's possible users would
> enter queries that are longer than necessary to avoid the DWIM dropdown.
We already have the dropdown, so users who don't want it will already be
doing this, and if their numbers are significant, then we should make it
possible (or obvious how) to turn the dropdown off.
It doesn't seem likely to me that merely adding an item to the dropdown
would push the suggestions dropdown over the usefulness event horizon,
especially when the item is as high value as we're aiming for it to be.
>> The primary engineering effort required of Firefox engineers is in
>> designing the API and the service that supports it.
>
> Basically a command line parser, right?
Parsing is the job of the providers, I think. Firefox's job will be to
pass the search terms to registered providers, add an item to the
suggestions dropdown if a provider, after parsing, has rich content for
a search, and display the rich content if the user selects the item.
> I don't think the benefits are obvious, and the feature sets off my
> bloat alarm, at least. Why not do this as a Labs project? I definitely
> think it's /possible/ this feature could work out well. Why not prove it
> first?
Sure, prototyping this first makes sense. We'll just have to make sure
the core suggestions dropdown can accommodate an extension that adds
this kind of functionality.
-myk
Axel Hecht
any way to prevent service providers to create a cat fight in the
drop-down? Like, how would one keep the yahoo movies rich search from
hijacking weather or stocks, too?
IMHO, the UI should at least have an obvious "he's naughty, kill'em"
button to disable the feature for those providers that do more than
expected.
Axel
Myk Melez
> Somewhat out of context, one thing I have been thinking about, is there
> any way to prevent service providers to create a cat fight in the
> drop-down? Like, how would one keep the yahoo movies rich search from
> hijacking weather or stocks, too?
For the set of providers we ship with Firefox, we should have contracts
that spell out what those providers will provide and preclude them from
deciding to start providing something else without our approval.
For providers that users install, the challenge is similar to that for
other addons: figuring out how to make sure users understand what
they're getting by ensuring truth in advertising for provider claims.
Nevertheless, note that some providers might legitimately expand their
capabilities over time. I can imagine that Google and Yahoo!, for
example, would have providers which provide rich results about a number
of different kinds of search terms and add new kinds over time.
> IMHO, the UI should at least have an obvious "he's naughty, kill'em"
> button to disable the feature for those providers that do more than
> expected.
Right. It should be very easy to disable a provider you've installed
(or even one we ship by default).
-myk