Search/Rich Results: Difference between revisions

clarify text, add info on extensibility, and propose PRD items
(first version of Rich Results proposal)
 
(clarify text, add info on extensibility, and propose PRD items)
Line 1: Line 1:
== Summary ==
== 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.
The goal of the rich results feature is to improve the speed, relevance, and usability of search when used to find a specific piece of information by providing users with a way to go directly to that information when it seems likely, based on the terms they enter into the Firefox search box, that the specific information we can direct them to is the information they are looking for.




Line 17: Line 17:
== Implementation ==
== 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.
The implementation consists of a Firefox API that lets extensions, core code, and web sites register as rich result providers.  When a user types search terms into the search box, Firefox queries registered providers for available rich results.


If the user selects a rich result from the menu, we display the result in some appropriate part of the interface.  In the current [http://wiki.mozilla.org/Search#The_Plan_.28So_Far.29 proposal for improvements to search], 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.
Firefox then provides an item in the Search History/Suggestions dropdown 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 [http://wiki.mozilla.org/Search#The_Plan_.28So_Far.29 proposal for improvements to search], this is a popup submenu of the History/Suggestions menu, 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.
Providers may use a variety of mechanisms to determine whether they can provide a rich 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 variety of ways, generating it on the fly 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.
The rich result itself can be any type of content that Firefox knows how to render, including plain text, an HTML page, XML transformed by XSLT, and images.
 
We would ship with a set of high-quality providers for a variety of common searches, and users could add providers by installing extension providers from addons.mozilla.org or web site providers from the web sites they visit.
 
The difference between these two types of add-on providers is that extension providers, like other extensions, would have full access to the browser chrome (including the ability to query arbitrary domains), while web site providers would have no access to browser chrome and would be limited to querying their own site.


== Related Features ==
== Related Features ==
Line 52: Line 56:


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.
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.
== Proposed PRD Items ==
FR create API for registering as provider, being queried with search terms, and providing results
FR query providers on entry of search terms into the search box and provide results as items in the Search History/Suggestions dropdown menu
NFR ensure extensibility of Search History/Suggestions dropdown menu to accommodate rich result items
canmove, Confirmed users
2,056

edits