Differences between revisions 6 and 7
Revision 6 as of 2011-02-04 01:26:11
Size: 2732
Editor: shoobe01
Comment:
Revision 7 as of 2011-02-05 23:59:13
Size: 6526
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Simple. Search box, whether website or address book, when typed it either jumps to or filters results. Commonly uses autocomplete. NOT the same as location jump at all. This is ONLY applied when already within the results, like a page or infinite list. Not used to search the internet, etc.

ALSO the widget to type a name in an address book, and it jumps to the first location with it (or where it would be, unlike Search Within, never a "no results" state). See search-within for a contrasting widget -- discuss that strictly it's a Location Within, since there are always results, and it just jumps but since there is typing the interaction model is more akin to this pattern.

Line 11: Line 6:
F Even the most common of informational displays on interactive systems can contain impressive amounts of information. Even if a user knows that a particular piece of information is present -- from a web search or from memory -- it may be very difficult to find by simply browsing.
Line 13: Line 8:
It is also implausible to assume that all information-finding may be solved by proper page design. Design of web pages, for just one example, are out of the hands of web browser designers. A method must be provided then to search for information within the displayed information set.
Line 14: Line 10:
Almost all are text search... in some cases, if the information can be categorized, additional or different search criteria may be offered (think feature search in g-maps... restaurants, etc.) Search is in fact exactly what is used. A text search may be placed on the page, and results jumped to or filtered. For mobile devices requiring this feature, the search must more often than not be visible by default, and very often have focus on entry to the page. When of secondary importance, it may be a feature that is explicitly summoned from a menu.
Line 18: Line 14:
1) Explicit submission... like normal search, may find no results, etc. Type a search and enter... used when list cannot be indexed well enough for live results, such as an Infinite List Variations of this pattern are widely dependent on the pattern used to display the information itself.
Line 20: Line 16:
2) Auto results... take off from the Location Jump in many ways, as it works best with indexed results.  1) Live Jumping - The most common, and the oldest style of the '''Search Within''' pattern is especially suited to long lists such as address books, and for scroll-and-select device. When the page is loaded, a search field is in focus. Typing will immediately result in a jump to the results.
Line 22: Line 18:
3) WHAT??? Subvariant for display is search in a web page/PDF style, where results are scrolled through but not all seen at once... SHOULD be AUTO since page is loaded/// all results or each one in turn...  1) Explicit Filtering - Most often used as a replacement for the "live jumping," when explicitly revealed by the user, and very often for touch or pen interfaces. Due to the perception of a conventional search, and the familiarity of many users with web search, this behaves as a filter for the list data displayed, suppressing all other results. The search is typed in it's entirety, then submitted by the user. This may also be more suitable for '''[[Infinite List]]'''' pages, where "live jumping" may have odd-looking delays in the display of some results.
Line 24: Line 20:
A fourth variant is for faceted search, where the user selects items they wish to find from a list of available categories. Consider such cases as restaurants within the current view on a map. Results are much like the 3-XXXX version, with each one highlighted, and a function to see all results or each one in turn.  1) Highlight Results - This is a display method alone, though often explicitly operated, as opposed to being opened by default. The search method should display as live results whenever practical, but use explicit submission when needed, as when the results set is not loaded. These are commonly encountered when searching within web pages, documents or maps. The results only make sense when displayed in context, so are left as such, and indicated.

A key, and increasingly relevant variant of this is non-text faceted search. Other, pre-set parameters are offered for selection and may be used alone or in combination with a text search. This is particularly suitable for maps; a pre-selected list may include resturants, transit, and types of shopping.
Line 28: Line 26:
For scroll & select, starts in focus. Typing will be entered here... therefore, no accesskeys on this page -- can split focus, so first item is in focus for OK selections, and is visually so when first loaded, but typing will be entered into the form field The "live jumping" style of list displays are loaded with a '''Search Within''' entry box anchored to the top of the viewport. On scroll-and-select devices, this has an unusual, almost unique sort of in-focus relationship with the list. The top item in the list is generally in focus, and displayed as such. Pressing "enter" (or sometimes using the Left and Right keys) will commit whichever action corresponds to the line item.
Line 30: Line 28:
However, regardless of the list item in focus, typing from anywhere in the list, at any time, will enter characters into the '''Search Within''' field at the top of the viewport.

A variation is to make nothing appear in focus; the text field behaves in the same manner, but a down scroll is required to bring the first item in the list into focus. When this is used, the top item in any results is still presented as in focus.

This text entry capability will necessarily disable all '''[[Accesskey]]''' functionality.

XXX


Live results vs. explicit submission...

When more than one result is found, controls like a simple '''[[Pagination]]''' widget will be provided, with the total number found, the current position in the results and a method to move between individual results, such as "back" and "next" buttons.

Search methods -- which results are displayed from a particular entry -- are left to the specific implementation, and must consider the way the data set is most naturally used.
Line 33: Line 45:
bring to top when in lists... or just show only relevant search results in a list Display of results must be immediate, and require as little additional user input as possible. Display the number of items found, and the total number of items in the data set, for all lists.
Line 35: Line 47:
for the many-results styles, highlight the results on the page... For the "live jumping" variation, the list is unchanged and simply scrolls so the first relevant result is at the top of the viewport. The remainder of the list is still there, and may be found by scrolling.
Line 37: Line 49:
For the "highlighted results" display variant, each individually-found result will be indicated. Usually, as the namesake would indicate, they are highlighted with an underlying color which contrasts with the background and which allows the text to be readable.

The current result, when multiple highlighted results are available, will be highlighted in a unique manner, and must always be moved to appear within the viewport. Zooming, and other techniques may be automatically employed to assure the result is readable in context if it is not of a readable size or position when the search is initiated.

XXX REFER TO THE POINTER THING FOR MAPS ETC. -- USE THIS WHEN THE INFORMATION IS NOT VISIBLE in the current information display, such as for maps. The THINGY will reveal the info... XXX

Results are generally as close to instant as possible, as the information is already loaded. For certain uses, such as for '''[[Infinite List]]''' displays, there may be a delay for some of the information. This may be confusing for "live jumping" type displays, so instead the "explicit filter" style should be used, and a suitable '''[[Wait Indicator]]''' used for any delays that cannot be avoided.
Line 40: Line 59:
Do not use explicit when the domain is all loaded, such as for a web page... Use the correct method for the information set available. Using an improper method can confuse the user or provide inappropriate or incomplete results.
Line 42: Line 61:
Be careful with what an OK/Enter action performs on AUTO... if user is not looking at screen, they might assume explicit, and press enter without thinking, do not commit to first result and confuse them... Carefully consider what an "enter" key action performs during a "live jumping" search. If the user is not looking at the screen and does not notice the results are already displayed, they can assume an explicit search. If a result is in focus, pressing "enter" may commit an action the user did not intend or which is destructive.

Problem

Finding specific items within a long list or other large page or data array is cumbersome. A method provided to allow searching for information.

Solution

Even the most common of informational displays on interactive systems can contain impressive amounts of information. Even if a user knows that a particular piece of information is present -- from a web search or from memory -- it may be very difficult to find by simply browsing.

It is also implausible to assume that all information-finding may be solved by proper page design. Design of web pages, for just one example, are out of the hands of web browser designers. A method must be provided then to search for information within the displayed information set.

Search is in fact exactly what is used. A text search may be placed on the page, and results jumped to or filtered. For mobile devices requiring this feature, the search must more often than not be visible by default, and very often have focus on entry to the page. When of secondary importance, it may be a feature that is explicitly summoned from a menu.

Variations

Variations of this pattern are widely dependent on the pattern used to display the information itself.

  • 1) Live Jumping - The most common, and the oldest style of the Search Within pattern is especially suited to long lists such as address books, and for scroll-and-select device. When the page is loaded, a search field is in focus. Typing will immediately result in a jump to the results.

    1) Explicit Filtering - Most often used as a replacement for the "live jumping," when explicitly revealed by the user, and very often for touch or pen interfaces. Due to the perception of a conventional search, and the familiarity of many users with web search, this behaves as a filter for the list data displayed, suppressing all other results. The search is typed in it's entirety, then submitted by the user. This may also be more suitable for Infinite List' pages, where "live jumping" may have odd-looking delays in the display of some results. 1) Highlight Results - This is a display method alone, though often explicitly operated, as opposed to being opened by default. The search method should display as live results whenever practical, but use explicit submission when needed, as when the results set is not loaded. These are commonly encountered when searching within web pages, documents or maps. The results only make sense when displayed in context, so are left as such, and indicated.

A key, and increasingly relevant variant of this is non-text faceted search. Other, pre-set parameters are offered for selection and may be used alone or in combination with a text search. This is particularly suitable for maps; a pre-selected list may include resturants, transit, and types of shopping.

Interaction Details

The "live jumping" style of list displays are loaded with a Search Within entry box anchored to the top of the viewport. On scroll-and-select devices, this has an unusual, almost unique sort of in-focus relationship with the list. The top item in the list is generally in focus, and displayed as such. Pressing "enter" (or sometimes using the Left and Right keys) will commit whichever action corresponds to the line item.

However, regardless of the list item in focus, typing from anywhere in the list, at any time, will enter characters into the Search Within field at the top of the viewport.

A variation is to make nothing appear in focus; the text field behaves in the same manner, but a down scroll is required to bring the first item in the list into focus. When this is used, the top item in any results is still presented as in focus.

This text entry capability will necessarily disable all Accesskey functionality.

XXX

Live results vs. explicit submission...

When more than one result is found, controls like a simple Pagination widget will be provided, with the total number found, the current position in the results and a method to move between individual results, such as "back" and "next" buttons.

Search methods -- which results are displayed from a particular entry -- are left to the specific implementation, and must consider the way the data set is most naturally used.

Presentation Details

Display of results must be immediate, and require as little additional user input as possible. Display the number of items found, and the total number of items in the data set, for all lists.

For the "live jumping" variation, the list is unchanged and simply scrolls so the first relevant result is at the top of the viewport. The remainder of the list is still there, and may be found by scrolling.

For the "highlighted results" display variant, each individually-found result will be indicated. Usually, as the namesake would indicate, they are highlighted with an underlying color which contrasts with the background and which allows the text to be readable.

The current result, when multiple highlighted results are available, will be highlighted in a unique manner, and must always be moved to appear within the viewport. Zooming, and other techniques may be automatically employed to assure the result is readable in context if it is not of a readable size or position when the search is initiated.

XXX REFER TO THE POINTER THING FOR MAPS ETC. -- USE THIS WHEN THE INFORMATION IS NOT VISIBLE in the current information display, such as for maps. The THINGY will reveal the info... XXX

Results are generally as close to instant as possible, as the information is already loaded. For certain uses, such as for Infinite List displays, there may be a delay for some of the information. This may be confusing for "live jumping" type displays, so instead the "explicit filter" style should be used, and a suitable Wait Indicator used for any delays that cannot be avoided.

Antipatterns

Use the correct method for the information set available. Using an improper method can confuse the user or provide inappropriate or incomplete results.

Carefully consider what an "enter" key action performs during a "live jumping" search. If the user is not looking at the screen and does not notice the results are already displayed, they can assume an explicit search. If a result is in focus, pressing "enter" may commit an action the user did not intend or which is destructive.

Examples

Search Within (last edited 2011-07-31 22:08:38 by shoobe01)