Design an offline screen for a desk terminal

Desk Terminal is a miniature desktop-style display with a small colour screen. If you build a supported custom dashboard around it, plan the unavailable-data view alongside the normal layout. A screen that remains on does not prove its information path is working. The offline state should explain what is missing without making an old result look freshly confirmed.

Which connection has been lost?

Distinguish the device's connection from the bridge's access to the data source. The display may still communicate locally while a remote service is unavailable. A generic offline label can be adequate for attention, but the detailed status should identify the boundary you can actually observe.

Do not claim a specific cause from missing data alone. A failed request might reflect network trouble, expired access or a service error. Keep the visible explanation proportionate to the evidence and place technical diagnostics in a companion view where they can be read properly.

Should the last-known value remain visible?

Retain it when it helps the user, but label its age and uncertainty clearly. A previous successful task result can remain historically true while no longer answering what is happening now. Avoid presenting it with the same visual treatment as a newly checked state.

For information that could mislead when old, consider replacing the main value with unavailable and keeping the previous value secondary. Choose based on the decision the dashboard supports. Do not substitute zero for missing data unless zero was actually reported by the source.

What should the user be able to do?

Provide a short next step, such as inspect the source on the main computer or check the bridge's status. Keep credentials and detailed error payloads out of the display. A small screen should help the user find the investigation route without becoming a crowded diagnostic console.

Confirm any interaction capability before designing a retry button or link on the device. If the supported interface is display-only for your intended use, put recovery controls in the companion software. Avoid implying that a proposed custom control is already part of the stock setup.

How should recovery be tested?

Simulate loss of source access in a controlled setup, then restore it and require a fresh successful observation before returning to the normal view. Include a restart with cached data so startup cannot make an old value current merely by redrawing it.

Review the Desk Terminal hardware details for confirmed setup capabilities. A useful offline design is part of the dashboard integration: it preserves honest context, points to a next action and restores confidence only when new evidence arrives.