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.
Should toggle button show its current state or the state to which it'll change? (2010)
181–190 of 303 posts
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#182I 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 (usu…
> 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 shu…
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.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#183One 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.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#184It 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).
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#185The 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.
Can someone make a car which has none of the complicated stuff? 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
You've described a 15 year old BMW 3 Series.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#186The 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.…
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.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#187This 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…
This isn't the case for me, I wonder what's different between us as I just tested:
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.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#188Earlier quoted context omitted.
I like it. Why doesn't our "industry" look at aviation/military more often where miscommunication gets people killed.
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.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#189Earlier quoted context omitted.
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.
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. 5. 3d. 6. Main menus. 7. b…
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.
Re: Should toggle button show its current state or the state to which it'll change? (2010)
#190Earlier quoted context omitted.
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.
True. 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.