canmove, Confirmed users
2,056
edits
(first version of Rich Results proposal) |
(clarify text, add info on extensibility, and propose PRD items) |
||
| Line 1: | Line 1: | ||
== Summary == | == Summary == | ||
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 == | ||
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 | 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 | 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 | |||