Unifying UI context handling with Context Rails (HCI Nerdz)

The problem: context is encoded differently everywhere

Across web, desktop, and mobile, teams often rebuild “what the UI knows” from scratch.

That usually shows up as:

  • Different screens storing the same intent in different places (querystring vs secure storage vs native state).

  • Different wording and fields depending on where you are in a workflow (but the underlying intent is the same).

  • Inside a single app, different features encoding “context” in different ways (elements vs functions vs feature modules).

The user feels this as friction: the UI behaves like it has amnesia, or like it is asking the user to re-explain the mental model every time.

The metaphor: Context Rails

Context Rails separate meaning from representation.

You treat “context” as a shared model that moves through rails:

  • Instance rails (web / desktop / mobile): adapters translate the same context model into platform-appropriate representation.

  • App rails (within a single app): elements, functions, and feature modules subscribe to the same context model (not ad-hoc copies).

Cross-instance context rails, role and goal layers, and within-app rails

Extra layers: role/goal sieves

Instance rails and app rails unify how context is carried.

Role/goal sieves unify which parts of that context matter right now.

Think of sieves as explicit UI state the user selects (or that the UI clearly justifies), rather than hidden assumptions.

Role and goal sieves filter the activated context bundle:

  • Elements: labels, fields, navigation steps, validation language.

  • Functions: which server-side actions are safe/expected for the chosen role/goal.

  • Features: which workflow modules appear (and which workflow modules are deferred).

Role and goal sieves routing into an activated context bundle

GUI-first scope (with a brief CLI note)

For this concept we focus on GUIs because that’s where teams most often “fork” context into separate UI shells.

If you later apply the same rails idea to CLIs/shells, the adapter can be “render targets” and “input sources,” while the shared context model stays the same.

Demo

Try the interactive mockup here:

Open the Context Rails demo.

In the demo you can switch:

  • Instance adapter rail: web / desktop / mobile

  • Role sieve: who you are in the product ecosystem

  • Goal sieve: what you want to do next

  • Within-app subscription: elements vs functions vs features

The UI should respond by updating both:

  • representation (platform adapter)

  • activation (sieve routing)

Design principle

Don’t “encode context” into a layout category like “OAuth section” or “API keys section.”

Instead:

  1. keep a shared context model in rails

  2. adapt it per instance

  3. sieve it per role/goal

  4. let every element/function/feature subscribe to the activated bundle