Lists (General) overview v. 0.1

Lists are an aggregation of many items into a logical group with a common theme.

Use When 

• You want to group similar content together

Don’t Use When 

• X 

Related/Similar Components 

• Pagination, Load More and Carousels are “list controls” and allow for a mechanism to divide lists when space is limited. Filters and Sorting are also list controls.

Key Content  

*Additional elements which are not technicaly expected to be content items (e.g. skip links and item counts) also exist, but haven’t been added to content as it isn’t expected to be content editable per se (outside of a dictionary).

Visual Style 

Lists in and of themselves don’t have a specific visual style. But within lists, there are common layout patterns.

Open

A standard horizontal list orders items and flows to a new line when necessary. A gap may be set between items to create a space.

Open

A standard vertical list applies a single column and places items in a vertical layout. A gap may be set between items to create a space.

Discuss grid vs flexbox and how to deliver a centred option (e.g. 3 + 2).

Behaviour 

• Lists themselves are often guided by the content that exists within them, so don’t specifically have a behaviour though there are some behavioural ‘extensions’ to be mindful of.

• Lists are always structural, but can also be semantic. Semantic lists allow for ordered and unordered lists (and potentially definition lists).

• Any individual list can be considered critical or optional. A critical list always displays its entire contents and is generally used with the list of the core content of the page (e.g. the main product list on a product listing page. An optional list can display a portion of the list, with the remained revealed through user interaction of list controls.

• List controls include carousels, ‘batch loading' and pagination, which are defined separately within this section.

• Filtering and sorting are also list controls that fall outside of the MVP.

Back-end Controls 

There are a significant number of back-end controls necessary for the curation of lists. Whilst not directly impacting the design system (visually), it is useful for teams to be aware.

• Curation: How the list is generated. The easiest solution is a manual list that can be ordered as needed, however this requires manual updates when new list items become available. Automated lists through tagging or algorithms allow for less manual list curation.

• Size: For manual lists, the size is set, for automated lists more items than are desired to present may qualify and so list size needs a control to cap it. For long lists, there is also the consideration in list size for how many items are visually presented before user interaction.

• Order: For manual lists, the order is set, but for automated lists, list order may include ascending and descending rules for recency, alphabetical order, popularity or more. There may also need to be additional ordering rules such as promoting “featured” items to the start or demoting products that are not in stock to the end.

• Additional Controls: Additional controls beyond the curation of the list centre on how the list is presented and and any user controls. This includes batching long lists (e.g. load more or progressive loading, presenting lists in carousels and filtering and sorting. Some of these decisions may be made programmatically based on the type of list and the list size. These elements are broken down as sub pages of this list section.

Accessibility 

• Semantic lists, marked as <li> within an ordered list <ol> or unordered list <ul> will provide a count of the items in the list to screen-readers to aid orientation. Where optional lists hide a portion of the list from display, semantic list markup would only reveal the visible portion and deliver a list count that is misleading. For this reason, optional lists need to deliver an alternative experience. The general best practice recommendation is to create an item count such as “showing X of Y items” and apply a polite live region to that phrase. If/when list controls are applied (e.g. carousel or load more) the user will be told the status of what is available. Key use cases for this include:

  • Reading out the revised list count when filters are applied.

  • Reading out the revised list count (like Finish) when more items are loaded with ‘load more’ (e.g. showing 24 or 48 items).

  • Reading the progression through the list across a carousel (potentially “showing items 1 to 5 of 15” or possible fallback “showing batch/slide X of Y”.

• Lists can be named and potentially even described. These fields can be used to populate aria-label, aria-labelledby and aria-describedby functions as relevant.

• For long lists, if keyboard users are required to tab through a large amount of items it is often considered best practice to offer those users the ability to skip the list (much like a hidden skip link at the start of the page which becomes visible on focus). This is not needed for all lists, but is a valuable enhancement where there are a lot of tab-stops.

Analytics & Data 

• Tracking of list performance for some types of lists is critical to understanding performance. An example is the ability to track list impressions in Google Analytics in a True-View style. This technique requires a data-attributes to log the position that the item sits within the list. This is only relevant to “optional” (cross-sell and up-sell) product lists, not all lists.

Future Expansion 

• Ordered lists can default to numbering from 1 in an ascending order within the MVP, but if not difficult to extend, offering ordered list flexibility to address the type, start and reverse attributes to give more granular control.

• For MVP, we can assume that lists will contain the same type of item (e.g. product cards, testimonials, etc). However we have also seen interaction patterns of brands wanting to “insert” teasers and similar related content within product grids to promote alternate content. This would result in a non-semantic list and a list count that could be inaccurate if those <aside> items were included in the list count. Due to potential complexity, this type of pattern sits in future expansion.

Wider Conversations that may impact this 

• Programmatic v Customisable: A pure approach to headless CMS removes presentation controls, instead delivering presentation programmatically. Whilst it might be possible to programmatically set decisions (e.g. lists over 20 cannot be presented in carousels), is it better to be cautious and provide guidance/recommendation instead and allow for manual implementation of decisions? 

• What doesn’t need list semantics?: Lists can often be overdone. Some argue that anything that looks like a list should have list semantics and in most cases that is right, but do all multi-item use cases need a list? (e.g. it is likely there is little value in a CTA Block being a semantic list).

Inspiration from elsewhere 

• AEM List Component Configuration

Examples

Useful links