5 ms·

I have some old NASA push button switches that have two bulbs in them. When the switch is off both lights are off, when you click the switch the yellow bulb co

I have some old NASA push button switches that have two bulbs in them. When the switch is off both lights are off, when you click the switch the yellow bulb comes on and lights up the switch, and when the device you turned on actually turns on a green light turns on ( and the yellow turns off ). The idea is you push the button and the yellow state is the confirmation that you toggled the switch, but the green is the confirmation that the action you wanted occurred. Kind of an interesting 'state feedback' mechanism.

2OEH8eoCRo0 3y ago
I like it. Why doesn't our "industry" look at aviation/military more often where miscommunication gets people killed.
- ajmurmann 3y ago
  I think the answer is that "looking pleasant" is much more of a goal for commercial software. In usability terms the much denser GUIs of the 90s were arguable better in some ways than what we frequently see today, especially for power users.
  - kfarr 3y ago
    Yes just like the design of car infotainment systems -- looking good resulted in the touch screen era. Luckily we're finally realizing our mistake and a few automakers are putting old school knobs back in.
- deleted 3y ago
  [deleted]
kqr 3y ago
This is a good one, and also what airplanes do[1]. These problems are solved by people who care a lot about usability, but computer people are slow to pick up this sort of stuff from other fields. Labels outside the switch also work.[2] [1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header-1024x568.jpg https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header... [2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef7720454414e4.jpg https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
- pjot 3y ago
  My table saw has this as well. A green and red light, both with off/steady/blink states that indicates information about the blade and safety system.
  - bqmjjx0kac 3y ago
    Mine has this as well! I like the UX, but it's also kind of crazy that they didn't think about red/green colorblind users.
    - thr33 3y ago
      colorblindness would have no effect on this ux pattern
      - bqmjjx0kac 3y ago
        Okay
    - kqr 3y ago
      Are they incandescent or LED? Until recently red and green were the only LEDs possible and some industries move slowly on such things.
  - 1-more 3y ago
    God are they ever nice saws too. Good for you big dog.
- Sohcahtoa82 3y ago
  > computer people are slow to pick up this sort of stuff from other fields Because computer people aren't optimizing for functionality, intuitiveness, or really any sort of UX. They're optimizing for some idea of "beauty" and whatever is trendy.
  - mattmaroon 3y ago
    And you don’t die if your mute switch is in the wrong position at the wrong time.
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 ago
  Interesting 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.

2OEH8eoCRo0 3y ago

I like it. Why doesn't our "industry" look at aviation/military more often where miscommunication gets people killed.

ajmurmann 3y ago
I think the answer is that "looking pleasant" is much more of a goal for commercial software. In usability terms the much denser GUIs of the 90s were arguable better in some ways than what we frequently see today, especially for power users.
- kfarr 3y ago
  Yes just like the design of car infotainment systems -- looking good resulted in the touch screen era. Luckily we're finally realizing our mistake and a few automakers are putting old school knobs back in.
deleted 3y ago
[deleted]

kqr 3y ago

This is a good one, and also what airplanes do[1]. These problems are solved by people who care a lot about usability, but computer people are slow to pick up this sort of stuff from other fields. Labels outside the switch also work.[2] [1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header-1024x568.jpg https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header... [2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef7720454414e4.jpg https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...

pjot 3y ago
My table saw has this as well. A green and red light, both with off/steady/blink states that indicates information about the blade and safety system.
- bqmjjx0kac 3y ago
  Mine has this as well! I like the UX, but it's also kind of crazy that they didn't think about red/green colorblind users.
  - thr33 3y ago
    colorblindness would have no effect on this ux pattern
    - bqmjjx0kac 3y ago
      Okay
  - kqr 3y ago
    Are they incandescent or LED? Until recently red and green were the only LEDs possible and some industries move slowly on such things.
- 1-more 3y ago
  God are they ever nice saws too. Good for you big dog.
Sohcahtoa82 3y ago
> computer people are slow to pick up this sort of stuff from other fields Because computer people aren't optimizing for functionality, intuitiveness, or really any sort of UX. They're optimizing for some idea of "beauty" and whatever is trendy.
- mattmaroon 3y ago
  And you don’t die if your mute switch is in the wrong position at the wrong time.

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 ago
Interesting 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.