Custom Workflows & Data Visualisation

Problem class: Custom workflows and data visualisation—the logic and rules that turn raw data into operational signals (the right information, in the right form, for the right context). Systems involved: Data sources (APIs, databases), transformation logic, display application. Why non-trivial: Data is rarely display-ready; time-based and conditional rules must be explicit and testable; interfaces must prioritise clarity. If done incorrectly: Wrong or confusing information on screen; implicit or untestable rules; clutter that obscures the intended signal. This page explains logic and rules, time-based conditions, conditional visibility, and calm interfaces—not generic dashboard features.

Turning Raw Data into Operational Signals

Raw data from APIs or databases is rarely display-ready. It may be in the wrong format (e.g. codes instead of labels), at the wrong granularity (e.g. per-transaction instead of per-queue), or mixed with irrelevant fields. We design transformation pipelines: fetch, filter, aggregate, format, and render. The result is an operational signal: the right information, in the right form, for the right context. For example, room status might be stored as a code; we map codes to colours and labels and show only what the viewer needs.

Transformation logic is part of the integration. We specify it in code or configuration, version it, and test it. The same discipline applies as for API-driven displays: source-of-truth, clear data flow, and defined failure behaviour. The display is the end of the pipeline; the value is in the correctness of the transformation.

Time-Based Logic

Many operational displays need time-based behaviour: show different content by time of day, day of week, or season; show countdowns or schedules; expire content after a duration. We implement time-based logic as part of the workflow. The logic may live in the display application (e.g. client-side scheduling) or in a central service (e.g. server-side rules). The choice depends on requirements: latency, offline capability, and consistency across many displays. Time-based logic must be explicit and testable. We avoid implicit or hard-coded rules; we prefer configuration or code that can be reviewed and audited.

Conditional Visibility

Not everything should be visible all the time. Conditional visibility means showing or hiding content based on rules: role, location, time, or data state. For example, show sensitive information only to authorised viewers; show queue information only when the queue is active; show alerts only when they are relevant. We design visibility rules as part of the workflow so that the display shows the right information to the right audience at the right time. Conditional visibility reduces clutter and focuses attention.

Calm, Low-Noise Interfaces

Operational displays are often viewed in busy environments: lobbies, corridors, shop floors. Calm, low-noise interfaces prioritise clarity over density. We avoid unnecessary animation, decorative elements, or information overload. Typography, contrast, and layout are chosen for readability at a glance. The goal is that the viewer can get the intended information quickly and without distraction. Calm design does not mean bland; it means purposeful: every element serves a function.