Tabs

The awkward case is a screen about a single thing that has to carry several distinct groups of content. Stack them all and the page gets long; split them into separate pages and the sense of still looking at the same thing breaks.

Pagedeck's document settings screen hit both walls. Renaming and icons, who can see the document, the revision history, and connections to other tools all ran down one page — about five screens of scrolling, which meant anyone coming in to change permissions scrolled halfway every time. Splitting it into four pages fixed the length and broke the flow: changing permissions and then checking the history took two presses of the back button.

Tabs pick the middle. The content splits into four groups while the screen stays in one place, and a row of names at the top swaps between them, so no navigation happens and nothing needs to be re-found. The screen keeps saying that the thing you're looking at hasn't changed, and the length drops to one group's worth.

One group is visible at a time and the others sit hidden in the same position. The row of names carries two jobs: showing which group is open and showing what else can be opened.

1. Mark the selected tab unambiguously. Colour alone excludes people who can't see the difference, so pair it with something that isn't colour — an underline or a filled background. Not knowing where you are is the most frequent failure of this component.
2. Label tabs with one or two nouns. If the contents aren't predictable from the label, people read the first tab and leave. General, Permissions, History, Connections work because each one states what's inside; Other and Advanced don't, because they state nothing.
3. Keep the count between three and five. Past six, the row won't fit on one line, and in a row that scrolls sideways the existence of the later tabs isn't communicated at all. A fade at the edge helps a little and doesn't solve it.
4. Put the open tab in the URL. Without it, a refresh returns to the first tab, and sending a colleague a link to the permissions view lands them on General.
5. Preserve state when someone leaves a tab and comes back. Select three people on the permissions tab, glance at the history tab, return to find the selection cleared, and the user closes the window rather than doing it again. Half-typed form values deserve the same treatment.
6. Make the row keyboard-operable. With focus on the row, left and right arrows move between tabs, and the open panel is marked so it reads next in order. This is why the component turns up so often in accessibility work.

The defining property is that this component hides things. Hidden content doesn't get opened, so anything everyone needs to see does not go inside a tab.

It fits when the content attached to one thing divides by kind and nobody needs two kinds at once. Four places account for most uses.

1. Settings screens, where groups like General, Permissions and Notifications each get edited on their own and rarely at the same sitting.
2. The detail view of one record. Open a customer and overview, activity and billing split across tabs, with the identity of the customer staying visible above the row.
3. Status divisions in a list. All, In progress and Done as tabs makes filtering the same action as switching views. A count next to each label shows where the work has piled up before anyone clicks.
4. Different representations of the same data — choosing whether to read the same numbers as a chart or as a table.

Where not to use it is equally clear. Not for a sequence that has to be followed in order: tabs can be clicked in any order, which means step three opens before step one, and nothing in the component says that was wrong. And not for content that has to be compared. Rather than making people alternate between two tabs and hold one side in memory, put both on one screen.

"Permissions are on the third tab and nobody finds them. Let's make it the first."

Fixing low traffic to a hidden group by changing its position in the row.

"Switching tabs doesn't change the URL, so we can't share links."

Screen state isn't in the address, which breaks refreshing and sharing.

"Seven tabs means this isn't a tabs problem."

There are too many groups, and the classification itself needs revisiting.

After Noa split the document settings screen into four tabs, Theo attached usage tracking. The first tab was opened by 90 percent of visits and the fourth, connections, by 4 percent. The two of them read that 4 percent differently, and settled on keeping it: the teams that use connections need the tab, and the rest don't. What they did treat as a problem was the permissions tab, second in the row, being opened on only 31 percent of visits, since support requests about permissions ran higher than that — people were asking rather than finding it. It moved to first position.

The most common reading is that this component saves space. Four groups fit in one slot, so it looks like four screens' worth of room. What actually happened is that three of them were hidden. Hidden content doesn't get opened, and traffic falls off sharply past the second tab. Put a service notice or a failed-payment warning inside a tab and the sentence might as well not exist. If the reason for reaching for tabs is that the screen is full, the first question is whether anything on it can be deleted instead.

The other assumption is that adding tabs will organise the information. Each new group gets a new slot in the row, and it feels like that scales. In practice, seven tabs is a signal that the grouping failed. Faced with seven labels, people can't work out which one holds what they came for and start opening them one by one. At that point the answer isn't fewer tabs, it's a different layout — a vertical menu down the left side of the screen. A menu can keep growing downward with twenty items in it, while a row of tabs is capped by the width of the viewport.