54 — UX/UI review — start simple, many ways of working (consolidation)

Consolidation / UX-UI review doc. Governed by 00-ROADMAP.md — defer to it on any conflict. Created 2026-07-04 (owner + stakeholder session). Stakeholder: "many people would work in many different ways, probably even in ways we don't fully think of" and — on attributes — "have like a bubble or plus sign to add more". Owner: "starting portals with almost nothing and allowing further configuration in a user-friendly way… tackled from the very beginning."Builds on: doc-37 · doc-43 · doc-47 · doc-48 · doc-49 · doc-50 · doc-51 · doc-52 · doc-53 (+ doc-15 for the [untitled] competitor row, doc-24 for the folded Home-header item).

Decisions locked (2026-07-04):

1. Principles 7 & 8 appended to doc-47 §7 — start almost empty · many ways of working (§2).
2. Home v2 = non-scrollable, one screen ("bold philosophy") — §3.1.
3. The Contact tab — 5th tab, extreme right (naming open): Contact ID + account + Discovery — §3.2.
4. Event = card + sheet, Portal-compatible, no full Portal v1 + contact↔event cross-refs — §4.
5. doc-49 §7 fork 4 (disclosure aggressiveness) resolved — portals start almost empty — §3.3.
6. Housekeeping: reference_assets/ committed/pushed as-is (doc-51 §5 Q1 closed) · handle sonnance.com/@username approved (doc-53 §6 Q1, pending doc-21 reconciliation).

Like doc-47, this doc invents no new capability — it consolidates a review session into decisions, places them into the existing docs, and sequences the builds.

---

1. Session context — what was resolved

Owner answers to the docs-51/52/53 open forks:

• Assets: reference_assets/ (the 38 Apple Invites screenshots) is committed and pushed as-is — no LFS, no local-only. Doc-51's links hold for every clone.
• IA for the two headline features: a new Contact tab (naming open — "or better naming") at the extreme right of the tab bar, providing access to Contact ID + user config (account) + Discovery — the Discovery entry sits top-right of the Contact view. Discovery is not a fourth zone; it hangs off the identity corner (§3.2).
• Event Portal: the owner's envisioning never included a full Event Portal — and asked for our recommendation (§4) plus cross-references from user content: "at least the contacts should have reference, like the ones assisting, inscribed, and assisted" → contact cards reference event relations (attending · registered · attended), events reference people.
• Handle scheme: sonnance.com/@username approved as proposed in doc-53.

Stakeholder direction (the meat of this review):

• Redesign Home; make it non-scrollable. One screen, no vertical scroll — a "bold philosophy" statement. (Closes the field feedback doc-47 already logged: "Home scroll behaviour felt off".)
• Many ways of working. People will work in ways we don't fully anticipate — structure must be offered, never demanded; the same product must serve "the artist that is kind of lazy or doesn't need to fully inform a software" and the multinational studio salesperson / A&R / director. "Many users in many stages with many needs — play smart."
• LEGO attributes must start easy — "a bubble or plus sign to add more attributes." The reference app the stakeholder cited, [untitled], is already our documented competitor (doc-15 L40: Brooklyn "WIP music workspace… sacred place for work-in-progress music") — its start-easy ethos is the bar.
• Workspace + configuration can be hard to onboard. Owner defended that it's needed; agreed stance: progressive configuration, "starting portals with almost nothing", architecturally tackled from the very beginning, shipped when ready (§3.5).

2. Two new principles (locked into doc-47 §7)

Appended to the six north-star principles, exactly as they read there:

7. Start almost empty. The minimum that provides basic/common value as a starting point — grow as you work. Surfaces, portals, catalogs, and configuration all begin at the preset minimum; empty structure never renders — content appears when it exists, affordances offer what could exist.
8. Many ways of working. Structure is offered, never demanded. Lenses, templates, saved views, and optional attributes let a lazy solo artist and a multinational A&R team use the same product; the product never requires configuration before delivering value.

Principle 7 generalizes rules we already shipped piecemeal into one platform law: doc-37 §2.1 ("never show an empty section header"; all-empty → one create-hero), doc-46's "template-first onboarding — never a blank slate", doc-53's "private is the zero-state". This section is the consolidated start-empty doctrine that previously existed only as fragments.

3. Per-surface review

3.1 Home v2 — one screen, no vertical scroll

Decision: DashboardView's outer ScrollView goes away. Home is a fixed one-screen composition; depth lives behind See-all drill-ins (DashboardList) — the only scroll escape. This closes both items of doc-47's logged field feedback: the scroll-feel oddity disappears by design, and the "Home isn't always the right landing" concern is answered by a Resume tile.

The one-screen budget (what earns a slot):

Slot	Content	~Height
Brand header	Bold compact wordmark row (folds in the doc-24 "Home header redesign" item — brand display font, full-bleed treatment)	50–60pt
Attention tile grid (2×2)	Approvals (count + top item) · Open notes (count + top item) · Activity pulse (what changed since last look) · Resume (context-aware jump-back: last portal/track/zone)	200–220pt
Pipeline strip	The doc-50 work-board, condensed to one row of stage chips → deep-links Manage Board	~80pt
Create	Stays the toolbar + (whole-hierarchy create menu, doc-37 §5)	0pt

Total ≈ 400–430pt against ~554pt (SE-class) to ~730pt (Pro-class) of usable screen — it fits, with room for the tiles to breathe. What drops: the four stacked row-lists (each section's rows move wholly into the See-all screens — the per-row what·who·when contract of doc-37 §0 migrates with them); the "Recently opened" list collapses into the single Resume tile. The doc-37 §2.1 empty state (create-first-artist hero) already fits one screen and is unchanged.

Stated policy, not afterthoughts:

• The philosophy bans vertical scroll. The pipeline strip may keep its horizontal chip scroll (or cap at ~4 stage chips — owner taste, §6).
• Dynamic Type accessibility sizes re-enable scrolling (standard iOS practice; a fixed layout that clips at AX sizes is not "bold", it's broken).
• Tile priority when space is short (small devices, or if a fifth tile ever earns a slot — something must leave, the screen never grows): Approvals > Resume > Notes > Pipeline > Activity.

The tile contract (added 2026-07-04 — owner: "confirm/envision/align the different tiles, the info that references, and the info that appears inside"). A tile = count + one one-line top signal, never a list; the drill-in owns the doc-37 §0 what·who·when row contract:

Tile	On the tile (references)	Inside (the drill-in)	Source
Approvals	Role-aware title · count · top item's track name	Full approval list: what·who·when rows, hierarchy long-press; (later) inline approve per doc-42 Queue	/mobile/dashboard pendingApprovals
Resume	Last-opened track name + artwork	The player itself (zoom + prewarmed audio)	recents[0]
Open notes	Count · first note snippet	Rolled-up notes with provenance breadcrumbs → their source	/comment/rollup/me
Activity	Unread count (else total) · latest title	The notification feed; (later) tap-through by pointerId	/notification
Pipeline strip	Stage chips with counts ("Ready" green)	Manage ▸ Board deep-link	/management/board

Future tiles (doc-38 pulse, Discovery RSVPs as the doorbell) enter only by displacing per the priority order — the screen never grows.

3.2 The Contact tab — the identity corner becomes a place

Decision: a 5th tab at the extreme right: Contact ID (the card + contacts graph, doc-53) + account/user config + the Discovery entry top-right of the view (doc-52). It absorbs the AppMenuDrawer duties (identity block, appearance, sign out); lean = the Home avatar affordance retires — one identity home, not two. This realizes doc-47 §10.3's "account = own corner" as a literal tab and exercises doc-37 §5.4's escape hatch ("promote most-used to the tab bar if needed").

Naming (owner picks — candidates with trade-offs):

Candidate	For	Against
Contact	Brand-coherent with Contact ID; the handshake word	Can read as address-book or "contact support"
You	iOS-idiomatic (App Store precedent), warm, obvious	Hides that Discovery lives here
ID	Short, brandable, literally the feature	Cryptic before you know the product
Network	Captures graph + Discovery together	Loses the account/config connotation; LinkedIn-flavored
Profile	Instantly understood	Generic; undersells the card/"club" vision
Me (owner, 2026-07-04)	Short, personal, iOS-familiar	Undersells Discovery; reads self-centered for a networking surface
World (owner, 2026-07-04)	Evokes discovery + the outside; roomy for events/maps	Vague about identity/account; less tied to the Contact ID brand

Resolved (owner, 2026-07-04): name = "Contact" — and the icon carries the tab: the signed-in user's avatar in a circle (falls back to person.crop.circle when there's no photo), since the icon disambiguates the "ambiguous tab" better than any label, at least for now. Shape = Option B (zoned tab) confirmed; organizers path A confirmed. Shell SHIPPED same day (ContactTabView: Identity seed card + absorbed account duties + Discovery corner → placeholder; the drawer slims to Library overflow only).

Relationship to Home: Home stays Discovery's doorbell — an invite awaiting your RSVP is exactly a "needs my attention" item (Approvals/Activity tiles). The Contact tab is Discovery's home. Same pattern as approvals: surfaced on Home, lived-in elsewhere.

3.3 Portals start almost empty — doc-49 §7 fork 4 resolved

The fork asked "how aggressive is progressive disclosure — owner taste." The answer is principle 7:

Zone (doc-49 anatomy)	Default state
1 Identity · 3 Content	Expanded (as built)
2 Health · 4 Workflow/Config	Collapsed to a one-line summary chip
5 Relationships · 6 Notes · 7 Personal · 8 Manage	Collapsed
Any zone with no content	Doesn't render at all — mirror of doc-37 §2.1

Instead of empty zones, a single "+" affordance at the Portal foot offers the unfilled zones (add a note · add attributes · share · add files…). A new portal shows Identity + Content and almost nothing else — "starting portals with almost nothing" — and grows as the node accrues real content.

Build vehicle to flag: there is no shared empty-state component today (each surface hand-rolls) — the portal pass should extract a shared EmptyState / add-zone affordance component in the DesignSystem, used by Portals, Home, and Manage alike.

Reference implementation SHIPPED (2026-07-04): DesignSystem/Components/PortalAddFoot.swift — the dashed "open slot" foot affordance (one unfilled zone = direct labeled button; several = one "+ Add" menu) — applied first on the Track Portal: the Files zone now renders only when it has content; when unfilled, the foot offers "Add file" (folder dialog → picker; uploading/error states surface at the foot). Roll-out to the other four Portals + more parent-knowable zones = the remainder of this slice.

Roll-out SHIPPED (2026-07-04, same day) — audit + application per altitude:

• Workspace — the Roster zone renders only when artists exist; a brand-new studio gets one dashed "Create your first artist" slot at the foot (→ create sheet → lands in Browse) instead of an empty command center (§3.7 delivered).
• Project — the ALBUM ART section renders only when a cover exists (viewers no longer see "No cover yet" dead weight); the foot offers "Add cover", which reveals the art tools in place (offer-then-expand — the second foot grammar besides direct-action).
• Artist — no unfilled zone: roster/tag live as identity-metadata rows (not zones) and the My-tag zone self-loads. Joins the foot when a parent-knowable signal exists.
• File (the leaf) — no change by design: a version's only growable content is its anchored Notes, whose emptiness is knowable only inside the self-loading section — the Notes zone header is the leaf's add affordance for now; it joins the foot when doc-33 exposes counts to parents.

3.4 LEGO starts easy — doc-43 sharpened, not changed

The stakeholder's "bubble or plus sign" is doc-43's locked decision 3 (authoring = inline quick-add + catalog editor). This review sharpens it:

• The quick-add "+" is THE primary authoring surface — present on Portals (§3.3's foot affordance) and mgmt.ctrl rows. The Workspace Settings catalog editor is the secondary power surface, not the front door.
• Default visible attribute set = the minimal preset — a handful of near-universal fields; everything else exists in the preset catalog behind the "+". [untitled]'s ethos (doc-15) is the bar: the lazy artist keeps working and still knows where things are; presets scale up to label-distribution needs without ever confronting the solo artist with them (already doc-43's promise).
• Premium gate reconciled with "start easy": the free tier's "+" picks from the shipped preset catalog — doc-43 already rules that reading/using is never gated. Only defining new custom definitions (catalog-write, the workspace overlay) stays the Pro gate. So the "+" works day one for everyone, and the upgrade moment is "I want my own fields", not "I want any fields".

3.5 Workspace & Configure — progressive onboarding

The stakeholder's concern (hard to onboard/understand/use) meets the owner's defense (it's needed) in one stance: configuration is a place (principle 4) that appears as it becomes relevant (principle 7).

• Zero-setup already works: the doc-48 cascade ships — a new project inherits the studio default workflow with no configuration at all. That's the model for everything Configure governs: the preset minimum is always in force; Configure is where you change it, never a prerequisite.
• Surfaces appear when relevant: a workspace with one artist doesn't push roster defaults; the Attributes row materializes when the first "+"-add happens (or is offered contextually), rather than sitting as a "SOON" promise. Configure stays an honest thin shell that grows into itself — the same doc-37 §2.1 grammar at zone scale.
• No wizard. The superseded-era /onboarding step-wizard (doc-17 / legacy web) is not the model — progressive disclosure in place beats an interrogation up front (doc-46: "never a blank slate" means good defaults, not forms).
• Sequencing honesty: the onboarding layer may not ship in the first release — but every surface is built empty-first from the beginning (per §3.3), so shipping it later is enabling, not rebuilding. This is the owner's "tackled from the very beginning" made concrete.

3.6 mgmt.ctrl — course confirmed under pluralism (no change)

Reviewed against principle 8, doc-42 already is it: the registry-driven view modes (Timeline · Matrix · Queue · Board · Insights · Saved) are ways of working made literal — the same catalog state consumed as a feed, a grid, an inbox, or a pipeline. Saved views (★) are the pluralism instrument: your way, persisted. The registry's per-workspace-configurable seam is exactly how ways-of-working we haven't thought of land without rewrites. No edit to doc-42.

3.7 Workspace / Roster

• Roster stays a tag/lens (doc-48, doc-49) — restated under principle 8: a lens you may use, never a required container. No roster config anchor (doc-48 §8 lean confirmed).
• Workspace Portal starts almost empty: Identity + the preset defaults in force; roster overview, KPIs, members, asset cloud render when non-empty per §3.3 — so the studio root onboards itself as the studio grows instead of greeting a new user with an empty command center.

4. The Event answer — card + sheet, cross-referenced through the graph

Recommendation (owner asked): no full Portal v1 — matching the owner's envisioning. The Event ships as a card + sheet composed from the existing PortalZone grammar, which makes it Portal-compatible without the ceremony:

• Identity = the event card (doc-51 INV-01: hero · title · when · where · host mini-card)
• Health = RSVP counts + time-to-date
• Content = when/where detail · lineup · tiles (INV-16)
• RSVP stays pinned on the card (INV-02) — the request-for-action leads.

Graduation criteria (when a full doc-49 Portal is earned): host-verb volume (notes, guest management, re-invites), tile depth, and afterglow content (recaps, recordings) start crowding the sheet. Until usage demands it, the sheet is the calmer, principle-7 answer. (Resolves doc-52 §9 Q2 and doc-51 §5 Q2.)

Cross-references live in the graph, not a Portal (the owner's "assisting, inscribed, assisted"):

• Contact cards gain event relations — attending (upcoming, RSVP going) · registered (RSVP'd/inscribed) · attended (past) — derived from doc-52's first-class rsvps[] / lineup[] / guest records, shown under the doc-53 §3 visibility lenses (an outsider sees only what the owner opted in).
• Events reference people — host · lineup · guests — as Contact refs, feeding the "met at ⟨event⟩" provenance doc-53 §4.3 already envisions (doc-36 provenance grammar).
• No schema work this pass — doc-52 §7's sketch already carries the records; this fixes where they surface.

5. Build-slice sequencing

✅ GREENLIT by owner (2026-07-04) — with added design input captured in §8 (Home corners · identity-corner inner IA · event organizers). Slice 1 (Home v2) proceeds; slice 2 (Contact tab) builds after the owner picks from the §8.3 options.

1. Home v2 — non-scrollable one-screen + Resume tile + bold brand header. Most visible; closes logged field feedback; touches DashboardView (+ DashboardList enrichment) only.
2. Contact tab shell — 5th tab in RootTabsView/AppRouter; absorbs AppMenuDrawer; Contact ID card placeholder + Discovery corner stub. Unblocks the docs-52/53 builds.
3. Portal empty-state pass — §3.3 defaults + the shared EmptyState/"+"-affordance component rolled across the five built Portals.
4. LEGO quick-add — preset-pick "+" on Portals; Configure ▸ Attributes graduates from "SOON". Prerequisite: the doc-43 preset-catalog backend slice.

6. Open questions for the owner

1. Contact tab name — pick from §3.2 (or better).
2. Non-scroll strictness — horizontal chip rows OK? Confirm the Dynamic-Type AX scroll exception; confirm the small-device tile drop order (§3.1).
3. Home avatar — retire entirely once the Contact tab exists (lean yes), or keep as a shortcut?
4. Event card v1 minimum — Identity + RSVP + when/where certain; is the Health line (counts/time-to) in the v1 cut?
5. Onboarding layer — first release or architecture-only? (Current lean: architecture from the start, ship when ready — confirm at the Release cut.)
6. doc-21 namespace reconciliation for @username — schedule the pass (users vs artists vs workspaces collision policy).

7. Cross-references placed by this doc

Doc	What changed there
doc-24	Home-header item folds into Home v2
doc-37	Home v2 non-scrollable banner + §2 tiles note
doc-43	Decision 3 sharpened ("+" primary, free-tier preset picks)
doc-47	Principles 7–8 appended · §10.3 Contact tab · field feedback resolved
doc-48	Progressive Configure onboarding note
doc-49	§7 fork 4 resolved (start almost empty)
doc-50	§6 note: Home composition = non-scrollable one screen
doc-51	Asset note resolved (committed as-is)
doc-52	§3/§9 Q1+Q2 resolved (Contact tab; card+sheet) · §7 cross-refs note
doc-53	Placement (Contact tab) · §6 Q1 handle approved · §4.3 event relations
doc-42	No edit — course confirmed (§3.6)

---

8. Addendum — greenlight round (owner, 2026-07-04)

The owner greenlit §5 and added design input on Home's corners, the identity corner's inner IA (situating Contact ID · contact list · Messaging · Discovery · Events · Maps), and event organizers. Presented as options with pros/cons (owner's working style); recommendations marked. New tab-name candidates (Me, World) added to the §3.2 table.

8.1 Home top-right "+" — confirmed; it was already designed

Owner: a "+" at top right to add a new element across the Artist / Project / Track / Version dimensions. That is exactly doc-37 §5's queued whole-hierarchy create menu — confirmed into the Home v2 slice. Scope options:

Option	Pros	Cons
A. Hierarchy create only — Artist · Project · Track · Version/upload (recommended v1)	Matches the owner's stated dimensions; small menu; principle 7	Other creations (Event, note) wait for their surfaces
B. Universal create — + Event · note · share link	One habit: "+ creates anything"	Menu grows; context-bound creations (a note needs a node) get awkward from Home

Recommendation: A now, grow into B — the "+" is a menu, so growth is additive: "New event" joins it when the Contact tab ships (doc-52), never a redesign.

Updated 2026-07-04 (same day): the owner flagged two missing creations. New version (of an existing track) — SHIPPED into the "+" menu: artist → album → track pick → the existing upload sheet auto-presents on the player (route-carried intent). Add file (to any hierarchy element) — ships first at its natural home, the Portal Files zone (doc-45 step 1, Track altitude SHIPPED same day); a "+"-level "Add file…" joins once the generalized any-node model (doc-45 step 2) exists.

8.2 Home top-left — options

Option	Pros	Cons
Nothing (recommended once the Contact tab lands)	Bold + calm; the brand header breathes; principle 7 (no structure without value)	—
Avatar → Contact-tab shortcut	Continuity with today	Redundant with the 5th tab it points at
Configure shortcut (owner's "probably config" instinct)	Config nearby	Configure is already a tab — a double entry violates "one home per thing"
Workspace/context switcher	Future multi-workspace	Premature — no multi-workspace yet; reserve the corner as the future slot for it

Recommendation: nothing (v1: keep today's avatar until the Contact tab ships, then retire it — §6 Q3 lean confirmed). If multi-workspace ever arrives, this corner is its natural home.

Confirmed (owner, 2026-07-04, via doc-55 §6 Q4): the top-left corner is the future workspace switcher — reserved, built when multi-workspace ships.

8.3 The identity corner's inner IA — situating everything

Owner's imagined path: tab ("World"/"Me") → tap Discovery → tap Events. Three shapes considered:

Option A — corner-portal stack (the owner's sketch). The tab shows the Contact ID card + contacts; Discovery is a top-right corner entry; Events/Maps live inside Discovery. Pros: calmest; identity-first; Discovery stays a contained "place". Cons: Events sit 3 taps deep — a Release headline feature hidden in a corner of a corner; Messaging has no seat.

Option B — zoned tab (recommended). The tab is itself a doc-49 zone stack — the same grammar as every Portal, at personal altitude:

Zone	Content	Drill-in
Identity	The Contact ID card (QR · share · Wallet)	Card detail / edit
Contacts	Top contacts/mutuals row	Full contact list
Messages	Recent threads	Thread → conversation
Discovery	Upcoming/nearby events strip + "Open Discovery →"	The full Discovery surface (browse · later Maps)
(foot)	Account/config row · "+" affordance	Settings

Principle 7 native: a brand-new user sees just their card and a "+" — Contacts/Messages/Discovery zones appear as content exists. Discovery also keeps the owner's top-right corner entry (icon → the same full Discovery surface the strip's "Open Discovery →" reaches — sketch and zones coexist). Pros: everything ≤ 2 taps; one grammar; start-almost-empty; both headline features visible on arrival. Cons: denser than a pure profile; needs zone discipline to stay calm.

Option C — segmented control (You · Contacts · Discovery).Pros: flat, fast switching. Cons: segments hide each other (undiscoverable); fights the zone grammar; Messaging still unplaced.

Recommendation: B (with A's corner entry retained). Situating the rest:

• Messaging — the threads list lives in the tab's Messages zone; conversations also open from any contact card (doc-53 §4.2 gate) and from notifications. Same doorbell/home split as Discovery.
• Contact list — the Contacts zone → full-list drill-in (with the doc-53 lenses: mutuals · who-has-me · event relations).
• Maps — a lens inside the full Discovery surface, appearing when geo ships (doc-52 §8 defers geo depth) — not a top-level place.

8.4 Event organizers — same app, role-driven

Owner: creators/admins/contributors must edit event info; believes the same iOS app — confirmed, and principles 5 (never fork per persona) + 8 make it doctrine. Options:

Option	How	Verdict
A. Same app, role-driven	Event roles ride doc-44 grants (principal, role, scope=Event): host/admin/contributor get edit verbs on the event card+sheet exactly as project collaborators do on Portals; the Hosting lens (INV-05/06) surfaces "my events"; their Contact ID gains a hosting relation (joins attending · registered · attended) + optional host badge	Recommended — zero new surface, one graph
B. Organizer dashboard	A mgmt.ctrl events lens (Queue = RSVPs to approve · Board = events by lifecycle stage)	Growth path — build when a host's event volume outgrows the sheet (same graduation logic as §4)
C. Separate app / mode	—	Rejected — forks the product (principle 5), splits the graph

Identification ("Event…something"): not a new account type — a role on the Event node (doc-44) plus a Contact ID facet (host badge + hosting relations). The doc-17 "Event Organizer" actor is served by lenses over the same app, not a fork. How much adaptation? Almost nothing structural — which is exactly the doc-44/47 architecture paying off.

8.5 Decisions this addendum leaves with the owner

Joins §6: (a) pick the §8.3 shape (recommendation: B) — gates the Contact-tab slice; (b) confirm organizers path A (+ B as growth); (c) tab name — now 7 candidates (§3.2). Home v2 (slice 1) is unblocked: "+" = hierarchy create menu (8.1-A), top-left keeps the avatar until the Contact tab ships (8.2).

All three resolved (owner, 2026-07-04): (a) B confirmed · (b) A confirmed · (c) **"Contact"

• avatar-in-circle tab icon** (§3.2 note). Owner device-QA passed for Home v2, the Files zone, and "New version". The Contact-tab shell shipped the same day; next slices on it = Contact ID card growth (QR/share, doc-53) · Contacts/Messages/Discovery zones as their content arrives.