SurfaceWorks gives a product a face without the product writing a UI. Any product that exposes a
control plane and publishes a self-describing control surface (a CommonTongue SurfaceDescriptor) can
be rendered here: SurfaceWorks turns that description into a live, accessible interface — generically,
with no product-specific code. Camera daemons, light controllers, and control decks are the first
consumers, but the contract is open — anything that can describe its controls can be rendered.
- Lucidity — the reference renderer. Reads a
SurfaceDescriptorand builds an accessible web UI. One renderer for every product; the descriptor privileges none (others may exist). - Palette — the widget vocabulary. The recommended, extensible catalogue of the control widgets a renderer draws — sliders, knobs, gauges, colour wheels, key-grids, trackballs, meters. A vocabulary, not code.
- Codex — the role vocabulary. The recommended, extensible
catalogue of cross-vendor control meanings —
brightness,aperture,illuminance,pan,macro_trigger— so renderers and aggregators understand "the same control" the same way across brands.
Codex and Palette are recommended, not required, and grow by PR — align to them for interop across the
wider ecosystem, or roll your own (x.<vendor>.* / a custom widget) and still render.
Accessibility · Ease-of-use · Speed · Choice. Accessibility is first, not a retrofit: a control that can't be operated by keyboard and screen reader, or whose meaning lives in colour alone, does not ship.
SurfaceWorks defines no wire standards of its own. It consumes the SurfaceDescriptor contract from
CommonTongue and conforms to the shared substrate
published by CommonPractices
(CommonMind,
blueprints) — incorporated by reference, never restated
here.
Contributions welcome from anyone. See the org's CONTRIBUTING, and open an issue before anything
non-trivial.