Lists
- Contributors
Graphical user interface to visually display a list or array of data. A common interaction that adds utility in mobile devices.
Typical Appearance
The list from an interaction design perspective has a very literal appearance, normally with a light colored background, and thin black bordered rows. Most lists tend to be navigable, with the title of the list, and an option to add more entries. Lists can be found in various applications that involve displaying a "list" or set of data. This data can be shown in an alphabetical order such as a list of contacts or unordered like a list of groceries.
Typical Behavior
Able to view or display a certain amount of elements at a time. Add or delete entries from anywhere on the list. List normally have a title associated to describe the purpose of the list. List can describe procedures in an ordered fashion or display data with bullet points in an unordered fashion.
Events
Adding or deleting an element to a list is an example of a event.
Users can specify if they wish the list to be ordered or unordered. The
user may wish to sort their list using user-defined conditions. A element
of a list can be highlighted or disabled. A
tag can be added to element of a list to display modifications
or activity.
Highlighted List State:
Often times, an element on a list may be highlighted to show the user that the element is currently selected or active.
Disabled List State:
Tag List State:
- 14 Cras justo odio
- 2 Dapibus ac facilisis in
- 1 Morbi leo risus
Component in Action
Variants
Lists are a very basic way to group together items that have some overarching similarity. The simplicity is the lists strength as well as its weakness. Many other interface elements have become variants to lists because they offer more versatility in their design. Some of these variants are listed below:
Vertical Navigation Menu
List Table Variant
| Firstname | Lastname | Age |
|---|---|---|
| Kevin | Hamilton | 20 |
| Rony | Aguilar | 21 |
| Chuck | Norris | 76 |
Priority Metrics
Talk about the five usability metrics in relation to this component. Not all components will have the same metric priorities. For example:
Practically every user interface uses lists whether its to organize data or to display further actions a user can take. When considering priority metrics with lists, its important to distinguish the variants that lists have an how those variant may have different priorities in terms of functionality.
In the previous section, it was shown how a list may take up a menu functionality. In this case it would be important for the user to recognize that the menu or list is interactable. Therefore learnablility and memorability become a critical factor. The list becomes a navigable element, thus it should have a label or title relevant to where it directs a user if he or she interacts with it. The list would not be effective if it created many errors where a user mistakenly interpreted its elements.
However, with other variants, the list consists of different priorities. If a list is implemented to display a table of data which in this case is now non-interactive; learnability, memorability, and errors are no longer as significant. For this list, its sole purpose is to display data in an organizable fashion.
Perhaps the lowest priorities for a list would be satisfaction and efficiency. The lists serves a utilitarian component that has no value of enjoyment for the user but to simply display its elements. There is no reason for a user to become "efficient" with using a list since it has very low complexity.
Key Characteristics
What makes for a good List? Here are some acceptable layouts and behaviors.The consensus between both Google and Microsoft is that a proper list is a single column, made up of rows whos primary function is to hold text. Specifically, Microsoft says, lists are for "Displaying content collections that are primarily text". This is not to say lists cannot hold other data types, however there are better choices if the primary data type is other than text. (i.e. grids are better for images)
For example, here is an acceptable usage of lists with heterogeneous data types:
Note that each row primarily houses text.
Furthermore, it is well understood that lists only scroll vertically, read top to bottom, and are single column. Without these features, a list is hopelessly inadequate. Therefore, some good implementations of lists would be for messaging, settings, contacts or, surprisingly, any set of textual data that intuitively fits into a list.
Keeping consistency in mind between each row is incredibly important. Guidelines by Apple, Microsoft, and Google, all indicate that the text's font between each row should be the same. Each cell should display the content in a uniform way, the picture above again serves as a good example. Notice how each contact image is lined up with the previous row, and the font is all the same.
Platform-Specific Instances
iOS
Typical Appearance
On iOS devices, lists tend to have a title that describes what the list represents. On most lists there is an "add" button, mostly on the upper-right corner that allows users to add an item to the list. In many cases on each row, there is an arrow indicating that by touching the element, more details may be revealed.
Typical Behavior
Direct manipulation is a defining interface for iOS devices, therefore lists contain direct manipulation as well. Swiping on a row of a list may reveal an option to delete that row of data. Tapping on an add entry button will allow users to directly insert data and insert this new row into the list. Users can also swipe the screen of the lists to scroll through the lists. With Siri on iOS devices, users can also use natural language to manipulate data on lists. For example, a user can instruct Siri to add a new reminder to a pre-existing list of reminders, and what the reminder should say.
Lists in Action:
Priority Metrics
For iOS devices, errors tend to be more common when trying to interact with the application. Since iOS lists tend to be navigable, users often have more errors when trying to display certain details. Sometimes elements are swippable to reveal a delete option, other times you may need to tap an edit button.
For this reason, it's also important for learnability and memorability to be a high priority, so that developers can perhaps prevent common errors that users encounter. It can also be argued that in the case for iOS, satisfaction now have a bit higher priority. People find using Siri to be fun, so being able to add events to a calender, or add reminders to a list may be more enjoyable than just a typical list.
Variants
Collection View
A collection view displays an ordered collection of data items. Most collection views display items in a grid layout, but custom designs are also used. Common designs for collection views include using a catalog-based interface. An example that use collection view is the iBook application, to display an array of books the user has. This variant is most useful when displaying nonhierarchical, ordered items. Collection views are able to add, rearrange or edit a collection of items.
Table View
A table view presents data in a scrollable list of rows that may be split into sections. It presents its data in a single column and serves to display or edit heirarchical lists. An example that uses table view is the Mail application, that displays a list of inbox messages. Users are then able to read it by selecting a message or edit the messages in the inbox. Table views provide a versatile interface for managing and interacting with sets of data.
Picker View
A picker view lets the user select among different options by spinning a wheel on the screen. Picker views are commonly used to display a list of options such as dates or times and cities. For picker views, list of options should be ordered in some way to make scanning easier. Picker views mostly serve to allow users to quickly choose between a set of distinct options.
Windows10
Typical Appearance
Windows 10 lists generally titled elements that also have accompanying icons to clarify the element to the user. Windows 10 also uses lists that can have sub-titles that creates sub-lists within the main list. Other features of the list may be accessed by right clicking inside of the list.
Typical Behavior
All if not most lists in Windows 10 highlight the list element that is being hovered over. If the element clicked on it is also common for a feedback in color change on the element. Some lists are unable to be manipulated while others are able to be directly manipulated via addition or subtraction. Renaming the elements of the list is also a option in a dynamic list.
Lists in Action:
Priority Metrics
Windows 10 leans a lot on memorability. Windows has kept alot of the same features from previous versions of the operating system. Lists are no different in Windows 10 as behavior and apperence are much to what we have come to expect.
Preventing errors are also critical for developers of operating system as you want your users to seamlessly navigate throughout the interface. Creating lists with descriptive titles and adding icons to list elements help prevent errors.
Android and Material Design
Typical Appearance
Like most lists, lists in Google Material Design are a single column of rows, where each row has some number of "tiles" within it. It is recommended that when using a list, a singular data type be used, and especially text is preferred. Google wants all lists to be in order so while dealing with lists in Material Design, expect the data to be sorted.
Typical Behavior
Lists according to Google Material Design, scroll only vertically. Each tile may be picked up, and manually reorded within the list. Furthermore, each tile can be sorted or filtered by date, file size, alphabetical order, or other parameters. Whenever a swipe action is implemented, each tile should have the ability to do the same action. Furthermore, the primary action on each tile is situated furthest left, while subsequent, less imporant, actions are to the right side.
Examples:
Priority Metrics
A huge part of Material Design lists, at least for me, is satisfaction. Technically, the lists themselves do not deliver much satisfaction. However, the animations that typically follow with each action make using these lists quite enjoyable.
Furthermore, from a more practical perspective, Google's decision to always have the data types ordered and uniform makes finding items in Material Design lists incredibly efficient, moreso than they would be without this choice. The consistency apparent between tile actions and row sizing is applicable to learnability and errors, as they make the system easier to learn, and less error prone.
After looking between iOS and Windows design guidelines for lists it seems to me that Google easily outdoes both systems since their specifications are so much more detailed. Not only are these design principles relevant to material design, but they are simply good advice for constructing a list in any situation.
List Alternatives
Google explicitly mentions when not to use lists, which is reminiscent of the Key Characteristics section: "If more than three lines of text need to be shown in list tiles, use cards instead. If the primary distinguishing content consists of images, use a grid list."Credits & References
Google Material Design on Lists: https://material.google.com/components/lists.html
Microsoft on Lists: https://msdn.microsoft.com/en-us/library/windows/apps/hh465465.aspx
Apple iOS Variants: https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/UIKitUICatalog/
Bootstrap List Component: http://v4-alpha.getbootstrap.com/components/list-group/