Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should toggle button show its current state or the state to which it'll change? (2010)

ux.stackexchange.com

Post reply on HN
Print view View original

171–180 of 303 posts

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#171

Post by AlienRobot »

alonsonic wrote: post #140
kqr wrote: post #98

Earlier quoted context omitted.

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.

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. border-style: ridge;

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#172

Post by thaumasiotes »

CamperBob2 wrote: post #78
lupire wrote: post #35

Earlier quoted context omitted.

It takes 1 day to learn, to avoid years of extra clutter on the screen. But an option or a long press tooltip would be nice for special cases.

Legibility isn't clutter. We moved away from hieroglyphics a long time ago because alphanumeric characters are objectively better.

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.

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#173

Post by silon42 »

pera wrote: post #142
bee_rider wrote: post #55

RIP Checkbox, 1990-2009, you were perfect and unambiguous but for some reason smartphone designers hated you.

Who created the checkbox widget? System 1 (1984) had check marks on the menu and "x boxes", which are equivalent, but not checkboxes afaik

Here are some samples from 1987... (CUA standard)

http://toastytech.com/guis/cua1987.html

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#174

Post by mvdtnz »

derekp7 wrote: post #6

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…

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.

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#175

Post by DanHulton »

Easy. It should be a checkbox.

(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.)

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#176

Post by beezlewax »

empath-nirvana wrote: post #149
derekp7 wrote: post #6

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…

Slack is similarly confusing. I've really never seen a conferencing app that does this well.

Zoom has mute or unmute coupled with icons the least silly choice I've seen regarding this.

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#177

Post by stavros »

actionfromafar wrote: post #60
rjmunro wrote: post #45

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.

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

Mercedes A-class 2014 is this car.

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#178

Post by Night_Thastus »

kevin_thibedeau wrote: post #169
Night_Thastus wrote: post #144

Earlier quoted context omitted.

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.

Disabling a feature doesn't protect you from firmware bugs or higher repair costs from the more complicated hardware you have but are not using.

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)

Re: Should toggle button show its current state or the state to which it'll change? (2010)

#179

Post by phkahler »

alonsonic wrote: post #140
kqr wrote: post #98

Earlier quoted context omitted.

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.

Post reply on HN