This has been really frustrating to me lately with Microsoft Teams. If I'm in their app, the mute button is a microphone with a line through it (if mute is activated, i.e. if the mic is off). And the icon changes to a microphone without the slash over it to indicate that you are no longer muted. Makes sense.
But if I join using the phone app on my phone, the same microphone with a line through it (that means you are muted on Teams) indicates that you are currently NOT muted, but you can use that button to activate mute. After pressing it, the icon is still a mic with the line, but it changes to a filled in background (reverse video).
Is this because in one case, that button is a "mic on" button, but in the other it is a "mute on" button, using the same icon? And the button still does an OK job of indicating what state you are currently in, as long as you know what the button looks like in the opposite state (I always have to toggle the mute button a couple times to observe what paradigm the given app is using).
I wonder if this is the price we pay for "flat UI", where designers are still figuring out design elements without a real-world reference to look back on.
I think part of this confusion stems from the "default mic on" mindset, where "mic active" is assumed to be the default, and mute is a deviation from that state. We can trace this pattern back to the UI of phone conference systems, back through analog phones, back to the time of a literal wire connection between parties.
Many/most audio mixers (in the context of live music and recording) and their digital brethren use the same pattern - a "Mute" button which lights red to indicate that channel is silenced. But a few have an ON button above the fader which lights to indicate the channel is active.
I think it's about time conference applications rip off the bandage and take the "audio off by default" approach. We can kinda see it already with UI elements that light up when a speaker is talking.
I have a similar frustration with UI differences between apps with Plex. If I look at a TV show season on my phone, episodes I've watched have a blue check mark. When I look at the same season on my TV, there's no blue check but episodes I haven't watched have a yellow triangle. It always makes my brain double take when moving between them.
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 respond, etc
It's quite different from, say, dark mode, which is pretty obvious when toggled on/off.
So the feature benefits a lot from a visual indicator of current state regardless what you choose to do for the button. It's unsurprising people try to smudge the "state" and "control" together, for the mic more than many other controls.
When I was just starting in IT (~1999) it was already a joke that you could identify where different MSFT teams wrote elements of software (say, Outlook) when a common action was implemented two different ways (explained by Conway's Law as I know now).
I don't mean to just blanket shit on Teams, but Teams is just a confusing mess of UI choices and UX design that makes no sense even within the context of using Teams. The meeting icons are of course pretty awful as you cited, but it's even more things for me [0]:
- When joining a Teams call, the toggle for video gets "selected" so that pressing Return or spacebar (I think one or both) will toggle the video on -- noticing that you did this or that the video toggle is selected is a matter of chance as it's hard to see
- For some bizarre reason Teams has a "start call" shortcut that just immediately starts a call without the usual pre-call warning items. Joining a meeting from your calendar gives you a "pre-meeting room" where you can confirm your mic/video settings before joining, but hitting the call shortcut or button immediately starts a call
- Sometimes right-click menu loads slowly and additional options load after you right-click and move the mouse -- it so happens this will usually put the cursor on Pinning the message instead of selecting reply or edit
- Regarding Reply/Edit, there is a nice button to jump right to both, but for chats one button is showed, for private messages another is shown
- All teams messages are linkable; whether or not you right-clicked on a link in the message and are copying the link or if you're getting a link to the message itself depends on if you happen to notice whether you have 2 options on right-click or 3+ options
- Copying a linked item (e.g., document, media, picture) will have Download or Copy Link button. Copy link for some reason puts up a text box across the conversation you're having that is dismissible with escape or clicking usual x in box corner -- other "copy link" options just copy the link normally, other ones (like copying channel link) will open a window with the link for you to copy
- it is huge pain for me personally that the links you copy from Teams are Sharepoint links and pasting it in a browser tries to open files in Sharepoint browser, even if Sharepoint absolutely cannot display a preview of the file: you sit while Sharepoint tries to load a preview, and only after a few seconds of Sharepoint trying does it show you a download button to get the file (thankfully there are browser extensions like Redirector [1] which can be used to create redirects for auto-downloads...just Microsoft likes to change the URL for actual downloads relatively often so occasionally you need to update your redirects..)
Teams is so inconsistent and the UI and UX are equally inconsistent -- Teams is also not shy about showing tutorial prompts for features just whenever it wants to, no matter how long you've been using Teams, sometimes it will just block the entire app to highlight some feature it wants to advertise. I honestly don't think this or anything has to do with flat UI versus other ones, it's just plain lack of attention. maybe flat ui's give the impression of a "completed" thing, but I just can't see that most of the UI/UX issues for apps like Teams are about the aesthetic so much as just a complete lack of concern over what actually using the app is like.
0 - All points here were observed on vanilla teams installations on different computers -- maybe my work just has weird defaults, but I'm not confident that is the case
I use teams all the time but only use the mobile app for audio since that's less crap than the desktop electron/etc. based apps
I recommend everyone to just the mobile app for audio since most people can't manage to get pc/windows audio working consistently and it's just works on most people's phones without issue
while I can certainly get it working fine on my pc, I have a nice bluetooth headset that is a pain to repair to my pc so I always just use the headset so I can walk anywhere and not be tethered to my pc (where bluetooth always seems unreliable in windows...)
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 panel with full HVAC controls. Touch and hold for a couple seconds, and (hopefully, not guaranteed though) you turn off the HVAC if it's on. ALL WHILE YOU ARE DRIVING AND SUPPOSED TO WATCH THE ROAD. And if your hand/eye coordination is slightly off (and hey, when you're driving, going over bumps, etc, it very likely is) if you mis-aim by even a millimeter, you may touch another button and not realize it and do something unintended.
Another disaster: Tesla's entire connect-a-Bluetooth-device UX is one of the worst mishmashes of disastrous UI design I have ever seen in a shipping product, at least the 2012-2022 Model S implementation. Just one example, a button label down at the bottom right that still says "Connect" long after the device is already connected, but meanwhile elsewhere on the opposite side of screen, up top at the left, that says "Connecting..." then indicates the connection is made. All this in a UI that you only have a split second to glance at because it's in a CAR and you very well might be DRIVING. The Tesla Bluetooth UI could fill an entire chapter of a book on UI, it is so magnificently bad. Maybe I should write it.
you should write it, i always find these kinds of writeups fascinating, and tesla (therefore elon) being the subject would only make for more general interest
Actually Bluetooth works well in my 2023 Model Y, and I am very pleased because it did not in my old Audi and Ford. There has to be something seriously messed up with the Bluetooth spec if implementations are always so bad.
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.
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.
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.
This is extra silly because you can make what's effectively a checkbox look really nice and toggle-y. Although this is a bad example it shows that it doesn't have to be a square with a check mark in it: https://www.ranecommercial.com/legacy/hal/MobileHelp/Advance...
A medical video conference / telehealth system my provider uses has broken the checkbox. In their direct message interface they change the checkbox field label based on whether the box is checked. Unchecked has the label as "Not Urgent" and checked is "Urgent". On multiple occasions I have quickly checked the box, to indicated as not urgent, then clicked send.
I agree that checkboxes are perfect; but that's because I never try to fill forms on a smartphone. Native browser checkboxes are often unusable on smartphones; too small to hit with a thumb.
Is Jony Ive the Thomas Midgley Jr of the design world? Jony is responsible for iOS 7 which popularized low-usability flat design, as well as the circular iMac mouse and the Macbook's fragile keyboards.
Yes obviously, because checkboxes need accompanying text, otherwise it’s just a mystery fidget. Text on a small screen is a problem for obvious reasons.
The you have the second problem: checkboxes were part of web forms, where you have a submit button. So a whole generation of users were taught the abstraction of “saving” your settings as an explicit gotcha step. The checkbox didn’t do anything on its own.
Very likely, Apple wanted to start over with an element that was independent and immediate, in their preference panes. But checkboxes would have worked too, in preferences – but does not solve the in-app problem:
The icon toggle buttons are not mobile designers faults – they existed way earlier, primarily known from text editors (think the bold/italics toggles). Who messed them up so badly, I don’t know..
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.
Yes, 100%! This is my second most frustrating UX gripe with the Tesla trunk UX - the first being the super long animation you have to wait through in order to open the trunk after putting the car in park. Overall tesla UX is miles ahead of other cars, but the little things like this are so frustrating!
Huh, I don't think it's confusing at all, the rendered car clearly shows the current state of the trunk, and when you push the open button, there's even an animation showing the trunk opening.
Interesting. This is a problem with the english language, where verbs and adjectives are often the same. It would not happen in Spanish, where "Abrir" (Infinitive) is different than "Abierto" (adjective).
I guess this could be avoided by using "Do open" or "Is open". Would this sound off to a native speaker?
The main issue with toggle buttons is that you have an object that at the same contain the state of the system and the action to change it.
The consequence is that it is not clear if the "ON" that you see on it is the current state (so pressing on it will turn it to "OFF"), or the action that you will invoke when you press it.
The solution is to separate (part of) state and action, and this can be done in a few ways. One possibility is to do like one of the answers in the link suggests, and write the label _outside_ the button. If you don't have a switch but a toggle button (like the teams example in some other comment), leave the icon alone, and change some other properties of the button (for example leaving it pressed to signal the "ON" state, like it has been done for decades without any issue....)
System sound properties in Windows 11 has an option "Allow apps and Windows to use this device for audio" and a button labeled "Don't allow" next to it. So what is the current state? I have no idea.
I agree with the conclusion, but would like to add that it should be obvious what the current state is, and what the state will change to when the toggle is changed; too often I have to change it in order to work out that I didn't need to change it.
The point about play/pause is really interesting because it goes against the conclusion. However, it's following physical precedent that's well understood. It's also (usually) obvious when music or a movie is playing, so the button icon wouldn't even need to change for the user to understand what pressing it will do. This stands it separately to the toggle question, I think.
Back to toggles and UIs, changing the colour of the toggle from light grey to slightly lighter grey is unhelpful in the extreme. Give me labels. If labels don't fit your motif then get better designers.
> However, it's following physical precedent that's well understood
The physical precedent would be to show the behaviour as the button image (play) and then the depressed/undepressed visual state would show if the behaviour was active or not. Software designers didn't follow this and invented swapping between the play/pause icons causing this new confusion. Not for any user friendly reason, more because skeuomorphic 3d buttons went out of fashion.
> It's also (usually) obvious
The only virtue of indicating the state at all is for when you have a problem. Very common for audio at least (muted sound, unplugged headphones, linux audio drivers have become borked again... sigh).
I still get that twang of cognitive dissonance when I see play/pause buttons and have to think about it and might just double toggle it anyway when I've got an issue because I can't be 100% sure what a pause button means.
> Give me labels. If labels don't fit your motif then get better designers.
That's unhelpful and unreasonable, particularly on mobile.
There's no room on Spotify for labels behind every button, for instance.
Not if you want room to show the cover art, which I do.
It's not a question about "better designers" -- space constraints are real, and sometimes you really need things available at a single tap. I don't want shuffle to be buried behind a pop-up menu.
> "A checkbox is a good example. It's pretty obvious."
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"?).
I want a button to tell me what it does if I click it. If you want to show the current status that is a different thing, not a button. A button exists to be clicked, it should communicate what it will do if you click it.
Should show both, just as analog switches do. You want it to clearly unmistakably show the current state, but also the state to which it will change.
Apple has really nailed that with its sideways slider toggles. You can clearly see where the toggle is currently, what it will change to, and whether the current setting has made some feature active (blue background inside the slider) or inactive (grey background inside the slider).
I can’t find it but one of my favourite designs was a switch with a “light” beside it that lit up when the state was “on.”
The best thing was that it also solved the latency of an async operation. You’d click the switch which toggled, and then some moment later the light came on. It felt incredibly satisfying and gave confidence that yes, this interaction has done something.
Without seeing the design in question, I think this still demonstrates the ambiguity the post is discussing. Is the icon what will happen, or what is currently happening? Is it the state, or is it the action? Maybe this particular design was unambiguous, but the description of it isn't.
> I can’t find it but one of my favourite designs was a switch with a “light” beside it that lit up when the state was “on.”
So when I revisit that page after a long time and see that the light is lit, does it mean that the state is currently ON or does it mean that the state will change to ON when I click it? How can I tell this by instantly looking at the lit light?
That sounds like an interface feature found on "smart" devices - I'm only familiar with TP-Link Kasa switches, but I think I remember their app UI having a similar feature where a color icon had multiple states, the most "on" of which is "confirmed with the switch it turned on".
That would be a great use for an HDR screen - make the "indicator light" extra bright compared to the rest of the screen, to make it really obvious that the light is now "on". Of course this would only work as long as the user doesn't keep their screen too bright to begin with...
I do keep doing it myself but combining multiple things into one button is a bad idea. What if the toggle action is just slightly delayed? What if the system is frozen, do you press toggle again? when do you know your click didn't register? Was freezing not annoying enough by it self?
What does a greyish padlock icon indicate? Let me tap it twice to cycle through states, then I’ll click once more if the original state needed to be toggled. If there’s any delay in the car’s response, prepare to complete another lock/unlock cycle, more slowly this time to be certain.
It’s also inconsistent. From what I remember, the padlock toggle shows the current state (an unlatched padlock means the doors are unlocked, and pressing it will lock the doors), but the trunk button shows the opposite (an open trunk means the trunk is closed, and pressing it will open the trunk).
I'm surprised we are still iterating on ideas like this, to be honest. Seems flight decks have been rather successful on complicated dashboards for a long time. Same with boats. Why can we take approximately no lessons from them?
The interfaces you are talking about require years of training, study and passing multiple tests to demonstrate proficiency. In software UX we are talking about discoverability and approachability for the untrained operator.
I mean, we do have solutions to this problem. You use them every day. The problem is that, unlike air travel or the military, nobody can say "everybody must do it this way". So, a lot of people do it their own way.
It is forgivable if the wrong choice is not so harmful (e.g. play/pause a video) and the effect is reversible. There's an e-commerce website I use that has an option to post product reviews as anonymous with a "slide toggle" typical of mobile devices. The only feedback is after the review gets posted which cannot be undone. I just learned by experience, but it is always confusing to interpret.
Tesla makes this mistake with their ambiguous "lock" button on the iOS app. The button toggles between an open/closed padlock icon. I often lock the doors remotely and since I can't physically see the car to confirm, I get paranoid about whether the icon is representing state or action.
The designers of everyday things also fall into this trap. My favorite example is the hammer drill, this kind should had the mode switch. I have a very decent device but implementing the same problem on/off approach showing and hiding the state. I almost always pause before choosing the right one. The example of the better design (mention in the stackexchange answers) is visible at the hammer drill polish wiki page: https://pl.wikipedia.org/wiki/Wiertarka_udarowa
For an unmute button, you could have a microphone with a line through it, and an arrowhead indicating that clicking the button will remove the line. Then the mute button could show a microphone with an arrowhead pointing inward from the corner, indicating that a line will be drawn.
One of the worst cases of this is the 'Airplane mode' toggle on a Kindle. Airplane mode turns off wifi but the icon is an airplane that says 'On' when airplane mode is on. When you click it, it turns to 'Off'. But what you really want to do is turn the wifi off and on, which is the opposite of the icon. 'On' means the wifi is off, 'Off' means the wifi is on. Terrible.
Airplane mode status and Wi-Fi status are separate statuses. Airplane mode can be on and it tells you nothing one way or the other about the actual state of Wi-Fi. This ultimately comes down to some Kindles being like phones and having more than 1 radio where you may want airplane mode on except for the Wi-Fi radio if you plan on using in flight Wi-Fi.
Airplane mode is a convenience to conserve battery during a flight. If you judge it by how well it acts as a universal radios on/off switch it will measure accordingly.
(If checkboxes are unavailable in your design system, you should have an unambiguous label next to it saying "On" or "Off", or better, describing the current state of the system in the terminology of the system, like "Background Noise Cancellation Enabled". But having a control label and a status label _should_ be a clue that you should just be using a checkbox.)
Not directly related but Bitbucket cloud has made some recent update where they started prioritizing reviewers over submitters in pull requests. One change is that you by default get the “I’m reviewing” filter turned on by default. Which I have to turn off most of the time. Anyway, sometimes I try to turn it off but then it is toggled (it was off). What’s going on? Well, the normal interface is that it’s a combobox where no-text means no filter—that’s where the I’m Reviewing by-default resides. But on a slightly different pull request view—which looks almost the same—the UI element is the same kind of thing... except here the combobox gets a black background when toggled! And the default is to show some option like I’m Reviewing but on a white background, which means not-toggled…
This has been one of my biggest eternal dilemmas in UI/UX/programming!
• The ideal would be to show both states: "Muted → Unmute" on the button label. Click it and it becomes "Unmuted → Mute". If there isn't enough space, maybe just add a " → " at the end to denote that the displayed state will change to something else when you click on it.
• Or just make it look like a physical electric switch with "On" & "Off" printed on opposite sides.
• or a hover effect: "Muted" or [Crossed Microphone Icon] becomes "Unmute" / [Microphone Icon] when you hover the mouse or hold the finger on it. The icon should also change color between red/green or dim/lit to further emphasize the actual state.
I once worked on an Optical Image Stabilisation system for mobile phones. I'd updated the stock Android camera app to show some icons from marketing for when the shake compensation was on / off.
The icon for when compensation was on was a shaky camera. When it was off, it was a shaky camera with a line through it...
Except, we asked, wouldn't the other way round make more sense? Doesn't line through shaky camera suggest we're removing the shake?
We ended up using the icons and just colouring them green for "on" and red for "off" and hoping people would figure out what we meant. And, yes, that would still be unhelpful for colour blind users!
This is why this kind of thing should have text (with or without an icon). Just tell me what you're trying to communicate. Yeah I know you have to translate it for other languages, but Microsoft, Samsung, et cetera should be able to afford that.
I am not a designer, but I've always heard that the difference between checkboxes and toggles is that toggles are expected to immediately produce side effects whereas checkboxes aren't.
That is to say, clicking on a checkbox shouldn't immediately mutate some state, whereas activating a toggle should.
The dribblization of UI lead to a bunch of people trying to make things pretty for their own benefit. Then they look at it in Figma and it looks absolutely stunning. Never mind that actually needs to be understood and used by someone, that’s irrelevant.
Just today I saw a HSL color slider on Twitter that was a single hue slider with two half-arc sliders on the main slider’s handle: one above for saturation, one below for lightness. It sounds like a joke but…
I don't know how developers manage to make simple toggle switches confusing and it makes me scared of their code but sometimes I think it's done on purpose as a dark pattern (when you unsubscribe to spam for example)
There are a number of ways to get this wrong. The shuffle button in Spotify on our Tesla is a grey color, and you have to wonder if it's dark ENOUGH a grey to indicate that it's on, or a light grey to indicate that it's off. So then you go to toggle it on and off to see the state change, but actually it's buggy so it doesn't do anything.
When you finally get it to toggle on, you realize the shuffle lines turn GREEN, not dark grey like most of the controls. facepalm
Also, the problem with buttons like this is that the shade of grey depends on the angle you're looking at the screen, so you end up moving your head around trying to figure out if it is actually on or off.
Worse yet, Spotify abruptly added a third option, Smart Shuffle, to their shuffle sometime in the past year or so. So now you gotta hit the button twice to go from shuffle to no shuffle, and once to go no shuffle to shuffle. This is for their mobile and desktop apps I mean. They gotta have some of the worst UX of newer consumer tech companies.
Another issue with toggles is idempotency. If I click the button, there is always some lag and some chance that the underlying system state has not changed. I might want to click the button again to reinforce my desired change, but with a toggle there's not really a way to do that. If I click it again, the system would likely revert back to it's original undesired state.
Like when you want to copy something, but Ctrl-C is unreliable, so you Ctrl-C,C,C,C to make extra sure.
I want one button for each state, so that I can click it several times if required.
In defense of the ambiguity of digital toggles, I’d like to add that this is unsolved on most, if not all, physical light switches in homes and offices.
Despite having existed for more than 50 years and most people are using multiple toggles a day with its labels, most people are unaware of the meaning of power symbol (https://en.m.wikipedia.org/wiki/Power_symbol)
Isn't that a feature and not a bug for light switches?
It's not uncommon to have multiple light switches control a single light socket - switching any of them changes the state of the light, therefore you cannot consistently say state-x = light on, state-y = light-off.
Because language works through association and analogy, you don't actually need to know the etymology of a word or symbol to use or understand it.
Any English speaker can understand perfectly well the words manual, manufacture and manicure without ever reflecting on the fact that "manus" in latin means "hand".
We clearly haven't needed to rename these words "handual", "handufacture" and "handicure" for these concepts to be understood by people who aren't fluent in Latin.
In much the same way, even a person who has never seen a floppy disk will associate its likeness with the action of saving if it appears next to enough save buttons.
While the NEC does not specify light switch toggle orientation, there seems to be a general convention among electricians and installers for the toggle switch to be positioned up for "on" and down for "off."
> In defense of the ambiguity of digital toggles, I’d like to add that this is unsolved on most, if not all, physical light switches in homes and offices.
What? This has been solved for physical light switches since before physical light switches existed.
If the light is on, the switch is set to "light on". If the light is off, the switch is set to "light off".
It should always show its current state. If a button is doubling as a status display, it needs to display current status, that's the entire point of a button doubling as displaying information.
Would you flip a breaker to the "ON" position in order to turn it off, or would you expect the breaker to display its current state of being ON/OFF?
False dichotomy. Toggle buttons should show both and visually indicate the state by proximity cue.
But there is usability vs aesthetics trade off.
I think Microsoft design systems (seen in Windows, Edge, Office products) only shows the active state probably because it’s easier to align toggle buttons flush when text is only on one side. If you display texts on both sides, the unpredictable text length would make the button area difficult to align.
The only two good suggestions I saw were radio buttons as well as toggles with labels on the left & right (so basically two merged radio buttons).
I think the play/pause button in media apps is an acceptable exception simply because it's obvious whether it's playing or not - you could even use it without recognizing the symbol, if music is playing you know a click will pause it.
It also works if the button is not labeled, as long as the state is clearly visible in the environment and the link is clear.
Consider the light switch - if there’s just one, it’s the best UI ever. You know what to do to turn the lights off, just flip the closest switch. Obviously if there’s more than one then it’s the worst UI ever.
Another example, a smartphone’s side button (screen on/off).
For an interface with hover interaction, a toggle button should show its current state by default and then on hover show the state it will switch to. This design pattern affords discoverability through safe interaction with the element.
Unfortunately that design pattern fails for touch interfaces, which increasingly are our primary method of interaction.
We should use the world's national emergency alert systems to conduct a poll of as large a percentage of the world population as possible, and whichever option wins the poll, we should go with that one.
Of course, no one will agree about which state is which,...
The top answer references About Face 2.0 which I read at the time and it's still probably the best book on user experience design. I think there's newer editions, but the principles it laid out were really the fundaments that I still live by.
This wasn’t an issue when buttons were 3D. They had an icon (or text) indicating what they activate, and were rendered depressed when active and raised when inactive. Some color could optionally be added to the icon to reinforce the active state.
There should be no ambiguity here! A toggle button is an analogue for a physical switch. Unless the switch state is dependent on other switches, it must always display its current state. i.e. ENABLED is always true unless POWER is OFF.
There is ambiguity in the physical world. Some audio equipment have what's called a ground lift. It physically disconnects the ground conductor between two devices, and it's usually a single push-toggle in/out button. I've seen some devices with "Ground On/Off" - does that mean grounded (not lifted) or not grounded (lifted)? IIRC one of the DI boxes I've used is the opposite of what you'd expect - "Off" means lift is off, meaning ground loop is connected. The sensible devices have two states "Lift/Gnd".
I usually make a toggle button reflects its current state and shows the next state in some other way, like in the hover over tooltip or small subscript text. That means a toggle updates two things, the button itself and the tooltip.
It has answers as recent as 2022 though and it could get more answers now that it is on HN. What's the accepted practice for putting year in parentheses for links like this that contain user-written content that could be much more recent than when the link was created?
Using words often works. But let me chime in with some outrage about the icons on an Android tablet - a triangle, circle and square with no discoverability and no ability to add text to icons on the home screen? WTF?
If you're using Samsung, they have an app called Good Lock that lets you change the icons to pretty much whatever you want. Mine are the same as the original Android icons: a curved back arrow, a little house, and two overlapped rectangles. Definitely agree the defaults are bad though.
This is a problem for forms where companies are legally required to follow the users instructions but may not want to. I find myself not trusting them to not pick deliberately unintuitive interpretations. Think the kind of designer that comes up with "check this box to receive transactional emails but not marketing emails", when an unchecked box leads to marketing and transactional emails.
I just want it to mimic the physical thing if it's going to mimic something at all.
A push button toggle stays clicked in, or better yet clicked in and illuminated, to indicate that it's on.
a traditional 2 way toggle exposes the state that its' in by the position of the knob relative to center.
I mean anyone can flip states around behind the scenes, but if we're talking about a switch/wires/battery/light it all works out as supposed. Let's follow that example.
There doesn't need to be an either/or if you give the toggle twice the space, just like a physical toggle. With the added space, you can show the states are related, which state is currently selected, and which alternate state will become current after the change. The real problem seems to be nobody cares about actual ui-design for human use but something that'll look good when you show the boss.
Google's Youtube TV. The UI infuriates me. To this day I can't remember which state the toggle is in. I do know it's the opposite to every other app on my Apple TV.
derekp7|2 years ago
But if I join using the phone app on my phone, the same microphone with a line through it (that means you are muted on Teams) indicates that you are currently NOT muted, but you can use that button to activate mute. After pressing it, the icon is still a mic with the line, but it changes to a filled in background (reverse video).
Is this because in one case, that button is a "mic on" button, but in the other it is a "mute on" button, using the same icon? And the button still does an OK job of indicating what state you are currently in, as long as you know what the button looks like in the opposite state (I always have to toggle the mute button a couple times to observe what paradigm the given app is using).
I wonder if this is the price we pay for "flat UI", where designers are still figuring out design elements without a real-world reference to look back on.
kortex|2 years ago
Many/most audio mixers (in the context of live music and recording) and their digital brethren use the same pattern - a "Mute" button which lights red to indicate that channel is silenced. But a few have an ON button above the fader which lights to indicate the channel is active.
I think it's about time conference applications rip off the bandage and take the "audio off by default" approach. We can kinda see it already with UI elements that light up when a speaker is talking.
Kuraj|2 years ago
mvdtnz|2 years ago
pavel_lishin|2 years ago
the_other|2 years ago
It's quite different from, say, dark mode, which is pretty obvious when toggled on/off.
So the feature benefits a lot from a visual indicator of current state regardless what you choose to do for the button. It's unsurprising people try to smudge the "state" and "control" together, for the mic more than many other controls.
AceyMan|2 years ago
zamadatix|2 years ago
Desktop: slashed = currently muted, plain = currently listening
Phone: slashed = currently muted, plain = currently listening.
I'm using the latest version of Teams for Windows and iPhone respectively.
gedy|2 years ago
csydas|2 years ago
- When joining a Teams call, the toggle for video gets "selected" so that pressing Return or spacebar (I think one or both) will toggle the video on -- noticing that you did this or that the video toggle is selected is a matter of chance as it's hard to see
- For some bizarre reason Teams has a "start call" shortcut that just immediately starts a call without the usual pre-call warning items. Joining a meeting from your calendar gives you a "pre-meeting room" where you can confirm your mic/video settings before joining, but hitting the call shortcut or button immediately starts a call
- Sometimes right-click menu loads slowly and additional options load after you right-click and move the mouse -- it so happens this will usually put the cursor on Pinning the message instead of selecting reply or edit
- Regarding Reply/Edit, there is a nice button to jump right to both, but for chats one button is showed, for private messages another is shown
- All teams messages are linkable; whether or not you right-clicked on a link in the message and are copying the link or if you're getting a link to the message itself depends on if you happen to notice whether you have 2 options on right-click or 3+ options
- Copying a linked item (e.g., document, media, picture) will have Download or Copy Link button. Copy link for some reason puts up a text box across the conversation you're having that is dismissible with escape or clicking usual x in box corner -- other "copy link" options just copy the link normally, other ones (like copying channel link) will open a window with the link for you to copy
- it is huge pain for me personally that the links you copy from Teams are Sharepoint links and pasting it in a browser tries to open files in Sharepoint browser, even if Sharepoint absolutely cannot display a preview of the file: you sit while Sharepoint tries to load a preview, and only after a few seconds of Sharepoint trying does it show you a download button to get the file (thankfully there are browser extensions like Redirector [1] which can be used to create redirects for auto-downloads...just Microsoft likes to change the URL for actual downloads relatively often so occasionally you need to update your redirects..)
Teams is so inconsistent and the UI and UX are equally inconsistent -- Teams is also not shy about showing tutorial prompts for features just whenever it wants to, no matter how long you've been using Teams, sometimes it will just block the entire app to highlight some feature it wants to advertise. I honestly don't think this or anything has to do with flat UI versus other ones, it's just plain lack of attention. maybe flat ui's give the impression of a "completed" thing, but I just can't see that most of the UI/UX issues for apps like Teams are about the aesthetic so much as just a complete lack of concern over what actually using the app is like.
0 - All points here were observed on vanilla teams installations on different computers -- maybe my work just has weird defaults, but I'm not confident that is the case
1 - https://github.com/einaregilsson/Redirector
clolege|2 years ago
It's inherently negative, basically meaning "not enabled" and as such, `not muted` == `not not enabled`.
Just say whether their mic is on or off, and reflect that with the UX elements and writing. Done.
emeril|2 years ago
I recommend everyone to just the mobile app for audio since most people can't manage to get pc/windows audio working consistently and it's just works on most people's phones without issue
while I can certainly get it working fine on my pc, I have a nice bluetooth headset that is a pain to repair to my pc so I always just use the headset so I can walk anywhere and not be tethered to my pc (where bluetooth always seems unreliable in windows...)
ClassyJacket|2 years ago
spookie|2 years ago
empath-nirvana|2 years ago
brianstorms|2 years ago
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 panel with full HVAC controls. Touch and hold for a couple seconds, and (hopefully, not guaranteed though) you turn off the HVAC if it's on. ALL WHILE YOU ARE DRIVING AND SUPPOSED TO WATCH THE ROAD. And if your hand/eye coordination is slightly off (and hey, when you're driving, going over bumps, etc, it very likely is) if you mis-aim by even a millimeter, you may touch another button and not realize it and do something unintended.
Another disaster: Tesla's entire connect-a-Bluetooth-device UX is one of the worst mishmashes of disastrous UI design I have ever seen in a shipping product, at least the 2012-2022 Model S implementation. Just one example, a button label down at the bottom right that still says "Connect" long after the device is already connected, but meanwhile elsewhere on the opposite side of screen, up top at the left, that says "Connecting..." then indicates the connection is made. All this in a UI that you only have a split second to glance at because it's in a CAR and you very well might be DRIVING. The Tesla Bluetooth UI could fill an entire chapter of a book on UI, it is so magnificently bad. Maybe I should write it.
sgustard|2 years ago
- 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.
willsmith72|2 years ago
ranguna|2 years ago
1. Look at it
2. If it's slightly transparent and I want to turn it on, I click it (I don't hold for a second or 2 or 10, I just click it normally) and it turns on
3. Click it again to get the full controls
4. Slide down to close the full controls
5. Click the button again to open the full controls, and click the off button to turn it off.
Then I click and slide to the right or left to increase or decrease the temperature.
Seems pretty intuitive to me.
I'm gonna try clicking and holding next time I drive to turn it off, seems really useful.
esafak|2 years ago
sizzle|2 years ago
sponaugle|2 years ago
kqr|2 years ago
Labels outside the switch also work.[2]
[1]: https://my737ng.com/wp-content/uploads/2014/08/cp_mcp_header...
[2]: https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
pavon|2 years ago
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.
2OEH8eoCRo0|2 years ago
bee_rider|2 years ago
kqr|2 years ago
83457|2 years ago
denton-scratch|2 years ago
pera|2 years ago
xnx|2 years ago
klabb3|2 years ago
The you have the second problem: checkboxes were part of web forms, where you have a submit button. So a whole generation of users were taught the abstraction of “saving” your settings as an explicit gotcha step. The checkbox didn’t do anything on its own.
Very likely, Apple wanted to start over with an element that was independent and immediate, in their preference panes. But checkboxes would have worked too, in preferences – but does not solve the in-app problem:
The icon toggle buttons are not mobile designers faults – they existed way earlier, primarily known from text editors (think the bold/italics toggles). Who messed them up so badly, I don’t know..
_0ffh|2 years ago
rjmunro|2 years ago
dhc02|2 years ago
ZitchDog|2 years ago
amarant|2 years ago
To each their own I guess
arximboldi|2 years ago
I guess this could be avoided by using "Do open" or "Is open". Would this sound off to a native speaker?
ljsprague|2 years ago
ClassyJacket|2 years ago
All it needs is "Closed - tap to open"
actionfromafar|2 years ago
List of features I want:
- automatic transmission (if ICE)
- bluetooth and FM radio
- no self steering
- cruise control with "follow speed"
- not-batshit-insane self-brake-system (use whatever Volvo uses, it works!)
- good airbags and decent structural integrity
- classic sedan height
mrighele|2 years ago
The consequence is that it is not clear if the "ON" that you see on it is the current state (so pressing on it will turn it to "OFF"), or the action that you will invoke when you press it.
The solution is to separate (part of) state and action, and this can be done in a few ways. One possibility is to do like one of the answers in the link suggests, and write the label _outside_ the button. If you don't have a switch but a toggle button (like the teams example in some other comment), leave the icon alone, and change some other properties of the button (for example leaving it pressed to signal the "ON" state, like it has been done for decades without any issue....)
vleaflet|2 years ago
BLKNSLVR|2 years ago
The point about play/pause is really interesting because it goes against the conclusion. However, it's following physical precedent that's well understood. It's also (usually) obvious when music or a movie is playing, so the button icon wouldn't even need to change for the user to understand what pressing it will do. This stands it separately to the toggle question, I think.
Back to toggles and UIs, changing the colour of the toggle from light grey to slightly lighter grey is unhelpful in the extreme. Give me labels. If labels don't fit your motif then get better designers.
Fluorescence|2 years ago
The physical precedent would be to show the behaviour as the button image (play) and then the depressed/undepressed visual state would show if the behaviour was active or not. Software designers didn't follow this and invented swapping between the play/pause icons causing this new confusion. Not for any user friendly reason, more because skeuomorphic 3d buttons went out of fashion.
> It's also (usually) obvious
The only virtue of indicating the state at all is for when you have a problem. Very common for audio at least (muted sound, unplugged headphones, linux audio drivers have become borked again... sigh).
I still get that twang of cognitive dissonance when I see play/pause buttons and have to think about it and might just double toggle it anyway when I've got an issue because I can't be 100% sure what a pause button means.
chatmasta|2 years ago
Yeah, I don't need to know which direction of my light switch means "on" (and in fact I don't know), because I can see whether the lights are on.
crazygringo|2 years ago
That's unhelpful and unreasonable, particularly on mobile.
There's no room on Spotify for labels behind every button, for instance.
Not if you want room to show the cover art, which I do.
It's not a question about "better designers" -- space constraints are real, and sometimes you really need things available at a single tap. I don't want shuffle to be buried behind a pop-up menu.
resters|2 years ago
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.
krab|2 years ago
Loudspeaker [()---] Crossed-out loudspeaker
jodrellblank|2 years ago
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/
croes|2 years ago
A toggle button is confusing because I don't know the designers intention unless the button shows both options beside it
Mute On[---()]Off
sfn42|2 years ago
I want a button to tell me what it does if I click it. If you want to show the current status that is a different thing, not a button. A button exists to be clicked, it should communicate what it will do if you click it.
deepsun|2 years ago
unknown|2 years ago
[deleted]
SkyMarshal|2 years ago
Apple has really nailed that with its sideways slider toggles. You can clearly see where the toggle is currently, what it will change to, and whether the current setting has made some feature active (blue background inside the slider) or inactive (grey background inside the slider).
Waterluvian|2 years ago
The best thing was that it also solved the latency of an async operation. You’d click the switch which toggled, and then some moment later the light came on. It felt incredibly satisfying and gave confidence that yes, this interaction has done something.
vsnf|2 years ago
mapreduce|2 years ago
So when I revisit that page after a long time and see that the light is lit, does it mean that the state is currently ON or does it mean that the state will change to ON when I click it? How can I tell this by instantly looking at the lit light?
maicro|2 years ago
unnah|2 years ago
6510|2 years ago
InCityDreams|2 years ago
knallfrosch|2 years ago
Mobile users might be confused about whether Auto-Rotate is on, but they do know whether Airplane mode is on.
maicro|2 years ago
thinkmassive|2 years ago
What does a greyish padlock icon indicate? Let me tap it twice to cycle through states, then I’ll click once more if the original state needed to be toggled. If there’s any delay in the car’s response, prepare to complete another lock/unlock cycle, more slowly this time to be certain.
tshaddox|2 years ago
taeric|2 years ago
ZitchDog|2 years ago
sitzkrieg|2 years ago
spyke112|2 years ago
karaterobot|2 years ago
signaru|2 years ago
wforfang|2 years ago
Agraillo|2 years ago
sojournerc|2 years ago
p1mrx|2 years ago
For an unmute button, you could have a microphone with a line through it, and an arrowhead indicating that clicking the button will remove the line. Then the mute button could show a microphone with an arrowhead pointing inward from the corner, indicating that a line will be drawn.
MattGrommes|2 years ago
zamadatix|2 years ago
Airplane mode is a convenience to conserve battery during a flight. If you judge it by how well it acts as a universal radios on/off switch it will measure accordingly.
DanHulton|2 years ago
(If checkboxes are unavailable in your design system, you should have an unambiguous label next to it saying "On" or "Off", or better, describing the current state of the system in the terminology of the system, like "Background Noise Cancellation Enabled". But having a control label and a status label _should_ be a clue that you should just be using a checkbox.)
lxe|2 years ago
avgcorrection|2 years ago
Razengan|2 years ago
• The ideal would be to show both states: "Muted → Unmute" on the button label. Click it and it becomes "Unmuted → Mute". If there isn't enough space, maybe just add a " → " at the end to denote that the displayed state will change to something else when you click on it.
• Or just make it look like a physical electric switch with "On" & "Off" printed on opposite sides.
• or a hover effect: "Muted" or [Crossed Microphone Icon] becomes "Unmute" / [Microphone Icon] when you hover the mouse or hold the finger on it. The icon should also change color between red/green or dim/lit to further emphasize the actual state.
mark_undoio|2 years ago
The icon for when compensation was on was a shaky camera. When it was off, it was a shaky camera with a line through it...
Except, we asked, wouldn't the other way round make more sense? Doesn't line through shaky camera suggest we're removing the shake?
We ended up using the icons and just colouring them green for "on" and red for "off" and hoping people would figure out what we meant. And, yes, that would still be unhelpful for colour blind users!
User interfaces are hard.
ClassyJacket|2 years ago
I hate that Windows 11 has regressed on this.
lopkeny12ko|2 years ago
tweakimp|2 years ago
koito17|2 years ago
That is to say, clicking on a checkbox shouldn't immediately mutate some state, whereas activating a toggle should.
datavirtue|2 years ago
bandergirl|2 years ago
The dribblization of UI lead to a bunch of people trying to make things pretty for their own benefit. Then they look at it in Figma and it looks absolutely stunning. Never mind that actually needs to be understood and used by someone, that’s irrelevant.
Just today I saw a HSL color slider on Twitter that was a single hue slider with two half-arc sliders on the main slider’s handle: one above for saturation, one below for lightness. It sounds like a joke but…
https://twitter.com/jh3yy/status/1756429165803246028
apapapa|2 years ago
datavirtue|2 years ago
rconti|2 years ago
When you finally get it to toggle on, you realize the shuffle lines turn GREEN, not dark grey like most of the controls. facepalm
qingcharles|2 years ago
lamp_book|2 years ago
1letterunixname|2 years ago
Nifty3929|2 years ago
Like when you want to copy something, but Ctrl-C is unreliable, so you Ctrl-C,C,C,C to make extra sure.
I want one button for each state, so that I can click it several times if required.
macspoofing|2 years ago
wodenokoto|2 years ago
Despite having existed for more than 50 years and most people are using multiple toggles a day with its labels, most people are unaware of the meaning of power symbol (https://en.m.wikipedia.org/wiki/Power_symbol)
NeoTar|2 years ago
It's not uncommon to have multiple light switches control a single light socket - switching any of them changes the state of the light, therefore you cannot consistently say state-x = light on, state-y = light-off.
marginalia_nu|2 years ago
Any English speaker can understand perfectly well the words manual, manufacture and manicure without ever reflecting on the fact that "manus" in latin means "hand".
We clearly haven't needed to rename these words "handual", "handufacture" and "handicure" for these concepts to be understood by people who aren't fluent in Latin.
In much the same way, even a person who has never seen a floppy disk will associate its likeness with the action of saving if it appears next to enough save buttons.
btbuildem|2 years ago
master-lincoln|2 years ago
thaumasiotes|2 years ago
What? This has been solved for physical light switches since before physical light switches existed.
If the light is on, the switch is set to "light on". If the light is off, the switch is set to "light off".
gsich|2 years ago
DigitallyFidget|2 years ago
Would you flip a breaker to the "ON" position in order to turn it off, or would you expect the breaker to display its current state of being ON/OFF?
low_tech_punk|2 years ago
But there is usability vs aesthetics trade off.
I think Microsoft design systems (seen in Windows, Edge, Office products) only shows the active state probably because it’s easier to align toggle buttons flush when text is only on one side. If you display texts on both sides, the unpredictable text length would make the button area difficult to align.
alpaca128|2 years ago
I think the play/pause button in media apps is an acceptable exception simply because it's obvious whether it's playing or not - you could even use it without recognizing the symbol, if music is playing you know a click will pause it.
thih9|2 years ago
Consider the light switch - if there’s just one, it’s the best UI ever. You know what to do to turn the lights off, just flip the closest switch. Obviously if there’s more than one then it’s the worst UI ever.
Another example, a smartphone’s side button (screen on/off).
mjamesaustin|2 years ago
Unfortunately that design pattern fails for touch interfaces, which increasingly are our primary method of interaction.
croes|2 years ago
Compared to what? Definitely not a checkbox.
The problem of a checkbox is just it's not very visually appealing but pretty good on carrying zhe necessary information.
wly_cdgr|2 years ago
Of course, no one will agree about which state is which,...
tootie|2 years ago
layer8|2 years ago
1970-01-01|2 years ago
kortex|2 years ago
ww520|2 years ago
laserbeam|2 years ago
mapreduce|2 years ago
swingingFlyFish|2 years ago
User23|2 years ago
continuational|2 years ago
brudgers|2 years ago
Or both...like a real world toggle switch.
Or have user configurable behavior (an idea that seems to be mostly out of fashion among designers...get off my lawn).
pcwelder|2 years ago
johnea|2 years ago
Because when it's not being clicked, it is a status indicator...
mhb|2 years ago
lupire|2 years ago
teddyh|2 years ago
Izkata|2 years ago
marcosdumay|2 years ago
freitzkriesler2|2 years ago
As for the 2nd one, I would download a different launcher. I know Nova lets you do that.
1letterunixname|2 years ago
ok123456|2 years ago
unsupp0rted|2 years ago
Macha|2 years ago
jonplackett|2 years ago
mathgradthrow|2 years ago
riwsky|2 years ago
serf|2 years ago
A push button toggle stays clicked in, or better yet clicked in and illuminated, to indicate that it's on.
a traditional 2 way toggle exposes the state that its' in by the position of the knob relative to center.
I mean anyone can flip states around behind the scenes, but if we're talking about a switch/wires/battery/light it all works out as supposed. Let's follow that example.
wmidwestranger|2 years ago
e40|2 years ago
syngrog66|2 years ago
kids: get off my lawn. lol
unknown|2 years ago
[deleted]