Surfaces and platforms

A Denote project declares which platforms it targets, and the design is captured per surface. A phone screen and a desktop screen of the same product share the ontology and the screen inventory, but they don't share a layout. Denote keeps one set of structural decisions where the platforms agree and separate decisions where they don't.

Product types and surfaces

At project creation you pick one or more product types:

• Responsive web — a web app that adapts from desktop to phone.
• Desktop app — an installed desktop application.
• Native mobile — an iOS/Android app.

Each product type expands into one or more surfaces, the concrete frames the design targets:

The choice is stored in design/project.json and editable later in Project settings. Adding a product type backfills sensible defaults; removing one deletes that platform's surface-specific data after a confirmation.

A single-surface project never has to think about any of this. The surface machinery only becomes visible when a second surface exists.

What is captured per surface

Four things can differ between surfaces:

• Availability — a screen, shell, or overlay rule can be limited to specific surfaces (an admin console that exists only on desktop, an action-sheet confirmation that exists only on the phone). When nothing is specified, the element appears on every enabled surface.
• Layout — each screen carries a template + variant per surface. The same Recipes screen can be a filterable card grid on desktop web and a single-column card list on the phone.
• Composition — the Screens layer composes each page once per surface it appears on. Mobile compositions can additionally carry a floating action button.
• Navigation — edges can be tagged per surface, so the desktop sidebar and the phone tab bar can expose different routes.

Everything else — the vision, the ontology, the screen inventory itself — is shared. The point of the model is that platforms differ in expression, not in what the product is.

The surface switcher

Multi-surface projects get a surface switcher in the page header of the Architecture layer and every Screens view. Switch to a surface to see and edit that surface's layouts, compositions, and navigation. On narrow surfaces the Architecture canvas renders screens as portrait phone frames, so the sitemap reads like the platform it describes.

The switcher hides itself on single-surface projects.

[Screenshot TODO: Architecture sitemap on the phone surface, portrait nodes, surface switcher visible in the page header.]

Some patterns are desktop-only

A few templates only make sense at desktop width (dense filter-panel tables, multi-column comparisons, permission matrices). Denote flags these in the catalog, and the app shows an advisory when a desktop-built variant is assigned to a narrow surface. The skills prefer narrow-friendly variants for phone layouts.

Surfaces that aren't designed yet

You don't have to design every surface before handing off. A screen can have a layout on desktop web and none yet on the phone. The Spec marks such surfaces as not yet designed and instructs the implementer not to invent a layout for them. Designing the missing surface later is a normal /architecture + /screens refinement.

Where to next

• Architecture — where per-surface availability and layouts are committed.
• Screens — where per-surface compositions are drawn.
• Spec — how the per-surface picture is written for the implementer.