Go-to patterns for displaying many services, devices, users, and more.
The when, how, and why to use lists.
HPE Design System list view templates are go-to patterns for displaying homogeneous data such as services, devices, users, and more. List views are optimized for scanability and reading comprehension. Each list item provides users focused information and identity labels to aid selection, decision making, and action.
A list is primarily used for:
- Looking for specific data or information. When coupled with search or filters, it provides a quick means of scanning to find something.
- Aggregating. When coupled with search or filters, it provides a summary of what items match the search/filter criteria and verification of the matching items.
- Selecting multiple items to perform an action with them.
- Be consistent with layout and visual treatments for all list items.
- Keep list item descriptions brief and concise.
- Use icons or images in list items to help draw attention and support scanning.
- Maintain sufficient space between list items or consider using dividers between rows.
- Sort lists in a logical order such as alphabetically, numerically, chronologically, or by user preference.
The following list types are supported:
- Single-line lists are optimal for scan-ability, especially with the addition of an image.
- Two-line lists provide a primary and secondary text which can be helpful when more detail is needed.
- Three-line lists of a primary text and two lines of secondary text are not recommended.
Use either selection of a whole list item or clickable areas on a list item (such as the action menu button). Do not combine these. Use hover states to indicate which kind of selection is being used. If the entire list item is clickable, the background of the list item receives the active background color and the cursor changes to a pointer hand. Otherwise, there is no hover state for a list item that is not interactive. If a list item contains an action button (or other clickable area), then that button respects its natural hover behavior.
Selection use cases include:
- A list with selectable items and a single action menu on the same page, allows for multi-selection of items
- A list with selectable items and no action menu on the same page, allows an item to be selected. When an item is selected, a detail view can be shown with a single action menu for performing other things, such as powering on or off a device. Multi-select is not supported.
- A list without selectable items, but an action menu on each item, allows an action to be performed inline on a single item. Multi-select is not supported.
- If space is limited, then don’t use an Action Menu in a List item (repetition of the Action Menu icon uses a lot of space)
- If more context is needed to perform an action, the entire list row should be clickable and should route the user to a detail page for the List item. On this detail page, an Action Menu can be provided to allow the user to engage with the data.
- If an action is simple and the results can be seen in the List contents (e.g. enable/disable), then use an Action Menu in a List item
- If multi-select is required, then don’t use the Action Menu in the List item.
- Add a sticky header for the list
- Avoid using multiple vertical scrollbars
- For really long lists (i.e. hundreds or thousands), consider limiting the number of items that can be shown at a time and provide some mechanism for accessing the rest of the items, such as infinite scrolling with lazy retrieval and rendering
- Provide search and filtering capabilities to allow customers to quickly find specific list items
- Avoid pagination. It tends to cause a more complicated user experience, especially when selection and/or automatic updating are involved.
Examples are included for different screen sizes – Desktop, Laptop and Mobile.
Lists should span the width of the container they are laid out in
- Long data in lists should be wrapped, rather than truncated.
- It’s about respecting the user’s content; that is, the words they type in.
- We have customers who use long names (>100 chars) and they really need to distinguish one from the other. Truncating often ends up with multiple list entries that look the same, but really aren't.
- It can also apply to automatically generated data, such as product names and descriptions.
- If for some reason the “Do not truncate” rule must be broken, then a way must be provided to see the entire content.
Lists are usually easier to navigate than tables. When creating a design that uses a table, especially a simple table, consider whether a list could be used instead.
When list items are interactive, the Tab key can be used to focus on the List. The focus is always on the list itself and up/down arrow keys are used to move an indicator demonstrating which item will be clicked when the Enter key is pressed.
Each list should also have a clear aria-label indicating what the list contains and a summary of the contents, such as how many items are in the list.
A List or a Table can be used to represent a set of related items, such as servers or devices or users. The one that is chosen will depend on the specific use cases that need to be supported.
- If space is limited, a List uses less room than a Table
- Use a List, If scanability is desired. It’s easier to read than a Table
- If items can be selected using only the List contents, then use a List
Examples of common lists.
Single-line list with an icon, primary title, and a short status tag. In this example, the list items are clickable.
- ActiveEric Soderberg
- InactiveShimrit Yacobi
- ActiveChris Carlozzi
- ActiveMatthew Glissmann
- InactiveTaylor Seamans
Two-line list with primary title, description, and a short status tag.
- InactiveEric Soderberg10.68.229.0
- ActiveAlex Mejias10.33.221.9
- InactiveVicky Avalos10.45.229.1
- ActiveMatthew Glissmann10.35.239.3
- ActiveChris Carlozzi10.48.129.1
Single-line list with a primary title, short status tag and an action button.
- My PVT Cloud OrderComplete
- VMaaS for R&DCritical
Two-line list with an image, primary title, and a description.
- Eric SoderbergSan Jose, CA
- Shimi YacobiFort Collins, CO
- Chris CarlozziSan Jose, CA
- Taylor SeamansSan Jose, CA
- Brittany ArchibequeFort Collins, CO
Something missing or looking for more information? Get in touch to help make the HPE Design System better.