Basic rules for table states
The message inside the table must get the
stickyproperty when scrolling and be centered relative to the parent table and the user's viewport.
Thus the user will always see what is happening with the table, and won't need to scroll to the top of it.
Message with a loading or error state must have
margin-top: 40px, so that when the user changes the size of the viewport, the message does not "stick" to table header.
It is also not recommended to change the table height when switching between states.
When loading data for the first time, show the structure of the loaded page and data. Use the Skeleton.
Show skeleton while there is:
- initial loading of the page;
- initial data loading;
- new data uploading.
We recommend using the skeleton to show only the first three rows, not the entire table.
Don't show Pagination when loading the table for the first time.
In a secondary table, you can show the skeleton for all the rows (there are usually no more than 5-10 rows).
If gathering data takes a large period of time (more than 1 minute, for example), show that data is being collected. Use the ProgressBar in this case.
A message with a progressbar gets sticky and is centered relative to the screen that the user scrolls.
When scrolling the table, fix the progressbar to the table header. The message remains centered relative to the user's viewport.
This state is for cases when user filters/sorts/searchs data. In this case, use Spin.
If data loading is fast, then this state is not necessary.
Use spin when:
- filtering vast data volumes in a table;
- sorting a large amount of data in a table;
- going to another page;
- having other data operations that do not require a long wait;
- searching in the table (if possible, show the search query).
The loading message gets the sticky and is centered relative to the screen that the user scrolls.
The table can be empty and has no data in it, because of the data that was either deleted or not provided at the beginning of working with the table.
Use empty state when:
- the table is empty and, for example, you need to connect data to it;
- the user deleted all data from the table.
See more information in the Empty page.
Note that illustrations for these cases are usually unique. Designers create them for each specific case or product if needed.
Show this message when:
- you don't have data for some reason;
- for some reason, you can't show the data.
Show this state when user has been searching or applying a filter in the table, and we didn't find anything.
In this state, save the active state of the sorted column.
In this state, we recommend adding a control that will help user correct the situation. For example, you can add a "Clear filters" button.
Something went wrong
Show this state when there was an error in the product on the backend, so we can't show the data. For more information about such errors, see Errors, n/a, nothing found in the widgets.
Show it when:
the error happens at the stage of table loading;
error happened while user was working with the table.
|We are aware of the problem, and report it|
|We don't know about the problem|
It is important to indicate the following things in the empty state message:
- In the title – the essence of the current situation.
- In the description – what user need to do to change the situation.
- If possible, suggest an action (in the form of a button or link) which will help user to change the situation. For more information about the rules for such states, see the guides – Errors, n/a, nothing found in widgets, Global errors, etc.
For all empty states of the table, keep the header. If it has sorting icons, also keep them.
Cell empty & error states
There is no data in the cell
- Show the
n/atext in the secondary text color (use
- It is recommended to show a tooltip with an explanation that the data is not available (and for what reason).
Data uploading in the cell
Use Skeleton when loading the table for the first time.
When loading content in one or more cells, show the Spin of XS size.
Error in a table cell
This is the state when something broke in a particular cell and we can't show the data.
Warningicon with M size and
--icon-primary-warningtoken for color.
- On the hover, always show a tooltip with an explanation that something went wrong.
We recommend giving the user the opportunity to change the situation. In this case, you can display the control in a cell for reloading data, for example.
The cell is blocked
A cell in a table may be blocked by a limit or by the need to take some action to unlock the data.
- Use the
Lockicon with M size and
--icon-secondary-neutraltoken for color.
- On the hover, always show a tooltip with a message why the cell is blocked and, if possible, how to get rid of this state.