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

241–250 of 303 posts

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

#241

Post by esafak »

01HNNWZ0MV43FF wrote: post #54
mapreduce wrote: post #7

Earlier quoted context omitted.

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

We should go back to checkboxes. The problem here is having the text change and be too clever. [x] Mute [ ] Mute "Oh the X means it's muted" Windows 95 and probably an older Mac had it all figured out.

I would not use that word because it is a negative, so it makes the user think. "Mic on" and "Mic off" are better.

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

#242

Post by 83457 »

bee_rider wrote: post #55

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

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.

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

#243

Post by willsmith72 »

brianstorms wrote: post #205

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

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

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

#244

Post by skydhash »

AlienRobot wrote: post #207
FridgeSeal wrote: post #201

Earlier quoted context omitted.

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

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.

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

#245

Post by tomsmeding »

semi-extrinsic wrote: post #229
csydas wrote: post #215

Earlier quoted context omitted.

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

It also parses certain C++ and Fortran syntax as smileys...

It had (had!) a multi-line code block option. Now it still does, but only in the desktop app, not in the browser.

I'm sure they need some native platform APIs to enable entering multi-line code blocks.

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

#246

Post by koito17 »

lopkeny12ko wrote: post #66

Why not just use a checkbox? Is anyone here a designer with a serious answer to this?

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.

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

#247

Post by mattmaroon »

Sohcahtoa82 wrote: post #192
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...

> computer people are slow to pick up this sort of stuff from other fields 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.

And you don’t die if your mute switch is in the wrong position at the wrong time.

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

#248

Post by jodrellblank »

wolverine876 wrote: post #108
01HNNWZ0MV43FF wrote: post #54

Earlier quoted context omitted.

We should go back to checkboxes. The problem here is having the text change and be too clever. [x] Mute [ ] Mute "Oh the X means it's muted" Windows 95 and probably an older Mac had it all figured out.

Use an adjective? [ ] Muted [x] Muted

... just the one adjective?

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

#249

Post by skydhash »

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

That's basically my 2001 Toyota Rav4 and my brother's 2010 Hyundai Creta.

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

#250

Post by terribleperson »

SoftTalker wrote: post #118
cobbal wrote: post #111

Earlier quoted context omitted.

Should the LED indicate mute on or mic on? I could see it both ways, and so I would also have a hard time trusting this UI at first.

Should be a text label in present tense not (or not only) an "LED". I like radio buttons but something equally unambiguous could also work. Microphone Status [ ] Muted [x] Unmuted

This takes up a lot more space, but I like how absolutely unambiguous it is.
Post reply on HN