MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

The Search contract that makes this happen is composed of a set of interactions between the
Windows-provided Search UI and the search target app. (In this section, when I refer to a target app, I’m
referring now to search, not share.) This interaction communicates the keywords (even if empty) to the
app when the user presses Enter, clicks the icon to the right of the entry field, or changes apps. The
interaction also allows the target app to provide suggested search terms, as well as suggested results
(with result-specific graphics) that appear in the search pane directly, as shown in Figure 12-10.
FIGURE 12-9 The Search pane invoked through the Search charm, with results shown in the Games app and the
Photos app. As with Share, the user can control which apps are shown through Change PC Settings > Search. That
same settings panel also allows the user to clear search history and control a few other aspects of the UI.
Designwise, Search should work with whatever data the app manages, whether local or online (or
both); it’s really the primary means to search within everything that the app can access. For this reason,
Microsoft highly recommends that apps don’t provide their own search UI (which otherwise distracts
from the app’s content) unless it’s really all the app does and where it would need additional search
criteria up-front. Otherwise, it’s best to let the user first search through the charm and then filter, sort,
and otherwise organize the results within the app through on-canvas or app bar commands. On the
515