Should toggle button show its current state or the state to which it'll change? (2010)(ux.stackexchange.com) |
Should toggle button show its current state or the state to which it'll change? (2010)(ux.stackexchange.com) |
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.
kids: get off my lawn. lol
When you finally get it to toggle on, you realize the shuffle lines turn GREEN, not dark grey like most of the controls. facepalm
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.
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)
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.
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.
"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
Etymology, etc. helps to understand what other people mean and have meant by the word, and what others will understand.
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
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".
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?
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.
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.
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).
Unfortunately that design pattern fails for touch interfaces, which increasingly are our primary method of interaction.
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.
Of course, no one will agree about which state is which,...
https://www.seattletimes.com/business/boeing-aerospace/boein...
How about (2002-?)
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).
Because when it's not being clicked, it is a status indicator...
As for the 2nd one, I would download a different launcher. I know Nova lets you do that.
I'll take a look at Nova. Thanks.
And you probably know now, but just in case Triangle: back Circle: close Square: task manager
https://www.explainxkcd.com/wiki/index.php/2501:_Average_Fam...
See also this comment ( https://news.ycombinator.com/item?id=39344935 ) "it's pretty obvious" that computers use the opposite symbol than the name says.
[Edit: deleted possibly rude paragraph]
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, 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.
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.
Certain Asian languages come to mind, something they started to regret grievously around the time the typewriter was invented.
> 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.
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.
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.
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.
Wish there were a hardware button for "accept cookie" or "yes send me email offers" dialogs to conquer the not clearness.
Whether the icon has a slash or not:
Device is currently ->| On | Off
------+-----------+------
Camera| unslashed | slashed
Mic| unslashed | slashed
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.
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.
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.
- 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
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.
Tons of stuff like this. It’s infuriating.
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.
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...)
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.
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....)
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.
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.
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).
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.
Mobile users might be confused about whether Auto-Rotate is on, but they do know whether Airplane mode is on.
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.
Similarly, sliders and levers help you see which ones are maxed out and which ones are set at a rough 50% or similar.
OP is entirely correct that the UI field could learn a great deal from those standards.
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.
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.)
• 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.
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.
I hate that Windows 11 has regressed on this.
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…
- 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.
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.
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.
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...
Because computer people aren't optimizing for functionality, intuitiveness, or really any sort of UX.
They're optimizing for some idea of "beauty" and whatever is trendy.
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.
> 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.
To achieve hat you're showing you need some depth to the button. Hard to accomplish with today's design trends.
https://developer.apple.com/design/human-interface-guideline...
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.
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.
I think it had (https://andymatuschak.org/files/papers/Apple%20Human%20Inter..., page 56)
I don’t know whether those were the first, but https://skeuomorphic.design/p/from-paper-ballots-to-pixels-t... claims they were, in the sense that the Mac made radio buttons different from toggle buttons.
Does anybody know in what cultures a checkmark would be inappropriate, as that page claims?
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..
IDK, I prefer my boring old UX of 'physical buttons on a dashboard', plus it's a lot easier to interact with without taking your eyes off the road ;)
To each their own I guess
I guess this could be avoided by using "Do open" or "Is open". Would this sound off to a native speaker?
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".
All it needs is "Closed - tap to open"
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
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.
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.
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.
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.
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.
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.
Loudspeaker [()---] Crossed-out loudspeaker
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/
A toggle button is confusing because I don't know the designers intention unless the button shows both options beside it
Mute On[---()]Off
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.
Which means making sure that the verb form doesn't sound like the noun form.
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.
(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.)
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?
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.
[x] Mute
[ ] Mute
"Oh the X means it's muted"
Windows 95 and probably an older Mac had it all figured out.
Just like most devices with signal lights — which have been that way for decades. Historically, the lights are signaling power being supplied.
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.
What I’m getting at is that it’s a lot more nuanced than what I as a software developer might like.
Can you elaborate what your point is, since not having done so, I can't begin to guess?
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.
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.
Microphone Status
[ ] Muted
[x] UnmutedWith a label, a light indicator is unambiguous.
Almost every manufacture has committed AEB on their entire lineup.
Plus, you can turn it off.
You can always turn off lane control too.
Seriously, why not bigger checkboxes?
It shouldn't need designing; but I have a suspicion that an unstyled HTML checkbox input doesn't behave like that.
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)
On the Apple side, things look a lot better. They were able to keep most apps using the native UI.
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.
I suspect you have no idea if OP's feature set is available on the market. I certainly do not.
Not on my iPhone SE screen.
I wouldn't want the buttons or even menu items to be any closer together. It's not about information density, it's about tap areas.
And I'm tapping the screen on the go, on a bumpy bus, being jostled in the subway.
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'm sure they need some native platform APIs to enable entering multi-line code blocks.
Buttons have more affordance too.
[ ] Muted
[x] MutedUnless you’re my TV and it’s completely backwards for some reason.
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.
Thankfully it can be turned off, and it stays off.
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.
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.
5. 3d.
6. Main menus.
7. border-style: ridge;
They exhibit almost all of these properties, and they were glorious to use.
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.
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.
I'm really not a fan of mobile. If possible, I'd rather ignore it completely and just let mobile users rotate their screens.
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.