Shell Design Language

Region Type Legend

Every region in an SDL diagram uses a consistent colour and border

Fig 1 — The six region types of the Shell Design Language

Claude Desktop — Annotated

A real application described in SDL terms

Every region is labelled with its SDL type, its name in this application, and its key behaviours. Dashed lines connect regions to their annotations.

Fig 2 — Claude Desktop annotated with SDL region types, zone labels, and behaviours

Claude Desktop — With Artifact Panel

Content-initiated Panel injection compresses the main Viewport

When the user writes code or markdown, a Trailing Panel is injected into the layout. Unlike an Overlay, the Panel participates in the layout — it compresses the Viewport horizontally.

Fig 3 — Panel injection: the Trailing Panel compresses the main Viewport. Compare with Fig 2 where no Panel is present.

Named Compositions

Six common shell patterns built from SDL region types

Fig 4 — The six named compositions of the SDL

Transitions

How the shell changes — before and after states

Fig 5 — Key transitions: Collapse, Lift (breakpoint response), Inject (Panel appears), Eject (Panel closes)

Spatial Viewport Mode

A camera over a canvas, not a window over a flow

The other three Viewport modes — Linear, Staged, Routed — are variations on the same model: content has a position in a one-dimensional flow and the Viewport moves through it. A Spatial Viewport breaks this entirely. Content exists in a two-dimensional coordinate space. The Viewport is a camera that pans and zooms over that space. This difference is not merely visual — it has structural consequences for navigation, selection, object modelling, and the controller relationships between the Viewport and surrounding regions.

Fig 12 — The four Viewport modes. Linear, Staged, and Routed are all variations on a one-dimensional content flow. Spatial is fundamentally different: the camera moves over a two-dimensional object space.

Fig 13 — Canvas shell bidirectional controller relationships. Gold arrows: region drives Viewport. Blue arrows: Viewport drives region. Layers Panel has a bidirectional relationship. Properties Panel is driven only. Activity bar drives only. The minimap is a Viewport Fixture — persistent within the Viewport, not a separate region.

Fig 14 — The four Spatial object models. Free-form: objects anywhere. Node graph: objects connected by edges. Frame-based: objects within named artboards. Tile-based: objects occupy cells in a discrete grid.

Example: Figma

Fig 15 — SDL description of Figma. Note the explicit declaration of bidirectional controllers, the Spatial Viewport properties, and the Viewport Fixture.

How Anchors Relate to Each Other

Span determines the root grid. Toggle buttons create cross-Anchor controller relationships.

The SDL previously described Anchors in isolation — their position, dimension, and persistence. But when two Anchors occupy perpendicular axes (a top header and a leading sidebar), they must negotiate who owns the corner between them. And when a button in one Anchor controls the collapse state of another, that cross-region wiring must be named explicitly.

Fig 16 — Anchor Span. Left: header-dominant — Top Anchor is full-span, sidebar toggle naturally lives in the header and spans the full width. Right: sidebar-dominant — Leading Anchor is full-span, no natural full-width location for a sidebar toggle in the header.

Fig 17 — Anchor-to-Anchor controller relationship. The toggle button in the Top Anchor drives the collapse state of the Leading Anchor. The button icon reflects current state. The Viewport expands to fill reclaimed space. This cross-region wiring must be explicitly named in the SDL description — it is a common source of implementation bugs when left implicit.

Fig 18 — The CSS Grid structure of the Chrome differs based on Anchor Span. In header-dominant, the header uses grid-column: 1 / -1 to span the full width. In sidebar-dominant, the sidebar uses grid-row: 1 / -1 to span the full height. Both use the same two CSS properties but applied to different Anchors — the SDL description tells the developer exactly which to use.

Claude Desktop — Updated SDL Description

Fig 19 — Updated Claude Desktop SDL description, now including Anchor Span declarations and the Anchor-to-Anchor controller relationship for the sidebar toggle.

Multiple Simultaneous Panels

Panel Groups, Panel Policy, and Corner Ownership

A single Panel compressing a single Viewport is straightforward. When multiple Panels are active simultaneously — on the same edge or on different edges — three new concepts govern the behaviour: Panel Group, Panel Policy, and Corner Ownership.

Fig 7 — Exclusive policy (left): opening Panel B auto-ejects Panel A. Additive policy (right): both Panels are open, Viewport compressed from both sides.

Fig 8 — Tabbed policy: multiple Panels share one fixed-size region. The tab bar inside the Panel Group switches which Panel is visible.

Fig 9 — Corner Ownership. Left: bottom Panel Group owns full width, trailing Panel Group stops above it. Right: trailing Panel Group owns full height, bottom Panel Group fills only the remaining width. This must be specified on the Chrome before building.

Writing an SDL Description

A compact, precise notation for communicating shell architecture

An SDL description should be readable by designers and developers alike. It captures enough structure to begin implementation without visual assets.

Fig 10 — SDL description of Claude Desktop. A developer reading this has a clear architectural picture before writing a line of code.

Example: VS Code (with Panel Groups)

Fig 11 — SDL description of VS Code, demonstrating two Panel Groups with different policies and explicit Corner Ownership.