221–230 of 303 posts
The absolute worst example of this I have seen is the Tesla dashboard screen UI. It shows a car with labels on it, not buttons, that say "Open". That unambiguously means that the particular part is open. But that's not what it means. The labels are in fact buttons to open the parts, and you have no way of knowing.
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…
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.
A toggle button should show its current state. A checkbox is a good example. Muted [] vs Muted [x] It's pretty obvious. What gets tricky is when designers create UI that does not have as clear a connection between the word used and the visual design, such as: Mute Off [---( )] Mute On [( )---] I have no idea what either of these mean because they include the action in the description of the state.
A check is a tick[1]. On a status page[2] a tick means "working" and a cross means failed. The "pretty obvious" view is that "Muted [x]" has failed in some way. To know any different comes from learning computer UX, the opposite of obvious. (Or is it "X marks the spot", that's the target I should click if I desire "muted"?).
[1] Unicode U+2714 https://www.compart.com/en/unicode/U+2714
[2] e.g. https://www.githubstatus.com/
The absolute worst example of this I have seen is the Tesla dashboard screen UI. It shows a car with labels on it, not buttons, that say "Open". That unambiguously means that the particular part is open. But that's not what it means. The labels are in fact buttons to open the parts, and you have no way of knowing.
Is this peculiar to English? For instance, in Spanish, the verb and the adjective would be different words.
In English you can also form an adjective from the past participle ("this door is opened"). Using "opened" resolves the ambiguity in one direction only: when you want the adjective. But when you want the verb you'd have to add context: perhaps "tap to open".
Any Tesla owner can relate to this, given the wide variety (read: no consistency, no standards) of toggle buttons the car's UI utilizes. For one, the HVAC. One button, showing temperature, which upon touched the system will react differently to depending on how you touch it and for how long. Touch it briefly, you get a little popup. Touch it slightly longer, and (hopefully, not guaranteed though) you get a bigger pan…
- A closed padlock means the doors are locked. Tapping it unlocks the doors.
- The word "Open" on the trunk means the trunk is closed. Tapping it opens the trunk.
Any Tesla owner can relate to this, given the wide variety (read: no consistency, no standards) of toggle buttons the car's UI utilizes. For one, the HVAC. One button, showing temperature, which upon touched the system will react differently to depending on how you touch it and for how long. Touch it briefly, you get a little popup. Touch it slightly longer, and (hopefully, not guaranteed though) you get a bigger pan…
Tesla's mobile app features inconsistent toggles right next to each other! - A closed padlock means the doors are locked. Tapping it unlocks the doors. - The word "Open" on the trunk means the trunk is closed. Tapping it opens the trunk.
Earlier quoted context omitted.
There's a pretty interesting (to me) aspect of the mic indicator/controller problem: without direct visual feedback, you can't tell what mode your mic is in until _other people_ respond, or don't. It's a very laggy tool in terms of feedback even when it's "on". In fact, you often need to test it two or three times to be sure, because your fellow meeting members might have frozen, might just be thinking before they re…
I think the solution to this problem would be to have a indicator on your profile that say is green when you can talk, but red or gone when you can't.
Earlier quoted context omitted.
One thing absolutely bizarre with Teams is that if you copy and paste the contents of a message most of the time it will paste the contents as plain text with a weird timestamped wrapper including the senders name. That makes passing a filepath or any text super annoying through Teams, most of all because it's a seemingly random behaviour --- sometimes it does it and sometimes it doesn't.
Ah I know of this one and yes it's very annoying. But I can explain the behavior for you, though it won't be any less random-seeming in my experience. Depending on where you stop your selection with the cursor, Teams will think you either only have text selected, or you've selected the message itself. The latter is what adds the message data to your clipboard, and the border between text and message selection is impo…