worklist

A worklist is a page for working through a list of things that need doing: episodes that are missing, jobs that failed, hosts that don't answer. It shows what needs a person first, and offers one next step for each item.

It is a page layout: a whole page, put together from components, so that every list of work looks and works the same, and people only learn it once.

The live version is on the worklist's React page, with 2,644 made-up items: select rows and grab them, use a row's menu, collapse a season, filter and search.

when it fits

Use a worklist when people work through many items that each need an action or a decision, when those items fall into a few states that people sort by, like “needs attention” first, and when people often act on several items at once.

For other jobs, other pages fit better:

• One item in depth. A page for that item (the detail page is planned), or a card for a summary.
• A few numbers to keep an eye on, with no list to work through. Number tiles on the home page.
• Reference information nobody acts on. A plain table.
• Settings. A form; see forms and settings.
• A dozen items without states. A data table on its own, without tabs or filters.

anatomy

1. Header. The list's name, like “missing”, a line that says which items belong in it, and a quiet line of facts, such as when the list was last refreshed.
2. Counted tabs. The list's states, each with its count: everything first, then the states people sort by. Choosing a tab filters the list. A count takes a colour only when it means something: blue for what is on its way, red for what needs attention, amber for what can't be checked. Plain counts stay grey. These are the filter tabs.
3. A banner. At most one or two, about the list as a whole: what it leaves out, or a load that failed. See the banner.
4. Search and filters, with the number of items left and a way to clear them all: the filter bar.
5. The toolbar. The count of what is shown; once rows are selected, the selection and its one emphasized action. See the selection toolbar.
6. The table. Grouped by the items' parent, like a season of a series, a hundred rows at a time. People can sort it and select rows. See the data table.
7. A menu on every row, with that row's actions, instead of buttons: the action menu.

Two more parts appear only at times. When there is nothing to list, a message takes the table's place and says which kind of empty it is. And after an action, a short toast says what happened, like “8 episodes queued”; when an action fails, a banner says so instead.

how it behaves

• Tabs first, then filters. The tab decides which items are in play; search and filters narrow it down from there. The counts come from the same data as the table, so a count and its list always agree.
• A tab can count items the list doesn't hold, like “not yet aired”. Choosing it shows a message that says why there is no list.
• Changing the view starts again at the top. A new tab or a new filter goes back to the first hundred rows. A refresh of the data keeps people's place.
• People act on what they can see. In the live example, a filter that hides a selected row also unselects it, so “grab 8 selected” never grabs rows that are out of sight. How a selection should behave across filters is under review.
• The toolbar and the table's header stay in view while the list scrolls.
• After an action, the toast counts what happened, “8 episodes queued · 2 skipped: held already or under way”, and the rows update when the data reloads. A failed action shows as an error banner, with the technical details behind “details”.

when there is nothing to list

When a worklist has nothing to show, the header, the tabs and the banner stay where they are, and the table's place holds a message that says which kind of empty it is: good news, or something nobody can know yet.

The React page shows both as whole pages: nothing missing and holdings unknown for everything. Empty states explains the five kinds of empty.

keyboard and screen readers

• The worklist is a section named after its title. Inside an app, the app owns the page's main heading, so the worklist's title is a level below it.
• The tabs are read as tabs, and the list below them as their content.
• The Tab key stops only a few times: once for the tabs, then the banner's buttons, the filters, once for the toolbar, the sort buttons in the table's header, once for all the table's rows, and “show more”.
• Give the table a name and each row a label, so every checkbox and every menu says what it acts on: “select The Quiet Harbour S04E07”, “actions for The Quiet Harbour S04E07”.

the words

• Title. What is in the list, as a noun: “missing”, “failed jobs”.
• Subtitle. The rule for what belongs in the list, in sentence case: “Aired, monitored, and not in the library”.
• Facts. What readers may wonder about: when the data was last refreshed, what runs by itself.
• Tabs. The items' states in their own words, with counts: “missing”, “on their way”, “needs attention”.
• Toolbar. The count and what is shown: “2,500 missing”, “81 need attention”.
• Groups. The parent's own name and its count: “The Quiet Harbour · S04 · 8 missing”.

related

• Selection and bulk actions: selecting rows and acting on all of them.
• Status vocabulary: one status per item, the same everywhere.
• Empty states: which kind of empty.
• Home & tiles: where people open a worklist from.
• Principles: 1, the system does the work; people handle the exceptions.