Autocomplete (advanced)

From MobileDesign

[edit] Applies to:

User Interface: All
Hardware: All

Example

Opera Mini home screen: forms and a series of heirarchical links, all in list format

Contacts from the Windows Mobile 5 OS are automatically filtered (and indicated with highlighting) as input proceeds.

Code Snippets

Sometimes a list of information or 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 the simpler version of autocomplete-by-first-characters detailed in Alphabetic Listings (Long).

[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.

This also has two additional advantages over other solutions. First, it can be used to find strings of information not in the title, such as nicknames, alternate contact numbers, etc. Secondly, if the user simply types a complete phone number, and no match is found, at the end of the entry a valid value has been entered which can be dialed or saved.

[edit] Solution

As soon as the user presses a number key, a list of possible matches is shown. In the illustration to the right, the user first pressed the "2" key. This key can be interpreted as the number "2", or any of the letters "a", "b" or "c." Any extended characters mapped to the number keys like "æ" or "å" mapped to the number "2" key may also be used for matching.

The list is immediately sorted by relevance. Matches from the call log are displayed first in time descending order (most recent first). Thereafter entries from the contacts list in alphabetical order. The list shows matches based on phone numbers and on both the first and last name fields. A recent call to a person with a first and last name both starting with any of the letters "a," "b" or "c" and a phone number starting with the number 2 could appear 3 times in the list. Note that the reason for matching is highlighted in the results, so the user understands why the list is changing.

When the user presses another key (shown in the second image to the right), all possible matches starting with the numbers "22" and any two letter combination of "a," "b" or "c" is displayed. If the user now presses the number "3" key, the list will show all possible matches starting with the numbers "223" and any three letter combination of "a," "b," "c," "d," "e" and "f." In the illustration, the list of possible matches is now down to a single one.

At any time, the user can scroll the list and select an item. It may, depending on the overall use of the system in which this list resides, be worthwhile to automatically select single names when found, instead of requiring the user to scroll down to the results and explicitly select the one remaining item.

Consider what would be the most relevant matches and design accordingly. In the case of an address book, it would be natural to match all names ("first name," "last name," nicknames), and all phone numbers but probably not ZIP or postal codes or date of birth numeric values.

[edit] Rationale

Entering text is difficult and addressing this issue is by far the more important factor in designing for mobile devices.
Selecting an item from a list has a lower error rate than entering it from memory.
Prefer a simple list if the number of items is small