IE 7 introduced a popular feature called Instant Search. This places a search box into the top-level browser chrome, enabling fast access to search without having to first navigate to the URL of a search engine.
In this chapter I discuss how you can easily build traditional search providers and visual search providers for your site or third-party services. I begin by discussing the OpenSearch specification, followed by the format and structure of search providers. I follow this up with a walkthrough of using OpenSearch to construct a basic search provider. Next up are visual search providers, where I discuss the process of building this enhanced extension for IE 8 and higher. I end the chapter with some guidelines and advanced topics, touching on issues such as user preferences and external installation options.
Search providers are a simple extension that provides a powerful search experience within the browser frame. IE completely manages the experience for users and developers, cutting down on development time and providing a consistent, predictable experience for endusers (Figure 9-1).
The search box is located in the top-rightcorner of the browser, next to the address bar. This prominent location is easily accessible and allows a user to easily perform the common task of searching without having to directly access a provider first. Users can quickly focus on the box by pressing CTRL+L.
The Quick Pick menu, shown in Figure 9-2, allows users to quickly switch between search providers without having to leave the Inline Search area. When text is entered into the Inline Search box, the drop-down displays with icons referencing as many search providers as can fit in the given space. Clicking one of these icons will reroute a search query to the chosen search provider. The Find button brings up the page-search toolbar, allowing users to search content within the current page rather than sending a search query to a search engine.
Search providers may optionally support search suggestions. Search suggestions are proposed queries returned from a search provider as data is typed into the Instant Search box. Providers that implement this feature are sent the current contents of the Inline Search text box as a user types in a query. Providers may return result sets, which are shown in the drop-down above the Quick Pick menu. Figure 9-3 shows an example of search suggestions returned from the ESPN.com search provider; a query of "LeBron" returns four possible results for the query as typed.
Search suggestions can help to refine search queries before they're executed, with the goal of cutting down the amount of time it takes for users to search a given topic (much like the inline autocomplete present on modern operating systems and Ajax-based web sites).
IE 8 introduces another form of search suggestion, called visual search suggestions. As the name implies, visual search suggestions return rich suggestions alongside text-based search suggestions. Figure 9-4 highlights the visual search suggestions for a query of Wikipedia with the term "Aleister."
Figure 9-5 shows the Inline Search context menu. The listing order of extensions is controlled by the Internet Options control panel item. The "Find on this Page" menu item directs the current query in the Inline Search box to the inline find toolbar for the current page, allowing users to apply the query to contents of the current tab rather than to an external search engine. The "Find More Providers" option launches the IE Add-Ons Gallery, allowing users to find and install more search providers into IE. Last, the Manage Search Providers command launches the Search Providers pane of the Manage Add-Ons dialog, giving users an opportunity to manage current search provider settings, set defaults, or uninstall providers.
As mentioned earlier in this section, IE provides an easy-to-use management system for search providers. When a user or site attempts to install a search provider, the search provider management dialog launches to inform a user of the pending action (Figure 9-6, left). Because search providers are a nonbinary extensibility mechanism, they are safer than traditional add-ons, and no additional security dialogs are shown.
Installed search providers can be managed and removed through the Manage Add-Ons dialog, a simple interface exposing the metadata and settings for each search provider (Figure 9-6, right).
Figure 9.6. Search Provider installation dialog and search provider management through the Manage Add-Ons dialog
The IE Add-Ons Gallery offers a complementary experience to the management experience provided in the browser. Found at www.ieaddons.com, the gallery allows users to find and install search providers they may be interested in (Figure 9-7).
This section highlighted the high-level experiences that search providers provide to a user's IE configuration. The next sections highlight the methods and means developers can use to implement the features described here.
The OpenSearch Description Format (OSD) schema defines the markup used to create search providers for IE and other modern browsers implementing search providers. This allows client applications such as browsers to integrate web services into an application itself without requiring a user to manually visit a search engine or other searchable web service provider. The JSON Search Suggestions and XML Search Suggestions specifications are extensions to the OSD that allow applications to query web services for intermediate search data that can provide a user with a subset of results; the most well-known example of comes with the text-based autocomplete features used by many modern operating systems and Ajax-based web sites.
The following sections outline the structure and basic uses of the OSD, JSON Search Suggestions, and XML Search Suggestions specifications. Understanding their use is key in building both basic and advanced search provider extensions for use in IE.
The OpenSearch Description (OSD) Format specification defines a format for sharing results between asearch engine and a consuming application. IE 7 and aboveallow web sites to expose their search capabilities by describing them using OSD files that the browser uses to extend the browser's search box.
The most basic search provider, shown in Listing 9-1 can be created with less than ten lines of XML markup! Such providers contain basic metadata such as a short name, description, tags, contact information, and the URL pointing to the search engine provider. This example is from OpenSearch.org.
Example 9.1. A Simple OpenSearch 1.1 Draft 4 Description File, As Shown on OpenSearch.org
<?xml version="1.0" encoding="UTF-8"?> <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"> <ShortName>Web Search</ShortName> <Description>Use Example.com to search the Web.</Description> <Tags>example web</Tags> <Contact>[email protected]</Contact> <Url type="application/rss+xml" template="http://example.com/?q={searchTerms}&pw={startPage?}&format=rss"/> </OpenSearchDescription>
More complicated search providers are still relatively simple to develop compared to other IE extensions. Listing 9-2 shows a more complicated example using most of the tags and some extensions defined by the OpenSearch specification. As one can see, even this more complicated extension is relatively simple to construct and easily understood given the declarative nature of the markup.
Example 9.2. A Detailed OpenSearch 1.1 Draft 4 Description File, As Shown on OpenSearch.org
<?xml version="1.0" encoding="UTF-8"?> <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"> <ShortName>Web Search</ShortName> <Description>Use Example.com to search the Web.</Description> <Tags>example web</Tags> <Contact>[email protected]</Contact> <Url type="application/atom+xml" template="http://example.com/?q={searchTerms}&pw= {startPage?}&format=atom"/> <Url type="application/rss+xml" template="http://example.com/?q={searchTerms}&pw={startPage?}& format=rss"/> <Url type="text/html" template="http://example.com/?q={searchTerms}&pw={startPage?}"/> <LongName>Example.com Web Search</LongName> <Image height="16" width="16" type="image/vnd.microsoft.icon"> http://example.com/websearch.ico</Image> <Query role="example" searchTerms="cat" /> <Developer>Example.com Development Team</Developer> <Attribution> Search data Copyright 2010, Example.com, Inc., All Rights Reserved </Attribution> <SyndicationRight>open</SyndicationRight> <AdultContent>false</AdultContent> <Language>en-us</Language> <OutputEncoding>UTF-8</OutputEncoding> <InputEncoding>UTF-8</InputEncoding> </OpenSearchDescription>
OpenSearchtags are used to define the metadata for an OpenSearch search provider. Each tag provides a unique element of metadata for a search provider. The root tag for an OSD document is the <OpenSearchDescription> element; all other tags in an OSD file are children of this tag. Table 9-1 defines the tags that may be used in an OSD file to define a search provider extension.
Table 9.1. Tags Used by the OpenSearch Description Format to Define a Search Provider Extension
Tag | Parent Tag | Description | Required |
|---|---|---|---|
|
| Root tag of an OpenSearch provider. The element must appear once and only once per document and may be the only element (besides the XML file header) at this level. | Yes |
|
| A brief title that identifies the search provider, containing 16 characters or less. The element may only appear once. | Yes |
|
| Description of the search provider containing 1,024 characters or less. The element must appear exactly once. | Yes |
|
| The URL by which the browser interfaces with the search provider. This element must appear at least once. | Yes |
|
| The e-mail address of the maintainer of the search provider. The element may be used only once. | No |
|
| A set of words describing the purpose of the search provider; a list of categories delimited by a space whose overall text length is less than 256 characters. It may be used only once. | No |
|
| A long title that identifies the search provider, containing 48 characters or less. It may be used only once. | No |
| URL that identifies an image that can be associated with this search provider. Must point to an image whose MIME type is supported by the browser. This is represented by a 16×16-pixel icon with a MIME type of either image/x-icon or image/vnd.microsoft.icon. | No | |
|
| An example query that is shown to users. It may be used one or more times. | No |
|
| The name identifying the creator of a search provider; contains 64 characters or less. It may be used once. | No |
|
| A list of all sources that are responsible for the content returned by the search provider;contains 256 characters or less. It may be used once. | No |
|
| A value indicating the copyright of content returned by a search provider. It may be used one time. | No |
|
| A Boolean value indicating whether or not results returned by a search provider include "adult content. "The term "adult content" used by the specification is vague and does not represent a universally defined term, rather a "good-faith effort to indicate when there is a possibility that search results may contain material inappropriate for all audiences," according to the OpenSearch specification group. It may be used one time. | No |
| String indicating the languages that a search engine used by a search provider supports. The value must conform to the language identifiers and formats described in both the XML 1.0 Language Identification specification and RFC 3066. This element should exist once for every language supported, but this element is not required. | No | |
|
| Like the language tag, this element exists zero or more times and indicates the output formats (such as UTF-16) supported by the search provider. The default value is | No |
|
| Following the same concept as the | No |
The OpenSearch description file begins with the root tag, <OpenSearchDescription>. This tag signals to the browser or other client that the file is beginning. This element contains all other tags used by the OSD file, occurs only once, and must be closed at the end of any OSD file.
The <ShortName> tag defines a short name used by a browser or other client. It allows for quick identification of a search provider extension. This text contained within this tag must be 16 characters or less in length.
Search providers may describe their purpose through the <Description> tag. Text within this tag informs users of the purpose of a specific search provider extension.
The <Url> tag specifies the URL by which the browser interfaces with the search provider. The <Url> tag is used by IE to link a search query. The values contained within this element point to search results or search suggestions. Table 9-2 shows the attributes that can be placed within the <Url> tag.
Table 9.2. Attributes for the <Url> Tag in the OSD Specification
The attributes of the <Url> tag define the external resource IE will use for a search query. The template attribute (detailed later in this section) defines a URL template used by the browser to send query information placed into the search box to a service. The type attribute specifies the MIME type of the external resource. The role of the resource is defined through the relattribute. indexOffset highlights the index number of the first search result from the web service. Finally, the pageOffset attribute defines the page number of the set of results where the first result is located (with respect to the web service returning the data).
The <Contact> element represents contact information of the developer or maintainer of the search provider an OSD file defines. This optional element should be coded in the form of an e-mail address (whose format is defined by RFC 2822).
A search provider may use the optional <Tags> element to list a number of single-word, space-delimited descriptors that define the intent and purpose of a search provider.
The optional <LongName> attribute allows a search provider to expose a longer version of the short name identifier specified in the required <ShortName> tag. This tag may contain text up to 64 characters in length.
Developers wishing to provide a visual tag for their search providers can do so through the <Image> tag. This tag is used once for every size image offered to clients displaying images associated with a search provider. The URL where the image can be found is set as the inner text of this tag. Table 9-3 highlights optional attributes developers may set when defining an image.
Table 9.3. Attributes for the <Image> Tag in the OSD Specification
Description | Default Value | Required | |
|---|---|---|---|
| The height of the image in pixels. This must be a nonnegative integer, but the attribute itself is optional. | None specified | No |
| The width of the image in pixels. This must be a nonnegative integer, but the attribute itself is optional. | None specified | No |
| The MIME type of the image returned by its source. The string of this attribute must represent a valid MIME type that is recognized by the client; however, the existence of the attribute itself is not required. | None specified | No |
Each image tag has three optional attributes. The width and height attributes define the width and height of an image in pixels. The MIME type of the image may be specified using the type attribute. Developers who wish to have their search provider displayed properly in IE should include an <Image> tag pointing to a 16×16-pixel icon with a MIME type of either image/x-icon or image/vnd.microsoft.icon.
Search providers can define the search requests a client may perform by way of the <Query> tag. The element attributes of each query tag correspond to the search parameters used by URL templates contained in <Url> tags. IE does not use this tag as part of its Search Provider specification.
The <Developer> tag reveals the entity responsible for creating (and potentially updating) the search provider. It may contain any plain text that is 64 characters or less in length.
Developers may use the <Attribution> tag to list all sources that should be credited for content displayed in the search field. This text can contain any form of copyright information as long as it contains 256 or fewer characters of text.
Search provider extensions flag their content for clients when their return content might not be appropriate for all audiences. The <AdultContent> tag, which is optional (and not recognized by IE), may contain a value of either true of false; true signifies that content returned by a provider may not be appropriate for all audiences. Audience inappropriateness is not clearly defined by the OSD specification and should be used by developers at their own discretion.
The <Language> tag allows a search provider to tell IE or another client what languages are supported by the extension. This tag is not required, and the absence of it signifies a language- or culture-neutral search provider. If a search provider supports all languages, it may include a language tag with the inner text of *. For specific languages, one language tag should be present for each language supported by a search provider.
The <InputEncoding> and <OutputEncoding> tags specify the input and output encodings supported by a search provider.
URLs specified within the <Url> tag contain one or more template variables. Template variables allow browsers or other clients to substitute these values for values entered by users or computed by the client. Table 9-4 shows the variables that may be used in the template attribute of the <Url> tag.
Table 9.4. Template Variables Used by the <Url> Tag
Description | Restrictions | Required | |
|---|---|---|---|
| Replaced with the search terms specified by a user in the browser. | Must be URL-encoded | Yes |
| Allows a web service to determine what UI element was used for the query. In IE, one of two values may be returned: | None | No |
| The number of search results per page to return to the browser. | Must be a nonnegative integer | No |
| The index of the first search result to show. | Must be an integer | No |
| The page of the first search result to show. | Must be an integer | No |
| The desired language for the results be returned in. | Must have a value that conforms to the language identifiers and formats described in both the XML 1.0 Language Identification specification and RFC 3066 | No |
| String indicating the character encoding used by the browser for this search request. | Must conform to the formats defined in the XML 1.0 Character Encodings specification and the IANA Character Set Assignments specification | No |
| String indicating the character encoding desired by the browser for responses back from the search provider's web service. | Must conform to the formats defined in the XML 1.0 Character Encodings specification and the IANA Character Set Assignments specification | No |
The OpenSearch Description format provides a loose structure whose core is geared toward a simple definition of a search provider. This simple nature and loose structure also affords it the property of being a very rich platform that can be extended and customized by individual clients (hopefully with the ultimate goal of integrating extensions into the mainstream specification).
IE uses two major OpenSearch extensions that enhance the overall search provider experience in the browser: the JSON Search Suggestion and the XML Search specification extensions. As these names imply, the extensions used by IE allow users to receive search suggestions before a full query is executed. The next two sections describe how IE uses these extensions to implement search suggestions within the browser frame; later sections in this chapter provide concrete examples of how developers can implement these features in real-world extensions.
Developers looking to build more powerful platforms using the OpenSearch Description format can start by investigating the extensions that already exist on the OpenSearch web site, www.opensearch.org.
The JSON Search Suggestion extension is an extension to the OpenSearch Description format that allows a web service to return text-based suggestions for a search provider. Clients such as IE display these search suggestions during the construction of a query. IE displays data returned through this mechanism while a user is typing in the Inline Search box.
This extension is constructed using the JSON (JavaScript Object Notation) format. The basics of this notation are described in earlier chapters. Table 9-5 describes the values, types, and description used in this format.
Table 9.5. JSON Search Suggestion Extension Values and Descriptions
Value | Type | Description | Required |
|---|---|---|---|
| String | Search term requested by a user | Yes |
| Array | Text-based search suggestions for the specified query | Yes |
| Array | Alternate information about the specified query | No |
| Array | List of URLs that should be used if a user clicks a specific search suggestion | No |
The actual format is stored in a JSON structure like that in Listing 9-3. The first entry is the query entered by the user. The next value is an array of completion suggestions; these represent completed search entries for which the query matches. Next is an array containing the descriptions of these matches—values whose index corresponds to the associated completion index. Last is an array containing the associated URLs for these matches (again, with indexes matching the associated completion index.)
The XML Search Suggestionsspecification is an extension to the OpenSearch Description format that allows an application to receive rich search suggestions from an online service. Much like the JSON Search Suggestion extension, search suggestions generated using this extension are displayed to a user before a query is performed and represent results returned from a web service based on an incomplete query. In the case of IE, this incomplete query represents a set of text in the Inline Search box that may or may not be completed.
Listing 9-4 is an example XML Search Suggestion file provided by Microsoft on the home page of the XML Search Suggestions specification page. In this example, a query of "xbox" returns a number of responses in the form of both text-based and visual suggestions.
Example 9.4. An Example XML Search Suggestion File Provided by the Specification on MSDN (www.msdn.com)
<?xml version="1.0"?>
<SearchSuggestion xmlns ="http://schemas.microsoft.com/Search/2008/suggestions">
<Query>xbox</Query>
<Section>
<Separator title="My Visual Suggestions"/>
<Item>
<Text>Xbox 360 Live Games</Text>
<Image source="http://www.example.com/live.jpg"
alt="Xbox 360 Live Games" width="75" height="75"/>
</Item>
<Item>
<Description>Game console systems and packages at a great deal.</Description>
<Image source="http://www.example.com/xboxconsole.jpg"
alt="Xbox 360 Consoles" width="75" height="75"/>
<Url>http://www.example.com/games.aspx?q="Xbox 360"</Url>
</Item>
<Separator title="My Text Suggestions"/>
<Item>
<Text>Xbox 360</Text>
</Item>
<Item>
<Text>Xbox cheats</Text>
<Description>Codes and walkthroughs</Description>
</Item>
<Item>
<Text>Xbox 360 games</Text>
<Description>Games and accessories</Description>
<Url>http://www.example.com/games</Url>
</Item>
<Separator />
<Item>
<Text>xbox 360 lowest price</Text>
</Item>
<Item>
<Text>xbox 360 news</Text>
</Item>
</Section>
</SearchSuggestion>Items in this example are contained within a section and are separated out by type; here, the query returns visual results under the label "My Visual Suggestions" and text-based results under the label "My Text Suggestions."
As with the OpenSearch Description Format specification, the XML Search Suggestions specification employs a tree-based structure whereby XML tags define the suggestion items returned to the browser. Table 9-6 highlights the tags and ownership structure for those tags used in an XML Search Suggestion file.
Table 9.6. Tags Used by the XML Search Suggestions Specification to Define Search Suggestion Results Returned by a Web Service
Tag | Parent Tag | Description |
|---|---|---|
|
| Root tag of an XML Search Suggestion file. There may only be one instance of this element. |
|
| Text query that was sent by the client application. There may only be one instance of this element. |
|
| Tag containing a set of items returned to the client as search suggestions. There may only be one instance of this element. |
|
| Element that represents a single suggestion. There may be one or more instances of this element, and all instances must contain a |
|
| A text-based suggestion that is part of an overall suggestion |
|
| The URL that a client will navigate to when a suggestion |
|
| A description of the search suggestion. There may be only one instance of this tag for each |
|
| Contains an image suggestion for a suggestion |
|
| Indicates the start of a group of suggestions. There may be one or more instances of this tag, though none are required. |
An XML Search Suggestion file begins with a parent tag <SearchSuggestion>. This tag informs the browser or other application accepting this format that the search suggestions are contained within this file. This must be the first tag of the file, the file must end with its closing tag, and there may be only one of these tags in a Search Suggestion file.
The <Query> tag is the first child item under the <SearchSuggestion> root. The text contained by this tag represents the query that was sent to a web service by a client application.
The <Section> tag encapsulates the set of search suggestions returned by a web service. This tag contains one optional attribute, title, described in Table 9-7. The title attribute reflects the title of the overall set of search suggestions returned by a web service.
Table 9.7. Attributes for the <Section> Tag in the XML Search Suggestions Specification
Attribute | Description | Default Value | Required |
|---|---|---|---|
| Represents the title of the overall search suggestion results returned by a web service | Empty string | No |
Individual search suggestions are defined through the <Item> tag. The content of each suggestion, be it text or image, is enclosed within this tag.
The <Text> tag represents the text that corresponds to a search suggestion item. For instance, a search on "xbox," as shown in the previous example, might return an entry with the text"XBOX 360 Brand New $100."
The browser will navigate to a URL associated with an item when that item is clicked; this URL is defined through the <Url> tag. This tag specifies a target address that should be navigated to whenever the search suggestion is clicked by a user.
The <Description> describes an item. This optional tag may be used by clients to provide extended information on a suggestion. IE 8 displays this information below the text for a search suggestion item when shown in the Instant Search drop-down box.
Items can contain a descriptive image defined through the <Image> tag. This tag is optional but may appear at most once within an item tag. Table 9-8 defines the attributes associated with this tag.
Table 9.8. Attributes for the <Image> Tag in the XML Search Suggestions Specification
Attribute | Description | Default Value | Required |
|---|---|---|---|
| The URL of the image to be used. | None specified | Yes |
| Alternate text for the image. | None specified | No |
| Width of the image in pixels. | None specified | No |
| Height of the image in pixels. | None specified | No |
| The preferred vertical alignment for the image. Possible values are top, middle, or bottom. | Top | No |
The location of an image is specified by a URL in the source attribute. Alternate text for the image—especially important for accessibility use by the client—may be specified in the alt attribute. The width and height attributes specify an explicit width and height for the image in pixels. Lastly, the align attribute allows a developer to set a preference for vertical alignment of an image with respect to its associated text and description; by default, it is shown next to the top of a corresponding text block in IE.
<Separator> is the last tag defined by this specification, representing a physical separation between groups of <Item> tags. This allows users to visually organize results returned by a web service into logical groups.
The <Separator> tag has one attribute, title, defined in Table 9-9. The title attribute contains text that is displayed as part of the physical separator between <Item> instances. Developers can compare this to the title shown as part of a panel (Java) or group box (Windows Forms and Delphi).
The process of building a basic search provider is simple—developers can construct a new search provider pointing to an existing web service with just a handful of XML tags!
Simple search providers can be built to direct users to existing web services. In a nutshell, this means developers can add search providers to complement their web sites without changing a single line of code.
An example of a basic search provider would be one that allows developers to search a programming information site such as Stack Overflow. This search provider uses an OSD file to direct IE's search box to an existing web service—in this case, the Stack Overflow search page. Listing 9-5 shows an example provider that lets a user search Google. com from the browser's search box.
Example 9.5. A Search Provider That Directs a Query to Stack Overflow (www.stackoverflow.com)
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
<ShortName>Example: Stack Overflow</ShortName>
<Description>Search Stack Overflow for programming topics</Description>
<InputEncoding>UTF-8</InputEncoding>
<Url type="text/html" method="get"
template="http://www.stackoverflow.com/search?q={searchTerms}"/>
</OpenSearchDescription>IE offers a streamlined installation and management experience for both developers and endusers. Developers wishing to surface search providers on their pages can do so through both a <link> tag and a function exposed on the window.exernal JavaScript object. Users can install search providers either through the Instant Search box's context menu or through links on pages that implement a call to the relevant JavaScript function. The following sections describe both the developer and user experience for surfacing, installing, and managing search providers.
The search provider installation experience is managed by IE. This allows developers and users to take part in the installation process and provides a consistent experience for all search provider extensions. This installation process is kicked off by a call to the window.external.AddSearchProvider function; the URL passed to this function is the location of the OSD file targeted for installation. This is shown in Listing 9-6.
Example 9.6. Code Used to Request Search Provider Installation, in This Case in Response to an onclick Event
<a href="#"
onclick="window.external.AddSearchProvider('http://www.textd.com/crowley/sp/StackOverflow.xml'
)">Add the Stack Overflow Search Provider Example</a>Figure 9-8 demonstrates the installation dialog presented to users when installing the Stack Overflow search provider from the last section. Users have the option to make a search provider their default and, if the add-on allows, to use search suggestions returned from a provider's target web service.
Once installed, this search provider is shown in the drop-down menu of the search box, and its icon is added to the Quick Pick menu (see Figure 9-9). If the search provider was selected to be the default search provider, it is shown at the top in bold lettering, and its name is preceded by the text "(Default)."
When a search query is placed into the search box, the URL template (defined in the template attribute of the <Url> tag in the previous section) is filled in and navigated to. Figure 9-10 shows the result of the query "Search Provider XML" being passed to the web service from this search provider.
IE allows search providers to be discovered through the browser frame. Web pages can let users know that search providers are offered on the page through a <link> tag. The browser will notify users that a search provider is available on those pages by changing the color of the Inline Search drop-down chevron (Figure 9-11).
Users who click this chevron will notice a drop-down menu that includes new search providers that are offered on the current page (Figure 9-12).
Developers can place <link> tags on a page to reveal search providers in this way. The link tag has four attributes, as described in Table 9-10.
Table 9.10. Attributes and value information for surfacing a search provider via an HTML <link> tag
Attribute | Description | Required |
|---|---|---|
| Title of the search provider. This typically corresponds to the text specified in the | Yes |
| Defines the relationship of the linked object to the current page. This value must be " | Yes |
| MIME type indicating that the value contained by the link tag refers to a search provider. This value must be " | Yes |
| URL pointing to the OSD file for the search provider. | Yes |
Search providers are managed by end users once installed on a system. Users can manage search providers through the Search Providers pane of the Manage Add-Ons dialog. This pane is shown in Figure 9-13.
Each installed search provider is listed in a list box contained within the Search Providers pane. The default provider is listed at the top and has a listing order of 1. Each subsequent provider is listed below it in the order it was installed; each listing order number is increased sequentially for each.
Detailed information, metadata, and commands for the selected search provider are shown in the Details pane below the list of search providers. The detailed information and command set includes the following:
Status: Information on whether a search provider is selected as default.
Search address: The URL used when executing a search from the Inline Search box.
Search suggestions: Information regarding whether search suggestions for a specific search provider are allowed (enabled) or not (disabled).
Search suggestions address: The address used by a search provider when returning search suggestions for a partial query typed into the Inline Search box. When a search provider contains only text-based suggestions, this URL represents the URL pointing to a JSON Search Suggestion result. When a search provider uses enhanced visual suggestions or both text-based and visual suggestions, this link refers to the URL returning data conforming to the XML Search Suggestions specification.
Listing order: Allows a user to move the current item up or down, or sort all items (save for the default item) by alphabetical order instead of order of installation.
Prevent programs from changing my default search provider: Prevents applications from editing the registry to change a user's selected default search provider.
Set as default: Sets the currently selected provider as the default search provider.
Remove: Uninstalls the currently selected provider.
Enhanced search suggestions can be returned using XML that conforms to the format laid out in the XML Search Suggestions specification outlined in the second section of this chapter. IE 8 introduced this open specification in an attempt to enhance the data returned during web searches made through the Inline Search box.
Search providers are simple on their face, mostly since IE abstracts the installation, management, instantiation, and running of these providers. Search providers can be customized more fully by examining the options available both internally (how IE manages these add-ons) and externally (how the overall system built by Microsoft can be used to promote and surface these extensions). The following sections shed light on both of these areas.
The OpenSearch Description format allows developers to not only build powerful web service extensions for IE, but also extensions that work across multiple browser. Search providers that properly conform to the OSD may be used in other browsers that support the schema.
At the time of writing, search providers written using OSD can be installed and loaded within IE 7+, Firefox 2.0+, and Google Chrome. Each browser supports its own subset of XML tags defined by this format, so some features discussed in this chapter may not be available in those browsers. Developers should consult developer documentation for each browser manufacturer to ensure that cross-browser search providers allow for a consistent experience across clients.
The IE Add-Ons Gallery (www.ieaddons.com) provides a way for developers to promote their add-ons online. The gallery is a web site that puts many types of IE add-ons (search providers, Accelerators, toolbars, etc.) in one location. It presents these add-ons to users, categorized by their add-on type and goals. Users can download and install add-ons directly from the web site.
Add-ons posted to the gallery web site are not immediately available to users. Developers' add-on submission and metadata (such as description and home page) are passed to Microsoft for approval. Microsoft employees and contractors hand-check the provided information, install the add-on, and reply back (typically) within a few business days regarding the acceptance or rejection of an upload. If accepted, an add-on is available for download by all users of the web site.
Developers looking to place their add-on onto this web site must signup for and loginto an account on the gallery home page. Figure 9-14 shows both the signup an login pages on the gallery site. The account information here is not linked to a Microsoft Live ID account used across other Microsoft properties; the username and password entered here are specific to the gallery.
The Your Account page—accessible after the previous process is complete—has two main functions: showing the add-ons currently being offered by the developer and providing a way for developers to submit a new add-on for approval. Figure 9-15 shows this page.
New add-ons can be posted to the gallery by way of the Upload Now button on this page.
The Gallery Upload page presents developers with a number of fields that can be used to describe the add-on. For each add-on type (in this instance, a search provider), developers can upload the corresponding add-on file in the appropriate field. Figure 9-16 shows this page.
The information provided here serves two purposes: to aid the Microsoft representative in a control's approval process by providing context for the add-on, and to aid users of the IE Add-Ons Gallery web site in making informed decisions about which add-ons to download. For reference, Table 9-11 describes the fields provided for search provider extension uploads.
Table 9.11. Metadata Fields for Describing an Add-On During the IE Add-Ons Gallery Upload Process
Item | Description | Requirements | Required |
|---|---|---|---|
Name | Name of the search provider | No more than 40 characters, and no HTML tags are supported. | Yes |
Tagline | One-sentence description (tagline) of the search provider | Less than 275 characters | Yes |
Description | Description of the search provider | No more than 450 characters and no HTML tags. | Yes |
Home page URL | Home page containing information about this search providers | Valid URL. | Yes |
Screenshot | Screenshot of the search provider in action | The image should be in JPG, PNG, GIF, or BMP format. It can be any size, but the higher resolution, the better. The optimal image size is 380×250 | Yes |
Language | Target language (locale) of the search provider | Only one language may be chosen per submission. | Yes |
Type | Type of the add-on (in this case, the "Search Provider") | One and only one type must be specified. | Yes |
OSD file | XML definition file of the search provider (OSD file) | One and only one OSD file must be uploaded. | Yes |
Categories | One or more categories the search provider falls under | At least one category must be chosen. | Yes |
The preview section at the bottom of the upload page shows a developer how the entry for this new add-on may look when shown on the gallery web page (assuming it is approved). The best use for this (given the feedback the preview provides at the time this text was written) is to ensure that the name and the image indicated in the fields of this page accurately represent the add-on. Figure 9-17 shows an example of the preview pane.
Once this information is entered, developers may click the submit button for approval. Again, developers using this process should expect a response by a Microsoft representative evaluating the add-on within a few business days.
Application installers may add search providers as part of an installation process. Microsoft discovered that, more often than not, these installers do not clearly ask users if they want their chosen search provider changed before editing their settings. IE 8 introduced a new feature called User Preference Protection, a system that protects the default search provider that a user chose either during the browser's first run experience, via the search engine drop-down, or via the Manage Add-Ons dialog box.
User Preference Protection watches for a change in the registry keys where search provider information is stored. If these settings are changed in any way outside of the three in-browser methods previously stated, the browser displays a dialog box informing the user of these changes (Figure 9-18).
Users have the option of accepting the changes or reverting back to their original preferences. This system ensures that applications do not "hijack" the search default without getting the user's permission.
Search providers are a great way for developers to expose functionality of their web services consistently in IE's frame. This means that users can access a web site or search engine without having to actually visit it—a powerful concept that may very well be the future of the Web.
In this chapter, I showed you how easy it can be to create search providers that give your web application this powerful functionality and allow you to extend your web application right into the IE browser frame. I began by describing the user experience flows associated with search providers, followed by a deep dive into the tags and variables associated with the two XML-based specifications used by them: then OpenSearch and XML Search Suggestions specifications. I then discussed how you can easily build a basic search provider, followed by an explanation of the installation and management process for these extensions. Next, I covered how you can extend search provider functionality using both text-based and image-based search suggestions. I concluded this chapter with some more advanced topics such as User Preference Protection.