DataTable

DataTables enable users to accomplish a task by finding records of interest, then take action against them. They present structured data in a grid, with columns and rows to aid readability, scanability, and show the meaning of the data.

Controls

DataTable controls should live above the table and facilitate a user's ability to locate and take actions against records of interest. A controls section may contain search and filter controls, as well as action controls such as batch applying settings or data export.

DataTable header

Contain table header cells concisely labeling the column's contents. Column headers may be enhanced by enabling sorting.

DataTable body
Consists of rows allowing users to scan, read and take action on the data. Rows may be enhanced by enabling actions such as record selection and navigation to a record's detailed view.

DataTable footer
Optional. Used for presenting summary counts, sums, averages, and other aggregations.

Users interacting with a DataTable are trying to accomplish one of the following types of tasks. They are not, however, trying to do all of these tasks at once. Keeping "what is the user setting out to accompish?" at the center of our mindset helps guide which table features to include and, more importantly, exclude when we add a Table to our interfaces.

Often, a user's task is to find and take action against a specific record. Whether it be finding a customer's record to review their chat history, tracking a particular order's status, etc., the user experience objective is to enable a user to locate that record as quickly as possible.

• Use Search. This is often the quickest, most efficient method for users to find a record of interest.
• As backup, use sortable columns coupled with paginated results. This combination provides users with the knowledge of alpha-numeric range, enabling an educated guess as to the record's location in the sort.

When a user is looking to focus on a group of records sharing similar characteristics, providing thoughtful filter controls allows for incremental reduction of the DataTable's result set.

• Provide filter controls.
• Filter control input types should be chosen to best fit the data type and breadth of values.

Sometimes users are "checking up on things" or do not have specific records in mind. In this case, they are assessing the state of their records and the user experience objective is to facilitate the scanning of records to identify potential outliers or records which the user is unaware need attention or action.

• Use infinite scroll. In this scenario, infinite scroll removes friction, allowing users to browse records effortlessly.
• Consider adding column data types such as status indicators or meters which call attention to records needing attention.

Distinct from the user objectives above, data tables containing data for analytical purposes deserve distinct treatments as well. While data tables are useful for providing initial "discovery" type insights, such as identifying available attributes and ranges of values, purpose built tools are often a better choice for conducting in depth analysis. In this scenario, a data table's design should be optimized for assembling the data set for analysis and easy portability of that data into the user's preferred analytical tool.

• Provide filter controls.
• Filter control input types should be chosen to best fit the data type and breadth of values.
• Provide export capability for users to consume the data in their analytical tool of choice.
• Provide aggregate measures in the table footer.
• Organize table columns to group like elements and to keep most important elements to the left.

• Use the correct set of columns, prioritizing frequently used ones. Don't add more columns just because the data is there, as this will clutter the data table.
• To support readability, make tables only as wide as they need to be and no wider. If the content does not need a large width, prevent the table from stretching.
• Limit the whitespace on individual columns by using size for data table columns.
• When the data table has the potential to be wider than the screen:
  • Use 'pin' to anchor the primary column to preserve row context.
  • Use horizontal scrolling within the data table, as opposed to scrolling at the level of the entire page
• When the data table has the potential to be narrower than its layout context:
  • Align it horizontally with the rest of its layout context. Typically, this is aligned to the start of the content as opposed to stretched.
  • Align any header above the table, including heading, search, filter, actions, in the same way. This keeps an actions menu or button in the context of the data table and prevents them from being orphaned. However, don't force the header above the data table to align its width to the data table, as that might compress the contents of the header too much.

• Let the data set the height of the data table. The data table will grow in height as the length of data increases.
• If it is expected a user will want to navigate to a specific portion of the data, pagination should be used. Generally, it is recommended that each page of data table results be limited to 20 records. For more information on pagination, read [Pagination guidance].(/components/pagination#when-to-use)
• Do not restrict the height of a data table if the page has available space. This may introduce unnecessary scrolling.
• If the height of a Table needs to be restricted, set overflow=“auto” on its parent Box to allow the user to scroll through the data.

When text exceeds the amount of space available within a table cell, wrapping or truncation may be used depending on your use case. Below are some best practices to consider when implementing.

• For readability, avoid truncating or wrapping text within the first column.
• Keep each cell short and concise, limiting the amount of characters within a cell when possible.
• Minimize the number of included columns by only showing those which are used most frequently.

Truncation should not be used on headings, numeric values, or statuses.

Truncation may be applied at the beginning, middle, or end of a piece of data. When choosing where to apply truncation within a string, consider which section of the text is most likely to differentiate the item from others in the column.

Additional questions to keep in mind when using truncation:

1. How much information loss is acceptable?
2. What impact is caused by any amount of information loss?
3. When creating the data, can it be structured so that a table can truncate it in such way that the information loss is kept to a minimum?

Front-text

Front-text truncation is when an ellipsis is placed at the beginning of a long string. This is best used when the start of a string is similar to many other cells, such as text containing a common prefix.

Mid-text

For recognizability, it may be better to crop the middle of a string. Define the parts of the content which need to be preserved in order to keep recognition high and should not be truncated. This strategy can be used when both the beginning and ends are uniquely identifiable.

End-text

End-text truncation is when the ellipsis is placed at the end of the string.

If truncating numerical values is absolutely necessary, use end-text truncation. Additionally, provide a tooltip to help users view the complete string.

Wrapping allows long strings of text or words to break and wrap onto subsequent lines.

Wrapping should be used when:

• The entirety of the content must be available at all times.
• Long numerical values need to be displayed.

If the value of a cell is empty, use -- in place of where a value would appear. This visual indicator aids the user in identifying fields that do not have values while also maintaing the scanablility across rows and columns.

Because the HPE theme does not have borders or background color differences to differentiate between rows and columns, a visual indicator in empty cells is necessary to maintain readability and scanability.

For empty cells, add an a11yTitle="No value" to the Text component that would otherwise render the data to ensure users of assisstive technology are informed of the empty state.

To ensure screen readers are able to associate a page heading with a given DataTable, apply an id to the Heading and aria-describedBy to the DataTable, where the same string value is applied to both attributes. When a screen reader reaches the data table, it will announce the Heading content which provides the user with better context about the table data and purpose.

For example, if on the Heading you apply id="storage-pools-heading", on the DataTable you would apply aria-describedBy="storage-pools-heading". In this example, the screen reader would properly associate "Storage Pools" as the description for the DataTable.

Statuses within a DataTable should always have these accompanying elements:

• Shape
• Color
• Content (This is not restricted to just normal, warning, unknown, and critical)

Greater detail, including accessibility considerations, is included on the status indicator page.

A state is the current stage of a process. A status is the condition of the state. Status can also be thought of as a pointer to a state’s “health”. Read more about the distinctions between state and status.

Depending on the scenario, status and state may be displayed within a DataTable in one of three ways:

1. Separate columns for status and state
2. Status only column
3. Combined column

When status and state are distinct and independent from each other, display them in separate columns. This is the most common use case.

• Used when the status column is not coupled with the displayed state column. (Ex. An equipment can have a “Normal” status but have a “Running” state shown within the DataTable.)
• Allows columns to be sorted independently from each other.
• Clearly visually separates and labels status and state to avoid false associations.

• In some use cases, displaying status on a DataTable is more important to users than state. If this is true for your use case, feel free to display only the status in the DataTable.
• Used in situations where horizontal screen real-estate is an issue.
• If displaying state is required, provide the user the ability to view the record's detail. State may be displayed once the user selects the row for more information.

When the status and state are coupled, they may be displayed as a single element.

• Coupled statuses have a 1:1 relationship with specific states.
• A single column presents both status and state. Status represented by a status indicator and state as the accompanying label.
• Status and State are sorted together rather than individually.
• Note: A single column is rarely used. Ensure false associations are not created when status and state are not coupled.

Column headers behave as a button and perform the sort action. A caret icon indicates the directionality and to which column the sort is currently applied.

Columns can be resized if a DataTable has the resizeable prop applied. Column resizing allows the user to change the width of the header columns. Each column can be resized by dragging the right side of its header to the left or to the right to expand the column.

Complimenatary elements such as search or filters should be guided by the task the user is setting out to accomplish.

• Looking for a specific record? --> Search.
• Trying to narrow records down to a set of shared characteristics? --> Filter.
• Not quite certain for what I am looking, but I know its general characteristics? --> Filter.

See Filtering for greater detail.

Clicking on a data table row takes the user to a context where the most prominent heading matches the primary column text. This context could either be a page or a modal. In this example, clicking on a table row navigates to a detail page.

Checkboxes allow for selection of multiple records, which then may apply batch actions via action control buttons or menus.

With long sets of data, pagination can help to create a more efficient means of navigating to a specific item or range of items.

Fixing or pinning header rows, columns, or footers allow users to track and maintain context across long and wide data sets.

Should be guided by the task the user is setting out to accomplish.

• Browsing? --> Infinite Scroll
  • Perhaps I am reviewing a customer's account history. I am not looking for a particular record, rather I am in scanning mode, trying to get a sense of the volume and types of interaction with a customer over time. Infinite Scroll creates a nice, frictionless experirence for this to occur.
• Searching for a specific record? --> It depends.
  • Do you have a good search experience? --> Infinite Scroll
  • Do you have a performant API?
  • Do you require page reloads?
  • Is your data structured?
• Do rows have many interactive elements? --> Pagination
  • Be mindful of keyboard users.