When users have explicitly requested subsets of information, you must display the resulting narrowed dataset in a meaningful manner.
Returned results may be suitably displayed with page refresh, and as any method you wish, so can work just fine on any platform.
In some cases, part or all of the information subsetting may be implicit or automatic, such as repeated searches and the use of sensors like GPS as some of the input.
The most common type of Returned Results is a simple Vertical List. Additional information, such as the order of results, relevance and domain must be presented as well. Add ons may also be used when relevant, such as Fisheye List or Thumbnail List.
You may also wish to present the information in contextually, as an overlay or add-on to other information visualizations. This may include very small amounts of information, suitable for placing in an Annotation. These results will themselves be points, and may appear over maps, graphs, charts and similar visualizations.
In certain cases, you might want to present prioritized information within the same display type. This may be customized information (e.g. stock information when searching for a company), or paid placement results.
Even if multiple information types are offered the most relevant display type should be presented by default.
Typically, items in the Returned Results list will need to be selected, either as choices for another process, in order to view more details, or to start a process (such as navigating to the selection).
The selection mechanism may be the entire item, or a specific portion of the item display area. Be sure to use the correct type of selection and selection indicator for the process; choice selection will be different from viewing details.
Pagination or Location Within controls and indicators should always be used for list-type displays, and may be relevant for contextual display.
You can display multiple types of results on one page, as overlays, adjacent to each other, or as easily-switchable alternative displays. For example, if a visualization overlay is used, then the results may be more useful for some users as a list. Subsequent or related displays may be shown as adjacent panels of a Slideshow, as Tabs or in other ways which allow the user to quickly flip between data sets.
Modifications to the parameters that resulted in the display of results (such as a text search string), should be easily accessible. They may be on the screen, available as options, or available for direct modification by going "back" to the previous screen. All parameters used, even those that were not directly selected by the user on the initial display of results, should be available for modification. See the Sort & Filter pattern. Less-often, you may wish to use the Search Within widget to further modify the results set.
Display the reason the results have been shown, generally as a Title. If search results are being displayed, the search terms must be printed on the screen.
Number the results, so an order is clear. For devices with support for Accesskeys, make sure the numbers cannot be confused with the accesskey labels. Color, alignment and treatment (e.g. light blue and italics) are generally sufficient ways to differentiate.
When space is available, and the relevance parameters can be clearly communicated, you can display the relevance as additional information with each result. This may be a relevance factor (a percentage is typical), by listing terms that are relevant, or by listing a summary of the information that is most relevant to the result. In additional to this, you can also include the implicit relevance of display methods such as position on a map. Distance from your location, or other physical measures are similar, and you should display them in the same manner.
If the domain is not entirely restrictive (searching only internal documents) or entirely non-restrictive (the whole internet is available) then an indicator of some sort must be placed by each result. Types of documents, when not all the same, should also be displayed, so the user is aware before they attempt to view a movie or download a file.
When information is displayed contextually, it should appear as an Annotation, with a pointer indicating the precise location in the contextual system, and a head which may be selected for information or contain a label of the item.
Paid placement results must be differentiated from the other results. They should not, for example, be numbered with the other results, and you should not count them in the total results in the Pagination or Location Within information.
Availability of the item for selection must be indicated. Whether the entire displayed area for the item is selectable, or only certain portions, an indication of selectability should be present. Each type must be differentiated, so links to view further details appear as links, and selection for a process appears as a choice.
Avoid error conditions for valid entry of information. Displaying errors for no results will dissatisfy the user, so solve the problem for them. Options include
- Expand the search parameters; for local search, change the distance until results appear.
- Correct mis-spellings, but not unless there are few or no results.
- Use common, similar searches to replace results.
- When no results must be displayed, make it clear that none were returned. Do not excessively obscure this message with paid placement, or other helpful information.
In all cases, inform the user on the results display of the changes, and offer an easy method to see the original results.
Use paid placement very carefully. Advertising revenue is a way of life for many products, but make sure items within the results list are at least slightly related to the original intent of the returned results list. Do not use paid placement "results" as a replacement for no returned results. When users figure this out, they will have less faith in all results.
Avoid making parameters too difficult to discover, understand or modify. Try to explicitly state all parameters, even if they are available via other interfaces; e.g. results on a map may have the radius constrained by the zoom level of the map, but this may not be clear unless also available as a search term, or explicitly stated on the results display.
Next: Component Wrapup
Discuss & Add
Please do not change content above this line, as it's a perfect match with the printed book. Everything else you want to add goes down here.
If you want to add examples (and we occasionally do also) add them here.
Make a new section
Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.