Skip to main content

Applications

The most visible layer — the software people actually interact with: sending messages, editing documents, managing files. The web browser occupies a special place here too, acting as a universal runtime for a wide range of what actually runs.

Living​

Most of that interaction is direct — touchscreen, keyboard, mouse. Some of it isn't: applications running in the background, syncing, notifying, acting on a schedule nobody set in the moment — indirect interaction, often unconscious. That split is exactly where UX design concerns emerge, and not the same ones each time: a direct interface has to be usable in the moment, while something running unnoticed has to earn trust a different way, by being predictable rather than surprising.

Those concerns aren't ours to name from scratch — they're exactly what Living as a process already addresses, direct interaction and background behaviour alike:

  • Usability — interfaces that work the way people expect, with predictable results.
  • Accessibility — not separating people by ability, device, language, or technical background.
  • Delight — software that's a pleasure to use, not just functional.
  • Trust — knowing the tools are safe, private, and there when needed — earned through consistency, not promised in a terms of service.

A resident's day-to-day experience of the stack is exactly this mix of what's engaged with directly and what just runs, and all four apply regardless of which kind of interaction is happening.

Part of a whole​

Visible doesn't mean simple, though. It's also easy to confuse an app with a service — the interface is what's visible, but what people actually depend on is the service as a whole: the app plus whoever keeps it running. A nicely designed interaction isn't worth much if the service behind it is badly maintained and goes down. Which application solves a given need is rarely a decision this layer can answer on its own — it's shaped by the infrastructure underneath (what a provider makes easy or hard) and by choices made elsewhere in the framework (governance, values, who's accountable) just as much as by the software itself.

We analyse that by service, not by application in the abstract, and defer it to its own place: the actual tool-by-tool record — what each app does, its licensing, why it was chosen over the alternatives — lives in the top-level Services section rather than nested here. This page stays the concept.