Settings view - Invoca

What it is

A page that configures an already-existing subject’s standing settings — an account’s settings, a campaign’s settings, an integration’s configuration — grouped into independent sections a reader visits selectively over that subject’s ongoing life, rather than filled in once during that subject’s creation. This is the concrete answer to CRUD: Create’s own rule: “A form with several independent sections is one page with a Table of Contents, not a Wizard.” Settings view is what that Table of Contents looks like when the subject is standing configuration rather than a form being filled in once. Settings are almost always settings of something — an account, a campaign, an integration — never a freestanding subject of their own. Breadcrumb back to that thing is required; see Header — Left. You are building one if the page’s sections are independent (no fixed order, each meaningful on its own) and the subject already exists and will be reconfigured repeatedly over time, not created once and then left. A page that is filled in once toward a single commit, for an object that does not yet exist, is Full-page form even when it also has several independent sections — see Choose something else when.

Region vocabulary

This archetype adds no regions to the page frame. It reuses a structural pattern Full-page form already established for independent sections on one page — an in-page navigation aid inside Contents, not a frame region — rather than inventing a second answer to the same shape of problem. Two terms are worth naming even though neither is a frame region:

Region	Also called	The system uses
One labeled group of related fields	Group, panel, block	Section (this archetype’s term, following Full-page form’s own usage — not a system export)
In-page navigation between sections	Table of contents, section nav, jump links	Not a named region — an anchor nav inside `Contents`, the same pattern Full-page form names

Choose this view when

The subject already exists and is being configured on an ongoing basis, not created for the first time.
Configuration breaks into independent sections — notification preferences, billing, API access — with no fixed order between them.
A reader typically comes back to change one section at a time, on separate occasions, rather than filling in the whole page once.

Choose something else when

If the page also needs to…	Use	Why
Configure only one thing — nothing to group into sections	Full-page form	Full-page form’s own `Contents` already collapses to a plain form with no anchor nav once there is only one section — see that page’s Regions table. Settings view’s grouping has nothing to organize once there is only one thing to configure.
Be filled in once, toward a single commit, for an object that does not yet exist	Full-page form	That page already resolves several independent sections onto one page with an anchor nav — for exactly the bounded, one-time case. Settings view is the same structural shape turned to the opposite case: standing configuration edited piecemeal, indefinitely — which is why its footer is fixed rather than sitting at the end of the scroll, see Footer.
Walk the reader through sections that genuinely depend on each other, in order	Wizard	Order-dependent sections need a Wizard regardless of which archetype would otherwise hold them — the same rule CRUD’s own Create page already states.

Regions

Region	Required	Landmark	Contains
`Header` — `Left`	Yes	`banner`	`Title` naming the scope being configured. `Breadcrumb` back to the thing these settings belong to — required, not optional, on this archetype.
`Header` — `Right`	No	—	A secondary, non-committing action if one exists. Never the view’s commit — that lives in `Footer`.
`Header` — second row	No, in the default case	`tablist` only if the Tabs threshold below is met	Nothing, in the default case — see Header — second row.
`Controls`	No	`search` when primarily search	A search box across all settings, when the number of fields makes one worth having — not required by this archetype.
`Contents`	Yes	`main`	The sections, each a labeled group of fields, plus an anchor nav when there is more than one.
`Footer`	Yes	`contentinfo`	The view’s commit and cancel, fixed to the viewport — see Footer.

What fills each region

Slot	Use	Constraint
Title	`Title`	Required. Names the scope — “Notification settings,” “Campaign settings” — not a bare “Settings” with nothing to anchor it.
Breadcrumb	`Breadcrumb`	Required on this archetype, pointing to the thing these settings configure. Settings are settings of an account, a campaign, an integration — omitting the breadcrumb strands the reader with no path back to what they’re configuring.

The default state is nothing — per Views overview’s own three states (nothing, tabs, filters), Settings view’s header carries no second row in the common case. The Table of Contents is not a header occupant at all; it lives inside Contents, following Full-page form’s precedent — see Contents — sections and navigation below. Why not a tab bar, when Views overview already defines one as exactly “a section of the page’s subject” — which a settings section plainly is. The reason is the frame’s own rule that exactly one TabPanel is visible at a time. That property is the wrong fit here, even though the section-of-a-subject test passes. A reader configuring settings often needs to see two related sections at once — checking who’s on the notification list while editing the escalation rule that pages them — or wants to search across every setting at once, not just the one section currently active. A tab bar hides everything but the active panel by design; an anchor nav inside Contents keeps every section on the page, reachable by scroll and by search, which is the property this archetype actually needs. Tabs are still the right call when sections are numerous and truly unrelated — each large enough to be worth its own screen, not just a labeled group of fields on one coherent configuration surface. That is the same threshold Progressive disclosure already states for its own “Settings tab over Accordion” variation: a secondary area large enough that most users never open it is worth a dedicated tab, not a scroll-triggered reveal. “Billing” and “Notification preferences” on one account settings surface are related enough to stay on one page; an entire “Integrations” configuration area with its own object model might cross that threshold and deserve its own tab, its own URL, and its own Settings view underneath it. Each section is a labeled group of related fields — a heading, then its fields, visually distinguished the same way Full-page form already specifies: headings, dividers, or grouped cards, never hidden behind tabs or steps. An anchor nav, when there is more than one section, is a shortcut to a section, never a gate in front of it — clicking an entry scrolls to that section; it never hides the others. This is the same structure Full-page form already establishes; Settings view follows it rather than re-deciding it.

Slot	Use	Constraint
A section	Heading, then its fields	Independent of every other section — no fixed order, and no section depends on another’s value to make sense.
Section anchor nav	An in-page jump list	Present once there is more than one section. Scrolls to a section; never hides the others — the same rule Full-page form’s own anchor nav follows.

Whether a section starts collapsed follows Progressive disclosure’s own threshold directly, rather than a rule invented here: collapse a section only if it is genuinely secondary — used by a minority of readers in a minority of sessions — and never collapse the section a reader most likely came to this page to change. A settings page whose every section is something most accounts touch regularly should show every section open by default; disclosure earns its place only for the sections most accounts never adjust. Required, and fixed to the viewport. Every section on this page configures one subject, so the whole view is the unit of commit and one footer covers it — the frame’s Footer, holding the view’s commit and cancel. No section carries a Save of its own. It is fixed rather than static because a reader arrives to change one section, which may be anywhere on the page. A footer at the end of the scroll is a journey away from the edit, which is the distance that makes a per-section button look like the obvious fix. Fixing it keeps the commit in reach of whichever section the reader came for. The full decision, and what changes when configuration is scoped to a single container instead of a whole view, is in Footers.

Slot	Use	Constraint
Leading	—	Empty. A backward action belongs to a sequence, not to standing configuration.
Trailing — Cancel	`Button` tertiary	Discards every uncommitted edit on the view.
Trailing — commit	`Button` primary	Labeled for the action, never the section — “Save changes”. At most one primary on the view.

Responsive and density behavior

Titan is desktop-first — most surfaces live at lg and xl, and xs/sm are rarely exercised (see Layout & grid). What follows is proposed with that in mind.

Breakpoint	Collapses	Stacks	Dropped
`md` and below	The anchor nav collapses from a persistent side rail into a dropdown or a collapsible list above the sections — the same collapse Full-page form already specifies	Multi-column field layouts within a section stack to one column	Nothing — every section stays reachable; only the nav’s presentation changes
Compact density	Field and section spacing only	—	—

Accessibility

The page-level decisions are the frame’s, and they apply unchanged — see Views overview → Accessibility. One main, one h1 on Title, region order matching visual order. What is specific to this archetype:

Each section heading is a real heading, descending from Title’s h1 without skipping a level, so a screen-reader user outlining the page sees the same structure the anchor nav exposes visually — the same requirement Full-page form already states.
The anchor nav is a navigation landmark with an accessible name — “Settings sections,” not “Navigation” — whose links move focus to the target section’s heading, not just scroll position. Same reasoning as Full-page form.
A collapsed section’s trigger states what it reveals, and a validation error inside a collapsed section forces it open and is announced — the same rule Progressive disclosure already states, applied here rather than restated.
The footer’s commit and cancel carry accessible names that name the action, not the section — “Save changes,” not “Save notification settings” — because there is one commit for the whole view and nothing to disambiguate it from.
A failed commit moves focus to the first invalid field, in its own section, and the failure is announced via a live region or the error text’s association to that section — not shown only visually. With one footer the field that blocked the commit is frequently off-screen from the button that was pressed.

Constraints

ID	Constraint	Rationale
TITAN-SETVIEW-01	`Breadcrumb` is required in `Header` — `Left`, pointing to the thing these settings configure.	Settings are settings of something. A page naming only “Settings” with no ancestry strands the reader with no path back to the account, campaign, or integration it belongs to.
TITAN-SETVIEW-02	Independent sections get a Table of Contents inside `Contents`, not a tab bar in the header’s second row — unless sections are numerous and truly unrelated, each substantial enough to be worth its own screen, per Progressive disclosure’s own “Settings tab” threshold.	A tab bar shows exactly one panel at a time, which hides related settings from each other and blocks searching across them. An anchor nav keeps every section visible and searchable, which is what a reader configuring related settings needs.
TITAN-SETVIEW-03	A section starts collapsed only when it meets Progressive disclosure’s own threshold for genuinely secondary content; a section most readers actually came to change starts expanded.	This archetype does not re-decide Progressive disclosure’s own threshold, it applies it.
TITAN-SETVIEW-04	Superseded by TITAN-SETVIEW-08. Each section commits independently, with its own Save and Cancel scoped to that section’s fields; the page carries no page-level commit.	Retired when the view became the unit of commit. Kept so a citation still resolves to the rule it meant.
TITAN-SETVIEW-05	Superseded by TITAN-SETVIEW-09. Cancelling a section reverts only that section’s uncommitted edits, never any other section’s.	Retired with TITAN-SETVIEW-04, whose section-scoped commit it depended on.
TITAN-SETVIEW-06	A validation error inside a collapsed section forces that section open and is announced.	Per Progressive disclosure — the same rule that page states, applied here rather than re-decided.
TITAN-SETVIEW-07	A failed commit keeps every edited field in its unsaved state, with the error rendered against the section it came from. It never silently reverts to the last-saved value.	Reverting on failure discards a correction the reader believed they’d made, with no way to recover it — the same reasoning Inline editing applies to its own failed saves.
TITAN-SETVIEW-08	The view commits as one unit, from a single fixed `Footer`. No section carries its own Save and Cancel.	Every section on this page configures one subject, so the whole view is the unit of commit. A commit per section splits that unit into several and leaves “am I done?” unanswerable from the screen.
TITAN-SETVIEW-09	Cancel in the footer discards every uncommitted edit on the view, never one section’s alone.	There is one unit of commit, so there is one thing to discard. A section-scoped revert would imply a section-scoped save, which this archetype does not have.

Composed example

┌───────────────────────────────────────────────────────┐
│ Acme Inc. / Settings                                    │  ← Header: Left (Breadcrumb, Title). No second row.
├───────────────────────────────────────────────────────┤
│ ┌───────────┐ ┌─────────────────────────────────────┐ │
│ │ Profile   │ │  Profile                              │ │
│ │ Notif.    │ │  Name:  [_______________________]     │ │
│ │ Billing   │ │                                        │ │
│ │ API keys  │ │                                        │ │
│ └───────────┘ │  Notifications                         │ │
│               │  ▸ Advanced routing (collapsed)         │ │  ← Progressive disclosure
│               │  ...                                    │ │
│               │  ...                                    │ │
│               └─────────────────────────────────────┘ │
├───────────────────────────────────────────────────────┤
│                              [Cancel] [Save changes]  │  ← Footer: fixed, one commit for the view
└───────────────────────────────────────────────────────┘
     No section carries a Save — the whole view commits together.

Views overview — the frame this archetype fills
Full-page form — the sibling archetype for the same “several independent sections, one scrollable page” shape, applied to a bounded, one-time commit instead of standing configuration
CRUD: Create — TITAN-CREATE-03 — the constraint this page resolves concretely
Progressive disclosure — the collapsed/expanded threshold this page applies rather than re-deriving
Footers — which surface owns the commit, and why this one belongs to the view rather than its sections
Inline editing — the alternative when the unit of change is a single field rather than the view
Wizard — where sections genuinely depend on each other in order

Why it works this way

The anchor nav is borrowed, not reinvented, because the underlying shape is identical. Full-page form already worked out that independent sections belong on one scrollable page with a jump list rather than behind tabs or steps, for the reason that hiding them teaches a relationship — order, or boundary — that independent sections don’t have. Settings view’s sections are just as independent of each other; re-deriving a second answer to the same question would only invite the two pages to quietly drift apart over time. The footer is fixed, and the reason is where the reader edits. A Full-page form is filled top to bottom and ends where its footer is, so a static footer is in the right place by construction. Settings view’s subject already exists and gets reconfigured indefinitely, in separate visits, by readers who came to change one section and have no reason to re-touch the rest — so the edit can be anywhere on the page, and a footer at the end of the scroll is a journey away from it. Fixing the footer puts the commit within reach of whichever section the reader actually came for. The unit of commit is still the whole view: every section on this page configures one subject, so one footer covers them all — see Footers.

Status


Constraints	Proposed. `TITAN-SETVIEW-01` through `-09`; `-04` and `-05` superseded by `-08` and `-09`.
Decided	One fixed footer for the view, and no section-level commit.
Provenance	Built from the constraints Views overview, CRUD, and Progressive disclosure establish, and from the sibling Full-page form archetype. No audited product screen backs the section structure.
Open	The composed example is a structural diagram; replace it with a live embed once the archetype ships. Footer behaviour on partial validity and multi-section cancel is undecided — see Footers.

​What it is

​Region vocabulary

​Choose this view when

​Choose something else when

​Regions

​What fills each region

​Header — Left

​Header — second row

​Contents — sections and navigation

​Footer

​Responsive and density behavior

​Accessibility

​Constraints

​Composed example

​Related

​Why it works this way

​Status