settings and setup

Settings come in different kinds. Some belong to one person, like the language they read in. Some belong to the whole platform, like who may use it. And some belong to one app, like where it looks for downloads. Each kind is changed in the place that owns it, so for every setting there is exactly one place to change it.

An app's own setup is a little special: people can find it from three places, but they always change it in one, the app itself.

Three ways in, one form: settings, the home page and the app itself all lead to the app's own setup.

four kinds of settings

kind	for example	changed in	owned by
A person's preferences	Language, theme	The user menu, under preferences	The shell
The platform's settings	People, apps, spaces, tiles	Settings	The shell
How an app is installed	Its database address, the resources it gets, the network it uses	Settings, under addons; the platform applies them, and may restart the app	The platform, following the options the app lists when it is installed
An app's own setup	Its connections, sources, rules and schedules	The app's setup views	The app; the shell doesn't store, receive or show these values

The app owns its setup. The shell shows whether an app is set up and links to its forms, but it doesn't hold the app's settings itself. That keeps the app's passwords and connection details in one place: the app.

found in three places, changed in one

People look for setup where they happen to be, so the shell points to it from three places. All three lead to the same form, inside the app.

settings → addons

A checklist with one row per app, each addon included: whether it is ready, needs setup, or is degraded, with a one-line summary. Each row's “configure” opens exactly the form that needs attention, inside the app.

Settings, addons: each app's state, a summary that counts and names, and the way to its form.

the home page

While something the app needs is missing, its tile on the home page says “needs setup”.

inside the app

The setup group at the bottom of the app's navigation marks the views that need setup, and the app's first view shows one message, “2 things to set up before it can work”, with “configure”. The side navigation is a planned component; the drawing shows the idea.

a few rules

One form per section, and a link to a section lands on that form, not on a page in between.
Summaries count and name; they don't quote values. “2 download clients, 1 unreachable”, not the address of either.
A secret can be replaced, but not read. It shows that it is stored, and offers to replace or clear it, but it doesn't show its value.
Each form has a save button, and says when it has unsaved changes; see forms and settings. The checklist shows a save the next time it is read.
Setup stays apart from daily work. It sits in its own group, at the bottom of the app's navigation.
“Set up” and “running” are different questions. Whether the app runs is the platform's view; whether it is set up is the app's. So the checklist doesn't say “ready” while part of the app is down.

The shell lists the app's setup state, and links to the app's own form.

don't

The shell draws the app's form itself: it would have to hold the app's values and its passwords.

the words

States. Ready, needs setup and degraded: the app's own words, each with one meaning, success, warning and error. See the status vocabulary.
Summaries. Counts and names, in sentence case: “No search source yet · 2 download clients, 1 unreachable”.
The action. “configure”, on every row and in the message inside the app.
The message inside the app. What is missing, and that the app can't work without it: “2 things to set up before it can work: search sources and clients.”

App navigation: the setup group at the bottom of an app's navigation.
Top bar: the user menu, and its settings.
Forms and settings: the forms themselves.
Switch and field: the controls the forms are made of.
Principles: 4, one platform, many apps.