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

201–210 of 303 posts

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

#201

Post by FridgeSeal »

AlienRobot wrote: post #171
alonsonic wrote: post #140

Earlier 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…

Peak UX design was the WinAmp and Windows media player skins of the Windows XP era.

They exhibit almost all of these properties, and they were glorious to use.

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

#202

Post by layer8 »

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.

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

#203

Post by AlienRobot »

bee_rider wrote: post #189
AlienRobot wrote: post #171

Earlier quoted context omitted.

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.

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.

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

#204

Post by 1-more »

pjot wrote: post #167
kqr wrote: post #89

Earlier quoted context omitted.

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

My table saw has this as well. A green and red light, both with off/steady/blink states that indicates information about the blade and safety system.

God are they ever nice saws too. Good for you big dog.

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

#205

Post by brianstorms »

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.

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

#206

Post by beezlebroxxxxxx »

csydas wrote: post #200
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 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 -- noti…

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.

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

#207

Post by AlienRobot »

FridgeSeal wrote: post #201
AlienRobot wrote: post #171

Earlier quoted context omitted.

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…

Peak UX design was the WinAmp and Windows media player skins of the Windows XP era. They exhibit almost all of these properties, and they were glorious to use.

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.

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

#208

Post by xahrepap »

csydas wrote: post #200
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 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 -- noti…

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.

Tons of stuff like this. It’s infuriating.

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

#209

Post by kqr »

bqmjjx0kac wrote: post #194
pjot wrote: post #167

Earlier quoted context omitted.

My table saw has this as well. A green and red light, both with off/steady/blink states that indicates information about the blade and safety system.

Mine has this as well! I like the UX, but it's also kind of crazy that they didn't think about red/green colorblind users.

Are they incandescent or LED? Until recently red and green were the only LEDs possible and some industries move slowly on such things.

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

#210

Post by thaumasiotes »

CamperBob2 wrote: post #193
thaumasiotes wrote: post #172

Earlier quoted context omitted.

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.

Post reply on HN