Every screen of a project is built the same way. Having read this page, you need not read it again in chapters 3 to 7.
The sidebar is sorted by activity
On the left are the project’s areas, grouped by what you are doing — not by which file lies behind them:
| Group | Areas |
|---|---|
| (no group) | Overview |
| Setup | Configuration, Plugins |
| Design | Layout, Styles, Templates |
| Publishing | Preview & build, Git sync, Publish |
| Maintenance | Updates, Snapshots |
At the very top, All projects leads back to the start screen.
The chapters of this handbook follow that division, with one exception: Plugins sits under Setup in the sidebar but in 4 – Design here — because that is where what they do on the finished page is explained.
One page is one task
Every area has a header at the top with an icon, a title and one sentence about what the page is for. Below it stands “Read this in the handbook” — the link to exactly the chapter that explains this screen; on a page with tabs, to the one for the open tab.
To the right of the header are the page’s buttons — and, where there is something to report, a status line (“Saved.”, “3 variables overridden.”). That line is read out by screen readers whenever it changes.
Then come cards: one box per topic, with a heading and an icon in front of it. Where an area needs more than one screen, a bar of tabs sits under the header (Configuration, Styles, Plugins and Layout each have one). The chosen tab is in the address; there is no “back” in the browser sense — but the tab is remembered when you leave the area and come back.
Saving is always explicit
Nothing is saved as you type. A page reads its file when it opens, holds the changes in the window, and writes them only when you click Save or press ⌘S / Ctrl+S.
As soon as anything differs from what is in the file, the badge Unsaved appears next to the save button. Click the sidebar without having saved and you are asked — with three answers where the page offers them: Cancel, Save, Discard changes. If saving fails you stay on the page, because that is where the error message is.
What appears on its own
- Confirmation questions are windows of the operating system, not boxes in QuartzControl. The confirming button is named after the action (“Delete snapshot”), never “OK”, and the safe answer is preselected.
- Errors appear as a message at the bottom right and disappear again. What it says comes from the operation itself — it is never merely “an error occurred”.
- Long operations — a build, a transfer, an import — show their progress where they were triggered, not in a window on top.
Light and dark
The appearance follows the system by default and can be fixed to light or dark in the settings. That means QuartzControl only — what the built site looks like is decided by chapter 4.