Personal Research

sas

4 min read

SAS multidimensional density implementation

Evidence status: practitioner-authored implementation case study; production tokens and components are not public.

1. Why this system is relevant

SAS describes adding density to an established enterprise product system that already supported themes and locale-sensitive typography. The account is especially useful for the token-file architecture, mode naming, loading order, and the failure mode created when density and locale both need to affect type.

2. Density terminology

Customer-facing labels:

  • standard
  • compact
  • comfortable

Developer labels:

  • medium
  • high
  • low

The implied mapping is standard → medium, compact → high, and comfortable → low.

3. Density model

SAS treats density as an independent user-selectable dimension. The initial demand came from a data-intensive application; broader interviews, workshops, and user testing validated use across product teams. The article contrasts high-density application workflows with lower-density dashboards, landing pages, and marketing tools without permanently naming the modes after those product types.

4. Token architecture

The previous JSON was organized by theme. SAS changed to a domain-based structure, using domains such as web, product, and mobile and controlling application order through manifests.

The published loading order is:

1. base/core tokens
2. theme override (light default; optional dark/high contrast)
3. density override (medium default; optional low/high)
4. language/locale override

Tokens Studio imports create independent collections for:

  • brand
  • core
  • density
  • languages
  • themes

This avoids precomposed combinations such as dark-compact. It also makes precedence explicit: language loads after density.

Core includes colors, motion, shadows, borders, containers, outlines, and typography properties that are expected to remain broadly stable, such as ratios, tracking, word spacing, font styles, overflow, transforms, and weight.

SAS says every numeric token was evaluated, including:

  • margins, padding, and gaps
  • dialog widths
  • input and card dimensions
  • font sizes and line heights
  • icon sizes
  • border radii

The article does not publish the complete three-mode token matrix. The public numeric typography example is:

CasePublished value
Default font size14px
Compact font size12px
Certain locale defaults16px
Compact minimum12px

The accompanying diagram visibly organizes token families for display type, headings, base spacing, body type, and icons across High, Medium, and Low density, but it does not provide legible/publicly specified values suitable for a reliable token table.

6. Typography behaviour

SAS intended font size and line height to participate, while acknowledging that responsive type ideally belongs to a separate concern. It established minimum values and would not allow compact text below 12px.

Locale precedence prevented a clean universal result. Some locales used a 16px default because of their font family. Since language overrides load after density, those larger locale values were not changed by density switching. SAS explicitly notes that a percentage-based shift might solve this but was not adopted.

This means the implemented architecture is multidimensional but not fully compositional for typography: locale wins over density for affected roles.

7. Representative component examples

The case study specifically identifies table cells and inputs as high-density targets and dialogs, inputs, and cards as dimension families requiring evaluation. It does not publish per-component token names, component props, or rendered values.

8. Design/Figma implementation

SAS uses Tokens Studio Pro multidimensional themes to import domain libraries with separate brand, core, density, language, and theme collections. The article does not reveal the exact Figma collection names, variable mode IDs, inheritance scopes, or component property bindings.

9. Code implementation

The central repository publishes domain JSON files to product teams. Manifests establish override order. The article does not expose the runtime selector, provider, CSS attribute, build transform, or package API.

10. Accessibility constraints

SAS identifies accessibility and user control as density principles and applies a 12px compact type floor plus minimum line-height values. It also notes that some visually impaired users require more separation. No public touch-target minimum or keyboard-specific implementation is given.

11. Limitations / unavailable evidence

  • No production token repository or files are public.
  • No complete numeric mode matrix.
  • No inspectable component bindings or runtime activation.
  • Locale/type precedence is documented as an unresolved limitation.
  • The customer/developer label mapping is clear conceptually, but no API example is published.

Graph View

Backlinks