skip to content
menu
patterns · forms and settings
patternslists & formsreact implementation

forms and settings

Settings change how something works: when a backup runs, how many days it keeps, who gets an email. Some settings take effect the moment they are changed. Others are part of a form, and wait until people press save. This page is about telling the two apart, and about how a form helps people get things right.

backup settingsalertsEmail me when a backup failsWeekly summaryscheduleunsaved changescancelsave changes
A settings page: switches that apply at once at the top, and a form below that waits for save.

The live version is on this pattern's React page, together with how it is built.

when it fits

  • For a page or a panel of settings that people change now and then: a schedule, limits, what to include, how things look.
  • For any form that ends with a save: creating something, or editing it.
  • For an app's own setup views, which are forms like this one; settings and setup says where each kind of setting lives.

Other jobs need something else:

  • Filtering or searching a list. Use the filter bar: filters apply as they change, and nothing is saved.
  • A decision that has to come first, such as confirming a delete. Use a dialog with the question and two buttons.
  • One action with nothing to fill in, like “check now”. Use a button.
  • Settings that each apply on their own, at once. They need no form and no save button: a card of switches.

instant or saved

Whether a change applies at once or waits for save is the most important thing to get right on a settings page. People need to know whether they are done.

  • A switch applies the moment it is flipped. Switches sit outside the form, in a card without a save button. When the change shows somewhere else, or takes a while, a toast confirms it: “Email alerts off”. If it can't be applied, the switch flips back, and an error banner says why.
  • A checkbox is part of the form. It waits for save, like every other field.
  • Keep the two apart. A switch above a save button leaves people unsure whether it applied; a checkbox without a save button sends them looking for one.
do
Back up configurationsave changes
In a form that is saved, an option is a checkbox: it waits for save.
don't
Back up configurationsave changes
A switch above a save button: does it apply now, or on save?

Today there is no radio button component; a group of the browser's own radio buttons does the job.

anatomy

backup settingsalertsEmail me when a backup failsWeekly summaryscheduleunsaved changescancelsave changes123456
The settings page, close up.
  1. Page title, with a quiet line of facts under it.
  2. Instant settings: a card of switches, each with its own label and, where the effect isn't obvious, a hint. No footer.
  3. The form, named after its card's title, so people can jump to it.
  4. Fields: each with its label, a hint, and the error in place of the hint when there is one. See the field.
  5. Option groups: a question that the options answer, with checkboxes under it. For one choice out of two or three, a group of radio buttons; out of more, a select.
  6. Footer: the “unsaved changes” signal, “cancel” as a quiet button, and “save changes” as the one emphasized button, at the end of the row.

Three more parts appear only at times: a success message above the content, after a save that changed what the page shows; an error summary at the top of a long form, after a save that found errors; and a toast that confirms a save.

  • One footer, at the end of the form. Its one emphasized button is “save changes”, with “cancel” as a quiet button before it.
  • The form has unsaved changes when a value differs from the saved one. Typing a value back to what was saved makes the form clean again.
  • While there are unsaved changes, the footer says so, next to the buttons: “unsaved changes”.
  • Save stays available, with or without changes, with or without errors. A greyed-out button is skipped by the Tab key, so keyboard users may never reach it, and it can't say why it is off. A save that can be pressed answers when it is pressed: with no changes, a toast says “No changes to save”; with errors, the errors show.
  • Pressing “cancel” puts every field back to its saved value and clears the errors, without asking first: nothing that was saved is lost.
  • On a form taller than the screen, the footer stays in view at the bottom while the form scrolls.

Today nothing warns people who leave a page with unsaved changes; the app does that, with the browser's own leave-page question.

do
unsaved changescancelsave changes
One emphasized action at the end; cancel is a quiet button before it.
don't
cancelsave changes
Two emphasized buttons: which one finishes the form?
do
unsaved changessave changes
Save stays available, and the footer says there is something to save.
don't
save changes
A greyed-out save is skipped by the Tab key, and never says why it is off.

checking the values

Checking what people entered is called validation, and it happens when they press save.

save changessave changesWhile people type: no errorsOn save: errors, focus on the first
No errors while people type. On save, the errors show at their fields, a summary counts them, and the focus moves to the first.
  • Check on save, not while people type, and not when they leave a field. An error that appears as people pass through a field scolds them for something they haven't finished.
  • Once a field shows an error, check it again on every change, so the error goes the moment the value is right.
  • Save checks every field, shows the error at each one that is wrong, and sends nothing.
  • Then the focus moves to the first field that needs a fix. People hear its name, that it is invalid, and its error, and they start where the problem is.
  • On a long form, also sum up at the top: an error banner that counts what needs a fix and names it in the labels' words. It follows the fixes, and goes when nothing is left. A long form is one with more than one group, or one that scrolls; a short form only needs the errors at the fields.
  • The save button doesn't turn off to signal an error.

when the save fails

  • The save itself can fail. Say so in an error banner at the top of the form, with a way forward, “try again”; the technical part goes under details.
  • The fields keep what people typed, and the changes stay unsaved.
  • Not in a toast: it leaves after five seconds, and the work still isn't saved.
do
A failed save is a banner that stays, with a way forward. The fields keep what people typed.
don't
Couldn't save the settings
An error in a toast is gone in five seconds, maybe unread, and the work isn't saved.

after a save

  • While the save runs, the save button shows that it is busy, so a second press can't send the form twice.
  • When it is done, the fields show the saved values, and “unsaved changes” goes.
  • A toast confirms it: “Settings saved”. A second save replaces that toast instead of stacking another.
  • When the save changes what the page shows, such as every time on the page now shown in UTC, say so in a success banner above the content that people can dismiss: “Saved. Times on this page now show in UTC.” The change happened where people weren't looking; the banner says why. No toast as well.
do
Settings saved
A plain save is confirmed by a toast that leaves on its own.
don't
A banner for a plain confirmation stays on the page long after it was news.

keyboard and accessibility

key what it does
Tab and Shift+Tab Moves through the switches, the fields and the options, then cancel and save, in reading order
Enter, in a text field Saves the form: it presses “save changes”
Space Ticks a checkbox, flips a switch, or presses a button
Arrow keys Move through a select's options, or to the next radio button, choosing it
Esc Closes whatever is open inside the form, like a select's list. It doesn't cancel the form
  • The form is named after its card's title, so people can jump to it.
  • Only “save changes” sends the form. Enter presses the form's first send button, so a cancel button that sent the form, placed before save, would be the one it pressed.
  • Required fields say “required” to screen readers; the browser's own error bubbles stay out of the way.
  • A field's error isn't read out when it appears; moving the focus to the first field that needs a fix is what gets it read.
  • Error banners are read out as they appear, and again each time their text changes, once per fix. The success banner is read out politely.

Today:

  • A success banner that appears with its text already in it may pass in silence on some screen readers. The toast doesn't have that problem.
  • The busy save button can't keep the focus while the save runs, so the browser may move the focus to the page. When the save ends, put the focus back on save.
  • A toast stays five seconds, and only a pointer resting on it pauses it, not the keyboard. Keep anything people need later out of it: the saved form is the record.
  • An error for a checkbox or a switch doesn't mark the box itself. Check option groups as a whole, and say what is wrong in the summary.
  • There is no group or radio button component yet. The browser's own, with the question styled like a field's label, does the job.

the words

  • Title. What the settings are about: “backup settings”.
  • Labels, hints and errors. In sentence case, as the field page says. A noun for the label, “Retention (days)”; an error that says how to fix it, “Use a whole number from 1 to 90”.
  • An option group's question. What the options answer: “Back up”, “Notify me about”.
  • Footer. “save changes” and “cancel”. Not “ok”, “submit” or “apply”.
  • The signal. “unsaved changes”, and nothing while there are none.
  • The summary. “Couldn't save.”, then the count and the labels as they are written: “2 settings need a fix: Backup host and Retention (days).”
  • A failed save. What happened, and that nothing is lost: “Couldn't save the settings. Your changes are still here.” The code goes under details.
  • Toasts. What happened to what, in sentence case, without a full stop: “Settings saved”, “Email alerts off”, “No changes to save”.
  • The success banner. “Saved.”, then what changed on the page: “Saved. Times on this page now show in UTC.”
  • Field: the label, hint and error around each control.
  • Message handling: when a message is a banner, a toast, or at its field.
  • Switch: the setting that applies at once.
  • Toast: the confirmation after a save.
  • Settings and setup: where each kind of setting is changed.