What the interface looks like

Visual intent

• The open note is the main object. Navigation supports reading and writing; it does not look like a task dashboard or a media feed.
• Use restrained type, generous writing space, thin borders and soft selection backgrounds. Reserve strong blue fills for primary actions.
• Keep icons small and consistent. Prefer familiar outline symbols with visible labels or accessible names; do not rely on colour alone.
• Keep the same hierarchy in light and dark mode. Dark mode changes the palette rather than the layout.
• Use the rounded 1:1.618 spacing family: 3, 5, 8, 13, 21, 34 and 55px. The current Simple layout uses a fixed sidebar; do not force every screen into a literal 38.2% / 61.8% split.

Desktop: sidebar and writing area

1. Navigation and creation: two equal tabs, Notes and Files, at the top of the sidebar. Below them, place two equal blue buttons: New note and New folder. Align text and icons to the same grid.
2. Folders and notes: optional folder pills in two columns, followed by note rows. A soft blue row marks the open note. Multi-selection adds a stronger blue edge; hover stays subtle. Long titles truncate instead of widening the sidebar. The list scrolls independently.
3. Persistent footer: settings and sync icons sit beside a short storage/sync status. It remains at the bottom while the list scrolls. Reserve a thin 3px loading strip above the list so loading does not make rows jump.
4. Writing area: keep the page white in light mode, with a modest title and left-aligned prose inside the centered reading column. Do not stretch prose across the whole screen or add a permanent large formatting toolbar.
5. Source content: media lives inside the note as an image, player, reference card or file link. A small View in Google Drive link sits beneath a Drive source. The source remains in Drive; the note adds context around it.

Above 860px, the list and editor are visible together. In Simple mode, the extra file/Drive columns and floating desktop column-switcher are hidden. Choosing Files replaces the sidebar content with the Drive browser in the same column; it does not navigate away from the note or add another column. An explicitly saved Classic layout can retain its existing panel arrangement.

Mobile: one active view at a time

• Use the full width for the active list or editor. Opening a note shows the editor; provide an obvious way back to the list. Do not shrink the desktop columns into two narrow panels.
• Keep tabs and create buttons at least 44px high on mobile. Touch targets are at least 44 × 44px even when the icon itself is smaller.
• Keep bottom actions reachable in both list and editor states. Sync sits to the right of the command control; settings remains available in the bottom bar rather than duplicated in the sidebar footer.
• Reserve bottom padding for the toolbar and safe-area inset. Menus must stay above it and follow the visible viewport when the keyboard appears.
• Prose wraps to the screen width. Tables and other genuinely wide content may scroll inside their own container; the whole page must not scroll sideways.

Colours and surfaces

These values come from the current Calm and Calm Dark theme definitions. Use semantic tokens so changing theme does not require redesigning each component.

Use the softer surface for sidebar chrome and input backgrounds. Use the editor surface for the writing pane and raised controls. A normal row has no heavy outline or card shadow. Reserve elevation for menus, dialogs and overlays. Focus uses a visible blue border/ring; destructive actions use red text or a clearly labelled confirmation, never an ambiguous red icon alone.

Typography and measurements

The app uses self-hosted InterVariable, with system sans-serif fallbacks. Retain the font licence if redistributing the font. Use a monospace stack for code. The Georgia heading on this documentation page is not the app’s note-title style.

Lists follow the note’s text rhythm. Task checkboxes align with the first text line rather than sitting in a separate oversized control row. Quotes use a thin left rule and muted text. Inline code gets a quiet filled background; code blocks can scroll internally. Links use blue and remain visibly recognisable as links.

What each interface component should look like

Loading, empty, selected and error states

• Empty: a short No notes yet message and one New note action in the editor area. Do not fill the screen with invented charts or sample user data.
• Loading: keep stable space for the list’s thin loading strip. If a local note exists, render it while Drive refreshes in the background; do not replace it with a full-page spinner.
• Local / queued / syncing: a concise status beside sync, with a pending count or progress where relevant. A server ticket is not shown as Synced.
• Failure: keep the current text visible, explain the problem and offer retry. Colour alone does not communicate failure. Disconnected Drive has a clear connect/reconnect action.
• Deletion / movement: show a pending row state and keep the exact affected selection clear. Confirmation distinguishes permanent Delete from managing old Trash.
• Selection and focus: the open note gets a soft background; bulk selection adds an edge/count/action bar. Keyboard focus gets a visible ring. Hover must not impersonate either state.

Visual implementation prompt

Read prompt/design.html together with the Solution Intent, Solution Design and requirements.
Use the app visual reference, not the cream/green documentation shell.
Build the default Simple desktop workspace: 360px sidebar, Notes/Files tabs, paired create buttons, optional folder pills, scrolling note rows and persistent settings/sync/status footer.
Use a white editor surface in light mode and a centered reading column capped at 42rem. Use Inter, 16px/1.7 prose and a modest 20px/650 note title.
Use the documented Calm/Calm Dark colour tokens, blue actions, subtle borders and quiet selection states. Match the spacing and component measurements in this chapter.
At 860px and below, show the list or editor as a full-width view, preserve bottom actions and use touch targets of at least 44px.
Keep slash commands and the Drive picker contextual to the caret. Keep dialogs, empty/loading/error states and keyboard focus consistent with the reference.
Use fictional test content. Preserve storage, authentication, sync and deletion contracts; a visual match must not add new behavior.
Compare the implemented screen with this chapter at desktop width and at 390px in BrowserOS Neo. Report visual differences separately from functional test results.

Acceptance checks for visual similarity

1. At a wide desktop viewport, the sidebar is 360px and the editor gets the remaining space. Long text remains inside the 42rem reading measure; there is no unnecessary third column in Simple mode.
2. The sidebar has aligned tabs, paired creation buttons, rounded folder pills, readable note rows and a stable footer. Files replaces its contents without losing the note.
3. Light and dark modes use the specified text/surface/action hierarchy. The note title is 20px, body text 16px and the writing area uses Inter.
4. At 390px, the list and editor are usable separately, with no horizontal page overflow. Bottom actions and caret menus remain visible above the device edge and keyboard.
5. Test keyboard focus, open/selected rows, empty content, Drive disconnection, a queued change and a failed sync. Every state has readable text or an accessible label.
6. Keep visual evidence separate from functional evidence. A convincing screenshot does not prove Drive storage, account isolation or safe deletion.

Use the functional scenarios in V03 and V15 alongside these checks. Security boundaries remain in 08 Security.

Source and scope of this reference

The measurements and colours were checked against local commit 867ca8d on 26 October 2026: src/views/theme-system.js, src/views/scale-system.js, src/views/content-renderers.js, src/views/command-menu.js, src/views/topbar-renderers.js and client/paper/drive-picker.ts. This is a code-based interface reference, not a new inspection of production or a redesign request. Filenames and implementation identifiers stay unchanged.