Frontend design: app shell, component library and design language #81

New issue

Closed

opened 2026-10-07 18:00:48 +00:00 by crowmaki · 1 comment

crowmaki commented

2026-10-07 18:00:48 +00:00

Owner

Parent

#24

What to build

Decide the app's frontend design: the shell layout, the navigation model, the component library and the design language. Today every feature is added to one temporary page (src/routes/+page.svelte), and no ticket asks for a UI pass. This ticket makes the decision. The next ticket builds it.

Use the prototype workflow, as with prototype/crop-sheet, prototype/dailies and prototype/board-paint. Put two or three shell variants on a prototype/app-shell branch behind the existing PrototypeSwitcher, with fake data.

Each variant shows:

Navigation across the Project's sections. Start from this list and change it as needed: Script, Entities (Characters, Locations, Props), References (Reference sets, Source sheets, Lock snapshots), Scenes (Setups, Shots, Boards), Dailies (per Scene), Animatic (per Scene), Export, Storage, Project settings (Lighting, slug table, slot order, Notation set, Generation profile), ComfyUI status.
Persistent chrome: the dockable Queue panel and the status-bar indicator (User Stories 136 and 137), the ComfyUI Ready / Not ready state, and undo / redo (US 11).
Multi-window: how a second window on the same Project opens and what it shows, for example Dailies next to the Animatic (US 13).
A component approach, one per variant, for example headless primitives (Bits UI / Melt UI), a styled kit (shadcn-svelte, Skeleton), or our own tokens and plain Svelte components. Judge each one on dense, desktop-style tool UI (tables, inspectors, splitters, context menus, keyboard shortcuts) and on how well it fits the three existing prototypes.
Design language: colour (dark-first for screening video), type scale, spacing, density, and how scene / setup / take naming (12A-3) and badges (stale, over budget, circled, NG) look.

Acceptance criteria

prototype/app-shell has two or three runnable shell variants with fake data that cover the points above
The chosen variant is recorded as ADR-0006: component library (or none), design tokens, the navigation model and section list, the Queue panel and status-bar placement, and the multi-window model
The section list and route map are written in the ADR so that the scaffold ticket can build them without more decisions
Any new terms are added to CONTEXT.md

Blocked by

None (can start immediately)

## Parent #24 ## What to build Decide the app's frontend design: the shell layout, the navigation model, the component library and the design language. Today every feature is added to one temporary page (`src/routes/+page.svelte`), and no ticket asks for a UI pass. This ticket makes the decision. The next ticket builds it. Use the `prototype` workflow, as with `prototype/crop-sheet`, `prototype/dailies` and `prototype/board-paint`. Put two or three shell variants on a `prototype/app-shell` branch behind the existing `PrototypeSwitcher`, with fake data. Each variant shows: - **Navigation** across the Project's sections. Start from this list and change it as needed: Script, Entities (Characters, Locations, Props), References (Reference sets, Source sheets, Lock snapshots), Scenes (Setups, Shots, Boards), Dailies (per Scene), Animatic (per Scene), Export, Storage, Project settings (Lighting, slug table, slot order, Notation set, Generation profile), ComfyUI status. - **Persistent chrome**: the dockable Queue panel and the status-bar indicator (User Stories 136 and 137), the ComfyUI Ready / Not ready state, and undo / redo (US 11). - **Multi-window**: how a second window on the same Project opens and what it shows, for example Dailies next to the Animatic (US 13). - **A component approach**, one per variant, for example headless primitives (Bits UI / Melt UI), a styled kit (shadcn-svelte, Skeleton), or our own tokens and plain Svelte components. Judge each one on dense, desktop-style tool UI (tables, inspectors, splitters, context menus, keyboard shortcuts) and on how well it fits the three existing prototypes. - **Design language**: colour (dark-first for screening video), type scale, spacing, density, and how scene / setup / take naming (`12A-3`) and badges (stale, over budget, circled, NG) look. ## Acceptance criteria - [ ] `prototype/app-shell` has two or three runnable shell variants with fake data that cover the points above - [ ] The chosen variant is recorded as ADR-0006: component library (or none), design tokens, the navigation model and section list, the Queue panel and status-bar placement, and the multi-window model - [ ] The section list and route map are written in the ADR so that the scaffold ticket can build them without more decisions - [ ] Any new terms are added to `CONTEXT.md` ## Blocked by - None (can start immediately)

crowmaki referenced this issue

2026-10-07 18:00:52 +00:00

App shell scaffold with section views #82

crowmaki added the

enhancement

ready-for-human

labels

2026-10-07 18:00:52 +00:00

crowmaki commented

2026-10-08 01:38:54 +00:00

Author

Owner

Prototype verdict

Question: which app shell, component approach and design language should the app use?

Prototype: branch prototype/app-shell, route /prototype/app-shell?variant=A|B|C. It has three variants on fake data, with popup windows synced over BroadcastChannel:

A, Workbench (plain Svelte, our own tokens): activity rail, sidebar tree, editor tabs, inspector, a bottom/right Queue dock and a status bar.
B, Scene desk (Bits UI): section tabs across the top, a scene switcher, status in the header, a right Queue dock, and companion windows that follow the main window's Scene.
C, Split panes (shadcn-style: Tailwind v4, Bits UI and PaneForge): command palette, resizable panes, a bottom Queue pane, and pop-out windows.

Verdict: A's shape with parts from B and C.

Layout: A's workbench, density and status bar, and its dockable Queue panel.
Tabs: dropped. A Pane shows one view, and a window has at most two Panes, split with PaneForge as in C.
Primitives: Bits UI, as in B (hand-rolled menus were A's weakest part), plus B's scene switcher.
Second window: follows the main window's Scene unless pinned, as in B.
Styling: our own CSS tokens, with no Tailwind or shadcn. Stock shadcn sizing was too roomy, and Tailwind needed its preflight turned off.

The decision, the section list, the route map and the tokens are recorded in ADR-0006 (branch issue-81-app-shell). The new terms Section, Pane, Secondary window and Queue panel are in CONTEXT.md.

## Prototype verdict **Question:** which app shell, component approach and design language should the app use? **Prototype:** branch [`prototype/app-shell`](https://git.crowmaki.me/crowmaki/ai-studio/src/branch/prototype/app-shell), route `/prototype/app-shell?variant=A|B|C`. It has three variants on fake data, with popup windows synced over BroadcastChannel: - **A, Workbench** (plain Svelte, our own tokens): activity rail, sidebar tree, editor tabs, inspector, a bottom/right Queue dock and a status bar. - **B, Scene desk** (Bits UI): section tabs across the top, a scene switcher, status in the header, a right Queue dock, and companion windows that follow the main window's Scene. - **C, Split panes** (shadcn-style: Tailwind v4, Bits UI and PaneForge): command palette, resizable panes, a bottom Queue pane, and pop-out windows. **Verdict:** A's shape with parts from B and C. - **Layout:** A's workbench, density and status bar, and its dockable Queue panel. - **Tabs:** dropped. A Pane shows one view, and a window has at most two Panes, split with PaneForge as in C. - **Primitives:** Bits UI, as in B (hand-rolled menus were A's weakest part), plus B's scene switcher. - **Second window:** follows the main window's Scene unless pinned, as in B. - **Styling:** our own CSS tokens, with no Tailwind or shadcn. Stock shadcn sizing was too roomy, and Tailwind needed its preflight turned off. The decision, the section list, the route map and the tokens are recorded in **ADR-0006** (branch `issue-81-app-shell`). The new terms Section, Pane, Secondary window and Queue panel are in `CONTEXT.md`.

crowmaki referenced this issue from a commit

2026-10-08 01:38:54 +00:00

Prototype: app shell, component library and design language (#81)

crowmaki referenced this issue from a commit

2026-10-08 01:50:51 +00:00

ADR-0006: app shell, component library and design language (#81)

crowmaki referenced this issue from a pull request that will close it,

2026-10-08 01:50:55 +00:00

App shell decision: ADR-0006 (#81) #83

crowmaki closed this issue

2026-10-08 01:51:32 +00:00

crowmaki referenced this issue from a commit