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.
Default state is mic active. There’s no slash through the mic, when you speak (and it’s above the noise cancellation threshold) you’ll get a green indicator on your name in the participant list. Press mute, you get a slash through the mic and you get the same indicator, in red, next to your name in the participant list. So in many ways they do both.
With a good UI one should not know what is the default - the current state should be clearly indicated. Different backgrounds / colour shades is not a clear indication even if it looks nice this way.
>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.
Hm, this is the opposite of what I've seen. On recording interfaces I'm used to having a button that lights up red when an input is armed -- unmuted and ready to record. In fact I have a digital 8-track sitting next to me that works this way.
Traditional recording studios would follow this pattern too -- the ON AIR sign is lit when the mic is hot, and off when the room is "muted"
Video conference software could certainly stand to adopt this model instead of default unmuted -- I certainly spend more time in meeting muted than with a hot mic.
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.
Device is currently ->| On | Off
------+-----------+------
Camera| unslashed | slashed
Mic| unslashed | slashed
The camera button is on a different row, and gets a background rect that the mic button doesn't, and turns green when on (vs. the red for the mic when off) … but I think that's sort of a mapping to the default Discord state & showing things that are "against normal expectations"…?
I hadn’t noticed- or struggled with this, but I guess it makes sense.
The channels are primarily audio and stream focused, with users video being second in priority (makes sense when you consider its initial target audience).
So by default mic is active, video is not.
When you mute yourself, you get a “muted” indicator next to your name anyway.
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.
On the flip side, a red light has been the symbol for "recording" for several decades. If you do an image search for "record button", it is invariably red.
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
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 impossible to tell. On MacOS I can _barely_ see some text highlighting when I grab the message, but it's not always clear.
Edit: additional complaint
Teams is bad with text in general. It inserts so many random new lines and hidden characters for cosmetic purposes only, and unless you've dealt with the issue before, you have no way of knowing why the powershell one-liner you copied from teams has a bunch of ????????? at random places like code blocks.
I'd say VSCode is one of the best optimized/built Electron apps out there. The team cares a lot about performance and weird edge cases.
I vastly prefer using Vscode if I need some IDE-esque features over something like IntelliJ these days, even if the latter is more "powerful" in terms of features.
I agree. Teams is an app of a constant stream of little frustrations to me. It’s led me to believe that no one who develop/designs uses this tool at all internally.
Not just confusing UI, but buggy UI. It’s not abnormal for people on my team to have “unread” indicators of messages they can’t get rid of. When you focus the app it does a silent refresh and if you start typing too soon the refresh finishing will delete what you typed.
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.
Yes, so bad. Those buttons do a poor job of allowing action and showing state at the same time - they only use one property (icon no color or slash etc.)
Also click-and-hold with or without haptics is not obvious. I was stabbing at the Tesla screen to activate defrost in a snow storm. I had to call the owner to figure out why it would not activate. I really like the 3 but you cant just hop in and go without some prep.
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.
The real pain is this WAS a solved problem in computers too. Almost all of the GUI OS's had a style guide. Usually 2-3 pages at most (usually smaller) and fairly easy to follow. Then everyone went bonkers and wanted to make their own. Then dump that all into one desktop and good luck... Every app is special.
I blame Microsoft for this. They release a completely new UI framework every 5 years, completely abandoning the old ones. The design is outdated and boring. The XAML based UI frameworks look terrible if you use the default settings, and force you to customize. It's great that it's easy to create custom UIs, but terrible for consistency between apps.
On the Apple side, things look a lot better. They were able to keep most apps using the native UI.
Apple was just as bad. :(
They switched at least 5 times in the early 2000s. Like you point out though they finally seemed to have calmed down.
MS had it in the bag too! Everyone wanted that 'sticker'. If you didnt have it almost no one would put your software on the shelf. To get that sticker you had to pass their usability tests that followed their style guide. Then they did like you said and switched it at least 2 times ever OS release.
Plus the web got in there and there were almost zero standards there. So we ended up with dozenes of framerworks that 'do it for you' and those have at least 3-5 generations of goop.
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.
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.
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.
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.
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...
Issue is that modern UX designed moved away from this type of 3D buttons. There was a big transition from UIs using heavy skeuomorphism to a more flat and digital look.
To achieve hat you're showing you need some depth to the button. Hard to accomplish with today's design trends.
>> To achieve hat you're showing you need some depth to the button. Hard to accomplish with today's design trends.
This why some people complain about UI design "trends". They elevate an aesthetic choice over clarity, usability, or function (not sure which word is best here). Or in this case it seems part of the push was to reduce the screen space taken by a control.
It's things like this that make me think the way to make a good UI is to look at what modern UIs do and do the exact opposite.
1. No spacing.
2. Information-heavy cluttered screens.
3. No auto-save. You have to click the save button to save.
4. Colored icons. Colored interfaces. Not "tinted" a hue of black or white. Actual vibrant colors. And not just one color either! Two colors, at least.
Absolutely. I have a theory that "windows" are called "windows" because of the 3D ridges at the borders. The moment we stopped doing ridges, everything went the wrong direction.
This translucent, rounded, acrylic, material, whatever, it's just not fun. We had the technology for making glorious media players in the year 2000. Where did our technology go?
I'm on linux right now and I checked a bunch of desktop environments and every single one I checked the themes for (the theme browser sucks, by the way) what I see is dark theme with a blue tint, light theme with a blue tint, dark theme with a green tint, light theme with a green tint. A Windows 95, XP, and 7 clone. And that's it?
It just blows my mind. I don't know if it's because the theme browser sucks (the websites to browse the themes also suck, by the way), but I can not find one theme like XP but not XP. I'm left wondering where did all those people who made so many beautiful, glorious, amazing WinAmp themes go to. Did they become extinct? Are the theming APIs too limited today to go all out? Is the technology not there yet to have border-image in your windows borders?
This is just so depressing. I'm hoping the pendulum swings back in the next 10-20 years, and hopefully I'm still alive by then to see some cooler GUIs.
I remember modifying the UI of Virtual DJ 6 for friends that wanted their logo on it. It was all bitmaps. And I guess the different skins were 3D renders on existing DJ decks. But they were beautiful, although there was a period there were some issue when laptops were moving to a wider ratio.
Sounds kind of hard to use on mobile, which is indisputably a popular set of platforms.
No need to throw the baby out with the bathwater. Big (resizable) UI elements with poke-ability are fine. Auto-saving can be great depending on the application. Let’s just ditch the false simplicity and flatness.
Every single time I'm on desktop and I see a GUI that sucks, I know it's mobile's fault. Why this button so big? Mobile. Why spacing? Mobile. Why this list of 6 clickable items with one line of text each takes up my whole screen's vertical space? Mobile. Why no more status bars and tooltips? Because you can't hover on mobile. Why is the filter of this table below the table instead of above the table's headers? Because the thumbs won't reach the top on mobile. Why the headerbar buttons have no labels? Because they wouldn't fit in the horizontal space in mobile.
I'm really not a fan of mobile. If possible, I'd rather ignore it completely and just let mobile users rotate their screens.
But checkboxes and switches don't always make sense. You don't always have room for e.g. "Light mode <switch>". Every component that you give more room to takes room away from other UI.
Rather than look at the obvious cases, the hard part is the periphery of what's obvious.
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.
It seems like an odd historical problem though. We could just render checkboxes bigger or with more white space around them, and make the touch area bigger in any case.
Sure, you clould just fix checkboxes. But then you have to deal with select boxes, which also work badly on smartphones.
Then you have the modern smartphone-driven practice of using multipart forms, with one field on each part. You can't see the whole form at once; you eventually find out that the very last field is a date-field with three badly-behaved drop-downs that you can't interact with.
I just don't try to fill forms on my smartphone. In fact I only use it as a (shock!) phone.
Then it triggers when I scroll - there's no place to click/tap safely. And worse, it can toggle and then scroll off the screen before I notice. Then I end up signed up for their marketing emails! :)
I actually have no idea, I made up 1990 completely, I bet it is way too late. In any case, I guess it is just the digitization of an existing UI element from paper forms, right?
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?
Yes, it is unfortunate that in English the imperative conjugation ("open this door") is typically the same as the present participle verbal adjective ("this door is open").
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".
No, you can't get a car with exactly the feature set you specifically want and nothing more. This is because other people want a different feature set. It's even true of things that are vastly less expensive to produce than a car.
This is true in general (for all feature sets anyone might want, there must exist a car with those features) but doesn't have to be true in particular (for a given feature set, there may exist a car with those features).
I suspect you have no idea if OP's feature set is available on the market. I certainly do not.
I would certainly be willing to bet there's nothing with speed-matching cruise control but none of the other features that depend on related sensors and software. Let alone one that also has the rest of the features and no more.
Automatic Emergency Braking and adaptive cruise are difficult features to avoid. The IIHS dings vehicle safety ratings if they do not have AEB. Because of that, even entry level vehicles like the Elantra have AEB.
Almost every manufacture has committed AEB on their entire lineup.
They said they want adaptive cruise control but not lane keeping. Most automaker allow you to disable the lane keeping if you want while keeping cruise (my Ford does this)
He asked for "no batshit insane" breaking system. Sane systems that engage only when it is truly last moment rather then overeagerly or randomly exists. My seat basically never breaks despite having the feature - because itnis setup for actual emergency.
They won’t. The car maker has the Budget product and the Premium product. The car maker wants to justify a high price for the Premium product, so they put in all conceivable features, useful or not.
What you want is a Decent product. If they add it to the product line, it would cannibalize sales for the premium product, so they gain nothing.
For the same reason my wife’s Premium electric toothbrush has a color screen, shitty IOT bluetooth features and a terrible battery life.
If I'm reading you right, you want your car to follow the speed of the car in front of you? Usually delivered by radar assisted cruise control?
That's complicated stuff, and you'll probably get lane keeping assistance too, because it's a package. At least on my car with lane keeping, there's a big button in the center console to disable it.
The last car I rented handled this package terribly. There was a way to disable the lane assistance, but it was a couple of steps and you had to perform them every time you started the car because it wouldn't remember your preference.
Adaptive cruise control is fairly standard these days, even cheaper cars have it.
You can easily turn lane keeping assistance off in my car. I guess it is necessary, because lane assistance massively sux when there is reconstruction. They are not really the same hardware wise, one of them requires radar in front and other camera thingy for lanes.
The lane keep assist in my 2017 Leaf is awful. If I used it, anyone would take me for a drunk driver as it drifts to the edge of the lane and then corrects endlessly.
Thankfully it can be turned off, and it stays off.
Oh is that what "Distronic" does? I literally work there on a backend system that has that term for one of the features, and I've just never known. I always thought it sounded like something AV related (it sounded "disc" adjacent).
Most cars have that feature list, as for the things you dont want, you can just toggle them off or not use them.
Though sedans are a dying breed, so I'd get one sooner rather than later. Everyone and their brother wants SUVs/CUVs and sedan offerings are getting slimer by the month.
If you're not using the feature, then a bug in it would be hard to manifest.
And as for the more complicated hardware, I am afraid that ship has sailed.
Cars have become incredibly complex in the last couple of decades. They are covered in sensors and filled with computers to handle everything, from the injection of fuel and shifting to acceleration and braking to infotainment and climate control.
If you want Cruise Control with distance following that means you get brake-by-wire and accelerator-by-wire with a computer making decisions about when to do both.
You cannot eat your cake and have it too.
If you want a simpler car, then look to the 90's - they still had computers, but obviously the technology was more limited. You won't get radar cruise control or much in the way of blutooth though, obviously. You can still have an automatic sedan with pretty good safety. (Not as good as modern, but decent)
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.
Unless there is an issue with either the light source or the power source. Muted/unmuted is also a pair where unmuted often does not equal "we can hear you"
> 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.
I just opened Spotify on my iPhone mini, just to check, and I really have to disagree. Spotify has TONS of wasted space. Even when you do want to pull up the "extra" menus (which is frequent for me, since it seems like that's the only place to get to the album for a given song), they practically throw the space away. The hamburger menu can only fit two items on its list of 10, because they waste so much space. I'm sorry, but 10 options can easily all be visible simultaneously while still showing the current context of that menu (the song).
But that ethos abounds. They hid all the controls, and make many of the controls that they do show ambiguous. Am I going to be shuffle-play on the queue? Is my queue currently autogenerating songs at its end or is it going to stop at the end of queue? And long presses / hovers provide zero extra information for what the unlabeled buttons mean / do.
I'm pretty satisfied with Spotify UI on the whole, mostly because of how easy they make it to toss the currently playing song around to different devices and they handle shared control well, but I do wish it didn't require three taps and a scroll (in a context where it's not even obvious that scrolling is possible, because the list is so sparse that it doesn't look like there are any more items at the end) to get to an album, which is almost always the context in which I want to listen to a search result.
By that same token, if I'm tapping the screen on the go, on a bumpy bus, I'd prefer for the control to be visible and for the screen to be unscrollable / locked in place. But I'll concede the point.
> "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.
So, while the button is not interacted with (unmuted) and not hovered over you would like a mute button to be what? Would you like it to be black and white with a microphone symbol where the microphone is white and the background is black? When you hover your mouse over it should a no symbol in red appear over it which could appear black for color blind? When you toggle this mute button should that no symbol stay on the icon and invert all of the colors so now the background is white the microphone is black and the no symbol is white?
I'm really confused by the concept of a button showing me what a button should do All of the time because if that button is showing me what the button should do then that button is indicating to me that that button is doing what that button is doing not what the button should be doing. That's why there is a hover over state if you're using a mouse things become more complicated when you're using touch which is why I think the button should not communicate what the button should do when interacted with but the current state.
Why are you making this so complicated? The simplest solution is just a button with text on it. But sure, maybe you want a symbol instead, they do look nice and take less space.
So when sound is playing, the button should have a symbol that conveys "mute", like a speaker in a stop symbol. If you hover over it, the tool tip should say "Mute" or something to that effect.
If the button is clicked, then the sound is muted. Now you could change to a symbol that conveys "unmute" like just a speaker symbol. Or you could let go of the whole button concept here because it's pretty clumsy and ambiguous, and just use a toggle switch instead. Could just have the text "Sound on" - "Sound off" on either side, or symbols if you prefer that.
You should never assume that the user knows anything. The UI should convey everything the user needs to know, trying to use some sort of convention doesn't work because there is no convention. Avoid using signal colors because as you alluded to that also gets complicated.
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.
If the light is beside the switch (rather than being the switch) then I'd say it clearly and unambiguously indicates the current state of whatever the switch operates?
(A light also has the advantage of being a skeuomorph - much as those are now out of fashion - we all know how to interpret indicator lights in the real world.)
The standby light on a TV in on for standby and off when viewing because a) it could be distracting and annoying for the extra LED to be shining while viewing in a darkened room, and b) the "on" state should be pretty obvious because of the stuff on the screen.
In electronic music instruments (which derived interfaces from electronics lab equipment) it's quite intuitive there's a switch with a light on next to it the next state is off and the light switches off.
> 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?
This interface has both a toggle switch and a light indicator next to it. Both state and action (ish).
The light is independent of the toggle and shows the current state, which is why they mentioned a delay - clicking the toggle doesn't immediately change the light indicator next to it, clicking the toggle tells the system to turn it on and the toggle changes immediately to show desired state, and only after the system changes and sends back "I'm on now" does the light indicator change.
"Mute [x]" means that 'mute is false', so I click to make it say "Mute []" but instead you take the "x" away, ... so is mute no longer false?? If sound isn't working then this can be difficult to determine. You can fix it with a tooltip and/or familiarity with the system.
I see! Those were two 'screenshots' of the same setting, one in selected state and one in unselected state, following the example of a post upthread. They were not two different settings - yes, that would probably be poor UI design! I've seen worse.
It's also quite common to have a light indicator that goes away when the device is turned on. TVs often do this - they have an indicator LED to show that they are plugged in, but turn that LED off when the screen is turned on, because it can be distracted, and is anyway no longer needed.
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.
Most of the training is to know which ones need to be on and which ones need to be off. Not how to read various buttons as on or off. And the point there is they are able to rapidly scan a dashboard to know what is on and off at a glance.
Similarly, sliders and levers help you see which ones are maxed out and which ones are set at a rough 50% or similar.
That may not be explicitly trained, but it's heavily trained becasue they must get that right to pass the tests. If they misunderstand at first, they won't for long. Also, the user is highly motivated - they don't want to crash the plane.
Consumers are often looking at UIs for the first time, and are highly motivated to go back to their feed and see what they missed.
Since failure to operate the controls correctly can get hundreds of people killed, there are detailed regulations governing how those controls must work.
OP is entirely correct that the UI field could learn a great deal from those standards.
I mean, sure? But, to that point, why discuss the conventions? If the goal is to have a predictable interface, it seems fair and in scope to study larger interfaces that people have to read quickly.
Don’t get me wrong I actually agree with you. I’d also love to have more consistent ui’s, but at the same time I get why the business wants to differentiate it self from the competition by not having a super effective “boring” ui.
What I’m getting at is that it’s a lot more nuanced than what I as a software developer might like.
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.
> "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."
"manual" is "by-hand".
"hand-made" is the literal meaning of "manufacture" (make by hand), if not the industrial meaning used today. From Old English hand-wrought, apparently: https://www.etymonline.com/search?q=handmade
Well, in this case, if one person says it does, and another doesn't see that it does, shouldn't the latter conclude they are likely missing something?
If I say 'this truck hauls 2 tons up Mount Rainier' and evidently I do that, and you don't think so, wouldn't the rational conclusion be that the truck does it and you were unaware?
I and many others, for centuries, have used etymology to understand meaning and history. Don't tell me it doesn't work - I do it, just like driving that truck. You can't do everything, we all miss out on most things, but you are missing out! :)
> in this case, if one person says it does, and another doesn't see that it does, shouldn't the latter conclude they are likely missing something?
In this case, we already have all the facts, so there's no reason to talk about what's likely.
Etymology is not informative as to meaning, and therefore cannot help anyone learn how a word is currently used. You are advocating for the Etymological Fallacy ( https://en.wikipedia.org/wiki/Etymological_fallacy ), but the name of the position you're taking should be a hint about whether it's actually a valid viewpoint.
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."
this is backwards from the perspective of digital logic circuits
physical light switches toggle between closed-circuit and open-circuit, not high and low voltage levels. 'on', where current can flow, is a closed circuit; 'off' is an open circuit
in digital logic, when there is a correspondence between closed/open and high/low, the correspondence is virtually always that closed is low and high is open. for example: ttl inputs always treat open-circuit as high; the can bus and i²c bus "recessive" states (when nobody is transmitting) are high; avrs have optional pullup resistors on their gpios but no optional pulldowns, so if you want to connect a pushbutton or toggle switch to a gpio, you have to connect it between the pin and ground, not between the pin and vcc; 8051s' 'quasi-bidirectional' i/o ports similarly feature a weak pullup and a strong pulldown, so that, again, an open circuit is a logic high level
(and normally high is 1, low is 0, though sometimes this convention is also violated)
the only exception i know of is that 60-milliamp and 20-milliamp digital current loop interfaces, as used on teletypes, treat a closed circuit (current flowing) as a logic 1 ('mark'), and an open circuit (no current flowing) as a logic 0 ('space')
incidentally, 'closed circuit' and 'open circuit' are also confusing. a closed circuit is 'closed' in the sense that a plane curve is 'closed' if it divides the plane into an inside and an outside region. on a closed curve, you can walk around the whole circuit and return to your starting point without turning around, which is in some sense what the electrical current is doing. but of course actual electrical circuits exist in three-dimensional space, where a 'closed' curve does not divide space into an inside and an outside region, because you need a surface for that. and in all other contexts, something that is 'closed' is something that does not permit flow: a closed barn door, a closed window, a closed valve, etc. nevertheless, it is far too late to eliminate this two-dimensional flatland thinking from our vocabulary
Silicate chemistry is second nature to us geochemists, so it's easy to forget that the average person probably only knows the formulas for olivine and one or two feldspars.
Yes indeed. I need to explain to IT people that most users don't even understand hierarchical folder structures; many don't understand folders. They don't believe me.
> 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".
That is a poor design choice. VERB STATE TRUE is standard for every toggle switch on all my hardware, including prosumer amps. Changing this can be deadly, and was found to be part of the reason for the 737 MAX going down in 2019:
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?
Hieroglyphics are alphanumeric characters. We moved away from them because they are much too detailed to be convenient to write.
You could make a case that alphabetic characters are "objectively better" than syllabic characters, but you'd have to do it on some other basis than "we moved away from them a long time ago"; syllabaries are very common today and don't cause problems.
OK, as I'm not an Egyptologist, let's substitute any other language whose orthography is based on icons and pictograms. There aren't many, and there's a reason for that. They suck.
Certain Asian languages come to mind, something they started to regret grievously around the time the typewriter was invented.
OK, here's an example of some written language with a heavy reliance on logograms:
> omg how r u doing that
> lmfao
> c u 2nite
(2nite is especially interesting because the icon is used to represent just part of the word!)
This is mostly notable because the formal written system didn't allow it, and the logographic forms were introduced spontaneously as a result of large numbers of people being literate. In other words, they are an example of the direction of change pointing toward logograms, not away from them.
> Certain Asian languages come to mind
Japanese is the only one that might fit this description.
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.
Ah yeah I know what you mean. For what it is worth, they've been pushing a new gestures system that supercedes the old tool belt buttons. Not sure your tablet has that.
And you probably know now, but just in case
Triangle: back
Circle: close
Square: task manager
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.
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.