Alphabetic Listings (Long)

From MobileDesign

Sometimes the list of results is quite long; principles and patterns for shorter lists will not work well. Instead, a pattern should be used to assist the user in finding the right information. Compare this solution to Autocomplete (advanced).

[edit] Design

Provide a text entry box allowing the user to type a few letters in the item's name. Return all items starting with the typed letters, followed by all items with that string within the name. If possible, return list results while the user is typing, without need for an explicit submission.

Results of the typing will be in a conventional list. Assure this sub-list is acceptably scannable and scrollable, and the user can continue typing (and filtering) regardless of which item is highlighted.

If the user provides enough information to narrow the results to one, it will often be desirable to immediately accept this instead of requiring the user to scroll to the resulting item in the list area and explicitly select it.

[edit] When Used

This can be used when there are very large lists, of two hundred or more items in the list.

It also should used whenever a smaller list has a large number of entries clustered densely around one letter. For example, there are hundreds of cities in California, a very large portion of which start with "San," like San Jose, Santa Clara, San Ramon, and so forth. Even the list of US states has 19 entries starting with M, N, and O, which are the letters on the 6 button, while Kansas, Kentucky, and Louisiana are the only states on the 5 button.

[edit] Rationale

Long lists require many button presses, many fetches, and are generally tedious. In contrast, entering three or four letters to search within the list is at worst twelve keypresses and likely only five or six. States in particular can be accessed with their postal two-letter abbreviation. This is likely faster than displaying a list of items starting with a letter.