R4.09.2library-borne conventiondesign

Conventions ship with the implementation library, spreading through code rather than documents

Aliases: convention in code · Material Components · shipped defaults

What it is

Material reaches a product not when a designer finishes a website, but when an engineer imports a component library. Conventions travel with the binary: how feedback starts, how type scales, how surfaces stack — defaults live in compilable parts. Call this library-borne convention. The carrier is code; documentation is the manual. A sentence that never entered the library never shipped.

This is not the physical metaphor itself, and not how far restyling may go. It explains why apps that never coordinated still feel related: they share an implementation, not a reading assignment.

Why it happens

People take the cheap path. Reimplementing a button’s states, touch feedback, and accessibility role is expensive; calling the library’s button is cheap. Default behavior therefore enters the product with the dependency, even without a design review. Long-form pages do not change that cost structure. A sentence that was read but not referenced does not exist at runtime.

That is also why docs and products drift. Library version, documentation version, and the version the mockups cite can be three numbers. Users touch only the library. A design team that maintains pages decoupled from the library is editing the manual, not the convention. The update channel is the changelog and breaking changes, not a new heading.

Where it stops holding

Platforms with no official library — some embedded targets, a custom renderer, a game canvas — are not library-borne; convention then depends on a homegrown kit or is abandoned. A library forked and patched past followability has already broken the channel; more documentation will not repair it. Pure visual campaign sites that never import the library should not claim to be keeping Material. Docs still teach how to choose parts and how to theme; they do not become the convention in the parts’ place.

Applying it

  • Pin the Material implementation library version in the repo. Align component names in mockups with symbols in the library, not with an illustration on a webpage.
  • Before inventing a control, search the library catalog. If it is missing, file a request against the library rather than drawing a custom set “for reference.”
  • Treat a library upgrade as a design event: read breaking changes and open the affected screens, not merely compile.
  • Verify by picking a high-frequency component and searching the repo for its type name or import. If it cannot be found but the UI “looks like it,” the convention arrived as mimicry, not as distribution. Compare the current library gallery with product screenshots; behavioral gaps are docs that never entered code.

Related

  • Same group: R4.09.1 A physical metaphor unifies hierarchy, space, and motion · R4.09.3 Restyling is allowed provided the skeleton does not change
  • Adjacent: R4.02 Material Design conventions · R4.14 Consistency cost of cross-platform frameworks
  • Search terms: library-borne convention · Material Components · convention in code

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/R4.09.2