4 ms·
A chunk of my early career was writing GUI software to control and display state of remote hardware, and I quickly learned to banish any "stateful" UI elements
by pavon 3y ago
A chunk of my early career was writing GUI software to control and display state of remote hardware, and I quickly learned to banish any "stateful" UI elements - those that retained their own state and changed behavior based on that state, like toggles, switches, check boxes, radio boxes, etc - because it wasn't uncommon for the interface and hardware state to get out of sync.
What I ended up settling on to replace them was a button for each option, where the respective button would light up to display the current state. For example, what would be an on/off toggle became two buttons labeled on and off. Initially both buttons were grey, and when the UI received SOH from the hardware indicating that the state was on, the on button became green, or for off, the off button became red. If communication was lost for some time all the colors became desaturated, to indicate the state was stale. When a button was pressed, the old state continued to be displayed, but desaturated (for just that button set), until a new state was received back. The user could always command the system on or off at any time (by clicking the respective button) regardless of what state the UI though it was in, unlike a toggle which only lets to you change to the "other" state. Likewise, radio buttons were replaced with a series of buttons labeled with their state, and the one the UI thought was current was colored (using blue for most "neutral" states and green/yellow/red if the state had a good/warn/bad meaning to the operator that they wanted to highlight).
Despite the atypical design, I found that operators generally understood the interface without training - buttons looked like buttons so they must be clickable. The spacing of buttons made it clear they were a set, and since grey was the default color of everything in 90s UI, the button that was colored differently stood out and must be the current state. I don't know if that would be the case today, where UI element can be any color chosen for aesthetics or funneling and only sometimes communicate information.
I did experimented with displaying both the commanded state and received state in various ways (akin to NASA's buttons), but all ended up being more confusing.
- Doxin 3y agoInteresting design choices. I can see how that'd work very well. > I did experimented with displaying both the commanded state and received state in various ways Did you try keeping the commanded button in the pressed state until the next state update? I feel like that should be fairly intuitive to most people, and it'd still allow you to give a different command while the state hasn't updated yet.