Hacker News Reader

Comment by lstamour | Hacker News Reader

I’m surprised nobody has mentioned that iOS has had round checkboxes since forever? https://ux.stackexchange.com/questions/116712/apples-round-c...

Likewise I thought the article’s punchline was going to be the increasing use of on-off toggles instead of checkboxes. Like how the settings app on macOS now has more on-off toggles than ever before.

Personally though, my fav pet peeve remains the unclear toggle button. When the icon is white, is it on? Is it off? Does the line through the microphone mean it’s muted? Or that it mutes when tapped? No one knows, tap it a few more times to find out…

View on HN

My "favorite" toggle button is the one where they add on/off labels[1] to it, but only one, and the slider hides the label. So the label actually tells you the state, not the state it would be when you move the slider over the label. Or at least that's how I think how they work, it breaks my brain a little whenever I look at them.

[1] https://itsfoss.com/content/images/size/w1000/wordpress/2022...

Or when you try to unsubscribe from a mailing list and are prompted:

  Unsubscribe from the following:
  [X] List A
  [X] List B
  [X] List C

  [ ] Unsubscribe All Lists

But if you check the "all" button it clears all of the individual ticks.

I would say a solid 80% of unsubscribe prompts have some sort of similarly confusing layout or verbiage.

That's by design. They want to minimize the number of people who completely unsubscribe.

Having an Unsubscribe All Lists checkbox doesn't minimize that. It just adds form noise and pointless work for a dev. The minimization already happens with the preceding checkboxes to select each list to unsubscribe from, but that's just as inherent to the form as the desirable feature of being able to keep certain subscriptions while unsubscribing from others in an efficient way.

A button or link in place of the 'All' checkbox makes sense and is easiest for users to understand, and has less user actions required.

Treat your customers well even when they're exiting (especially) so they remember something good next time they consider you. "Well at least they made it easy to unsubscribe" is better than "Well they made it unnecessarily complicated to unsubscribe". No need to add insult to injury.

I think this is about confusing AI like that offered from gmail or iCloud email that will unsubscribe for you if you click on unsubscribe from their respective inbox / application. Fastmail offers this too.

I noticed there are times I have to do it manually and can't take advantage of auto unsubscribe because the button layouts are like this.

The unsubscribe buttons in email clients are powered by a header that the email includes. Google and Yahoo just started requiring these for all bulk senders (they were previously a best practice only). It doesn’t rely on what the manual preferences page looks like.

This is just a standard unsubscribe header. It's added by the sender specifically for this purpose and has nothing to do with the UI you see. Not everything is AI, but it being the default assumption is funny to me.

I have to admit I've never experienced this. When I check the "all" checkbox it goes and checks all the other checkboxen for me. Maybe I've only interacted with "nice" unsubscribe pages.

I've seen both versions, and whether they check or uncheck all of the other options (behaving like a radio button), both versions are overcomplicated nonsense.

The unsubcribe-all should just be a link or button with its own submit value or URL param (like unsubscribe=all).

I don't know why people overcomplicate things.

It makes no sense to have a checkbox for "Unsubscribe All Lists". That should just be a link. There's no point in adding a redundant form element even if it's only conditionally redundant.

Or a radio button between all and choose which to unsubscribe from.

I remember when I designed a list of checkboxes this case was specifically considered. The last one needs to be updated when all of the checkboxes above are checked or one of them is unchecked.

I would not be able to tell if these slider toggles were saying "yes" or "no" without them going from gray to green. How do colorblind people deal with them?

That the whole world adopted these abominations, when there was absolutely nothing wrong with checkboxes, is immensely frustrating.

Does green (usually these are blue) mean yes? Every time I see one of these I realize I don't understand them and I'm not even sure they are consistent in behavior. I usually use a context cue to infer what they mean. The dumbest part is there is plenty of room to just write "on" and "off" right on them.

I think it is no coincidence these are the preferred control for all manner of dark pattern setting screens.

Yes, green means "yes".

Now, does light-green mean "no" because it's light, or "yes" because it's green? That one you have to check on each application.

Most of us cope just fine, so long as the contrast between the states is clearly different. My colour blindness is anomalous trichromacy, with a perception difference for red-green. Because the examples shared are a bright blue for on and black for off, I can see it just fine, however, I'd suggest making the switches off state back ground the same as the main background in this case. Aesthetically, it looks better.

An icon or text should indicate the current state while hover text should indicate what will happen if you click. At least that's what we do. It's still confusing, but I agree you should be able to infer current state by looking at it. The person who designs it thinks it's obvious but it's usually not.

Checkbooks are quite self explanitory.

Hover isn’t really acceptable UX since the touchscreen era

Even on desktops it's not great for accessibility. There isn't an indicator for what has tooltips, and they appear out of the usual flow of control.

Accessibility guidelines usually allow them but encourage you to make it a last resort.

Not to mention that half the time tooltips don't show up until you wiggle the mouse over them a bunch, and tooltip delays are arbitrarily timed and usually far, far too delayed (often on the order of hundreds of milliseconds when they should be like 10-50ms at most). And my biggest pet peeve about them is that, at least in Chromium-based browsers, they really don't like to go away once they finally show up, to the extent that I can often scroll the page until they're offscreen and they still don't disappear. Or they leave the farm entirely and persist outside the browser window.

Also, most windows aren't eligible for tooltips if they are not the focused, active window. I remember that difference being hard to explain to people when Windows 3.x and Mac Classic used entirely different title bars between the two states and sometimes even "shadowed" the window contents. It's especially hard to explain to today in a multi-monitor world and when inactive windows respond by default to all other inputs except some hover behaviors like tooltips. (I'm a software developer and know all this too well and I still tripped over it the other day wondering why tooltips wouldn't show up in a window and only realizing belatedly that the window wasn't active.)

>> Hover isn’t really acceptable UX since the touchscreen era

It's an augmentation that can be used on desktops though. I agree that it shouldn't be necessary but, but it can help. Some apps aren't meant for mobile either.

Real question: Are there any touchscreens that provide the equivalent of hover with your finger?

I have an older Android (Samsung S5) with a physical hover feature - you literally hover your finger close to the screen and it triggers hover actions like previewing a message or opening a magnifier over text. It is called "Air View"[1] in Samsung lingo, and was coupled with other features ("Air Gesture"[2]) involving moving your hand over your phone to do things like scrolling or waking the screen.

It's finicky on occasion, but when you are used to it, it's surprisingly intuitive practical! It wasn't super popular though, and I imagine it could be annoying to users who didn't want it. It appears they only did it for a few models, ending in the S5.

That phone was pretty interesting, sensor-wise. I kind of miss using it, and I wonder if it would be practical nowadays.

[1] Air View: https://www.samsung.com/hk_en/support/mobile-devices/what-is...

[2] Air Gesture: https://www.samsung.com/hk_en/support/mobile-devices/what-is...

Would tap-and-hold be the closest equivalent?

Long-tap to see tooltips is a convention that has been proposed in various incarnations of the Android UI guidelines. The convention was present in very early Android UI guidelines (e.g. Android 4.x); I'm not sure if it still is.

The problem is that long-tap gets used for a lot of other things on Android (extended selection, particularly). The user experience is pretty unhappy if you use both conventions. And, in practice, long-tap tooltips are so rarely provided on Android apps that I doubt that ordinary users would expect them at all.

As far as I know, tap-and-hold (as distinguished from long-tap) isn't a conventional gesture on Android.

At least that’s how you get tooltips on Android. Of course, tooltips were designed to be discovered by a user hesitating with their mouse over an UI element (sometimes works, sometimes doesn’t), while tap-and-hold on buttons you have to know about, and it’s still scary when the button looks like it could do something potentially destructive and you want to find out.

Depends on who your target audience is. Many applications can still safely assume they are for office workers using a desktop or laptop computer with a keyboard and a mouse.

It is ok; you just have to offer a different UX for each medium. And not every application is done on every medium. I don't code or write long-form on my phone.

Laptops have touchscreens too.

And trackpads or mice that let you hover.

Some laptops fold so the mouse/trackpad is inaccessible and/or disabled.

I have a Lenovo yoga, and its a constant nightmare of websites and apps that cannot figure out if I am a laptop or a tablet, even with tablet-mode fully off. I am usually offered whichever UI is least useful for my current configuration

Current state is the best, but it's still not immediately obvious unless you say "current: on" and "Click to turn off" in the hover.

At least sliders generally have right for on, as opposed to pure text toggle buttons which are just awful.

An element should do one thing, not two.

Showing the current state matches light switches with the state on them.

https://www.homedepot.com/p/Leviton-15-Amp-Single-Pole-Switc...

Or car door locks which show red (unsafe) when unlocked. It's showing the current state, not the state that will be when toggled.

And (as a european) i'm reminded of the confusing american light switches which show a light when they are off. Oh, and they toggle in the wrong direction (up is on?).

By comparison, it's quite common here to have a switch with a lamp to indicate the light is on, which get used when the status of the light cannot be easily seen where the switch is located (e.g a switch for a light in the loft/outside light etc).

I'd say in a residential setting our switches make a lot of sense.

The light up variety are mostly to aid turning on the lights in the dark and aren't usually the default. It's nice being able to see the switch when entering a dark room.In a residential setting it's a bit more rare to have a switch control a light you're not either immediately seeing or are often imminently going to see, like a closet or looking out a window next to the switch. It's not like you're often turning on and off lights across the house, so having it light up when the room lights up is rather redundant instead of offering that dark time help. Finally, having an on light would be really redundant since you can usually easily see the switch is physically pointing up or down and they sometimes even say ON or OFF.

As for up being on and down being off, it's about being easier to toggle to the safer state. It's more likely for off to be a safer state (think changing a bulb, having it connected to a garbage disposal, etc.). It's generally easier to flip the switch down than flipping it up, so it's easier to toggle to the safe state rather than the unsafe.

> And (as a european) i'm reminded of the confusing american light switches which show a light when they are off.

I have those in Europe. The point is that you can find the light switch in the dark. Why would it need a light when it's on, if it's in the room that it lights?

This reminds me of when i was studying electronics and we had to design a circuit with some purpose. I made a “Light indicator” with an LED a photoresistor and some other stuff.

I believe American light switches are intended to confirm to a standard if installed correctly. But that all goes out the window with a 3 way switch.

I guess such interactive elements always show the current state of the system, and when they are interacted with, it changes the state it was in, examples: 1. Social media buttons for upvotes/likes/dislikes 2. on/off toggle switches for features 3. microphone/speaker buttons on desktop OSes

The YouTube play/pause button shows the action it will do, not the state that it is in.

I miss the old convention of showing a button with shadows indicating it's been pushed in vs. showing it with just a flat plane when it's not pushed in. A button that shows that it's been pushed in with a triangle icon means it's playing, clicking or touching it will stop it from playing. A button that doesn't indicate it's been pushed in with a triangle icon is not playing, clicking or touching it will start it playing. Bonus points if there is a small virtual led that turns on when it's pushed in.

Fewer and fewer devices we have access to these days have physical switches on them, though.

As someone who has built media players, the established convention seems to be that the play/pause button shows what the button will do. It hurts me to do "button shows what it will do" every time. But all the other media players I'm familiar with do it this way.

Does anyone know of a major media player where the play/pause button shows what the state is, rather than what the button does?

Why not just have separate play/pause buttons and highlight the active one?

>> The YouTube play/pause button shows the action it will do, not the state that it is in.

A lot of physical play/pause buttons show both symbols. Also in a lot of cases you can tell if a video is playing.

Not if it's buffering because you know that you have a bad internet connection. Around here, I often see people skip to an earlier portion of the video to check if it is playing or not.

And that is anyway besides the point of consistent UIs' toggle switches describing their state, not their action.

Red means “stop” and green means “go”. So how the fuck does red mean “this door is passable”??!

“Unsafe” is contextual. If you are inside the car, and the car is on fire, then “locked” is very much the “unsafe” option.

I've been in moving vehicles where opening the door would have been unsafe more than I've been in car fires. I often lock my car when leaving as well which usually unlocked is a bad state to leave it in, that normally happens more often than being in a burning car.

Are you in burning cars often?

Honestly, if I’m in the car and we’re driving then I want to see a red light for same reason: red means stop and green means go. Or from outside after parking it: will this door open or will it stop somebody.

Red also often means "danger, caution" not just "stop". A red stop sign means "pay extreme attention here, there's danger, please stop and evaluate". A red DO NOT ENTER sign isn't just saying to stop, its saying there's danger heading that direction. If you just stop there its probably not going to end well, So clearly they're signaling more than just "stop".

I'm still unsure, have you been in many burning cars before? More than just moving vehicles?

If you’re inside a car and the car is on fire, you’re not determining the state of the door lock by its position visually. For people inside the car unlocked is the unsafe position in most cases (leaving, driving.)

(Do car still come doors that don’t automatically unlock when the handle is pulled, if the child safety switch is disabled?)

On many guns, switching the safety to the "fire" position exposes a red dot, red meaning "hot" or "fire".

Yeah my CZ pistol is like that and it’s fucking terrifying because in my mind red means stop or locked. I actually feel more secure with my Glock because it doesn’t have a safety so it’s unambiguous. If I point my Glock and squeeze, I know it’s going to fire.

The red of a stop light makes a lot more sense in relation to the red of a fire mode on a gun when you think of red being "caution, unsafe" instead of just "stop". Just like the red of a STOP sign is to caution you into paying attention of the danger of the cross traffic, not necessarily just stopping.

Red lights on top of towers isn't trying to tell planes and helicopters to stop, its telling planes to exercise caution around the tower.

Reprogram your brain for "Red means danger, green means safe" and you'll do a lot better.

Red at a traffic light means there's a danger so you stop. Green means it's safe to proceed.

Red on a gun safety switch means danger because it's live.

The red wire is live and dangerous. The green wire is earth and safe. (at least true in Europe).

Or like at a railway crossing. The flashing lights indicate danger, and the barriers drop. According to GP, the lights should flash when the barrier is not dropped, because now it's unsafe, FFS.

Ah, my CZ is a DA/SA with a decocker. I'd recommend it! No manual safety, but you can hold the hammer forward while holstering.

At my current workplace (particle accelerator) one control panel in particular has red for "good" as in "this is red, so don't go in here, because everything's fine and you have no reason to". Always amuses me.

The link is 403 for me.

It's been archived

https://web.archive.org/web/20240128035720/http://www.homede...

My "favorite" is when they use green color to indicate "Off". Like in this page

https://www.istockphoto.com/plans-and-pricing

The dark patterns here are something to behold (A bit like Adobe's stuff)

Those are terrible. I think I’ve had analogs in the physical world where toggles indicated state by the color exposed (green = on, red = off) but this tries to be better by having both color indicator and text indicator) and you’re left deciphering their language a bit. Yes, it is terrible.

The intended analog is lightswitches with the text on them.

https://cdn.thisiswhyimbroke.com/images/lightswitch-identifi...

With a light switch you can immediately verify that the switch is in the correct position by looking at the light you want to control. Text/labels/positions don't add anything of value. Also, it's usually safe to experiment with the toggle until you get the desired state.

In software often none of this applies.

I've never seen lightswitches like those, but that's a terrible design as well, for the same reasons.

They're ubiquitous in America, but approximately nobody pays attention to the text because the position is what indicates on/off, where "up" in "on".

Huh, I'd always considered that toggle switches are "down is on". (UK resident).

That way it's the same as a standard rocker switch (the direction of rotation is the same).

Agreed, in the UK:

- 'angled towards the ground' is 'On' (https://cdn.aws.toolstation.com/images/141020-UK/800/10481.j...)

- 'angled towards the ceiling' is 'Off' (https://www.tlc-direct.co.uk/Images/Products/size_3/MKK4870....)

But that's completely backwards from a normal rocker switch!

In Aus most light switches are rocker switches that are also "down = on".

In aviation (and old cars) switches are usually toggle switches with "up = on".

Strangely I'm ok with both. I think of rocker switches as opposite to toggle switches automatically.

- https://www.google.com/search?q=rocker+switch

- https://www.google.com/search?q=toggle+switch

I’d expect a rocker switch in America to also be the same as our light switches - pressed at the top for on, pressed at the bottom for off.

That's generally a rocker switches work on devices in America, e.g. guitar amps: the side that is pressed is "on" or selected/enabled.

Last time I was in Europe (Portugal), I remember having a lot of difficulty making sense of the light switches, but it was one of those apartments where you have two or three light switches controlling the same fixture, which is always confusing.

Still, I think the American light switches are actually pretty good. Maybe one day we will get a Technology Connections video about light switches around the world.

Until you encounter a switch that's part of a three-way switch arrangement where up can be on or off depending on the position of the other switch in the circuit.

I've lived with these my whole life, in every place I've lived, plus with one or two switches that were sideways, so the first time I'd ever heard "up is on" was in a comment thread like this a few months ago. I didn't think there was any sort of standard, it's just always been "flip the switch if it's not currently what you want".

This is in the US.

It's still "on" in the sense of the circuit being closed.

In this case I mean "down" as in "the long part is pointing toward the ground", not "some button-like thing is depressed towards the wall".

> green = on, red = off

Are you sure? I think the opposite is more common.

where have you seen red = on, green = off?

In electrical industry, red used to mean powered or hot or dangerous, green unpowered or harmless.

All earth-leakage breakers in my area are like this: https://en.m.wikipedia.org/wiki/File:Schneider_Electric_A9D3... https://i.ebayimg.com/images/g/sHYAAOSwu2ZkBk5~/s-l960.webp

Electronics industry have diverged.

Most safety switches on firearms expose a red dot meaning the weapon is "ON"/ready to fire.

I agree with you on that, but I’ve never seen green be the contrasting or alternative color.

Maybe because a gun should never be treated as totally safe.

In security red generally means encryption/protection is active.

And then there is this: https://en.wikipedia.org/wiki/Tally_light

> In the active (on air) mode, tally lights are typically red.

> Some cameras and video switchers are capable of additionally showing a preview tally signal (typically green) for when the camera is about to be switched to and become the main source of video signal. Once the switch happens, green changes to red.

> In security red generally means encryption/protection is active.

That's daft. You want to highlight (red) the insecure state, and reassure (green)in the secure state.

Really?

Do you want a real-world example have a look at US White House:

> President Obama talks on the phone aboard Air Force One. April 10, 2014.

> The Airborne Executive Phone has the red light on, which means it's a secure call.

https://www.electrospaces.net/2017/01/the-presidential-commu...

It is further made more clear because NSA literally calls their secure network the red network.

I’ve seen it a few times on the web with cookie preferences pop-ups, to set your tracking and personalization preferences. Dark patterns to confuse and trick website visitors into enabling all tracking settings.

red and green should not be used like that. A significant fraction of the population, especially males, has difficulty telling them apart.

That's why mains wiring no longer uses red to mean live and green to mean ground.

I have at TV that is red-lamp off, blue lamp on.

I actually hate this one because it’s completely unclear.

Does OFF there mean

-the setting is off

-Slide this thing over to turn it off

I’ve seen it both ways. It’s confusing and not clear.

https://www.youtube.com/watch?v=Ljjns1Y1q-A

is the bridge open when it's up or is it closed when it's up?

are you in a car or a boat?

I don't like these. They can be mistaken to users as an indicator of what moving the "lever" to the other side of the toggle button will actuate - effectively reversing the user's intent of the button as compared to what the buttons do.

My same thoughts. The inventors of that revolutionary toggle button should all be tied to the South side of an ass walking towards the North.

Yeah so in your example:

"Disable all extensions" = OFF.

Does this mean all extensions are currently on, or off? Does toggling the switch to on /enable/ the disable-all-extensions subroutine?

A switch brings in a bunch of double negatives that can be avoided in most cases.

Hella confusing!

>> A switch brings in a bunch of double negatives that can be avoided in most cases.

If you put the labels next to the switch: ON [xxxx] ---- OFF then it's clear that sliding the switch toward the label puts it in the on or off state. But hey, we can save some screen real estate but swapping the labels and hiding the inactive one under the switch! Yay! For on/off a chechbox is much clearer for the size.

Physical switches are labeled like that. Somehow, it's not a problem for them, but I do agree that on-screen ones are very unclear.

It's rare to see physical switches like mobile toggles. Most switches show both labels with the switch pointing to the label. It's clear what the status of the switch is and what changing the switch will do.

With software however, the inconsistency comes from knucklehead design. Hipster aesthetics. "But I want ours to be different!" They introduce toggles that don't follow convention and make unclear the status and behavior, or if touching it will even do anything. It then muddies up in people's minds how the conventional ones look and behave.

Physical sliding switches usually look exactly like the ones on your link.

Ex: https://www.chily.com/customer/chily/product/3331_350.png

(Why selling photos of those things never seem to show the label?)

When a button displays the text "mute" ... does it mean that the status is CURRENTLY muted, or that pressing that button will make it MUTE?

Yep!

When the _state_ and _action_ are intermixed it becomes ambiguous. This is one of may things we lost in the war on skeumorphism. The skeumorphic interfaces could mix both more clearly, using shading and texture and "lights" to indicate that a play button was pressed down and active.

Look at this UI, it's mix of state and action: https://discussions.apple.com/content/attachment/861693040

fast backward rewinds: Probably showing action

Play: 100% ambiguous if action or state

fast forward: Probably showing action

Volume slider: showing state

Back-forward buttons: showing action

Select drop-down: Showing state

As someone who has no experience with this version of iTunes:

- The lower row is definitely a row of buttons. Back, forward, categories in the library (?), I don't know what the last one is supposed to do.

- Are the things above that row buttons? Why don't they look like them then?

- If they are, what does fast forward and rewind do? Skip to the next track and to the beginning of the same track? Actually move quickly through the track (like fast forward and rewind used to do)? Does pressing rewind go to the beginning of the track or to the previous track? If it's to the same track, how quickly do I have to click again to go to the previous track?

- Is that slider a progress bar or volume slider?

- Where do I click and drag to move the window? If it's in that top row, why are there things cluttering up the title bar? How much space do I have left to move the window?

- I assume the coloured things are the window management controls. Does clicking the red one close the window and keep the music going, or does it stop?

> what the last one is supposed to do.

It's indicating an iOS device being locally, e.g. for administration, backup, file transfer and the like.

> Are the things above that row buttons? Why don't they look like them then?

Haha yeah. That's modern Apple for you!

> what does fast forward and rewind do?

They sort of behave the way ff and fr does on a remote. Click/press fast and you skip to the next/previous song/chapter or equivalent. Hold down and you scrub at something like 4x speed.

> Is that slider a progress bar or volume slider?

A volume slider.

> Where do I click and drag to move the window? If it's in that top row, why are there things cluttering up the title bar? How much space do I have left to move the window?

I ask myself the same thing every day and have the same problem with many many apps, also in Windows. For example Firefox has the same design problem where its buttons have nor border and therefore have no clear place where draggable top space is and button is.

> I assume the coloured things are the window management controls.

Yes, these have remained mostly unchanged for over 20 years, they have gotten a bit flatter and lost some subtle small iconography.

> Does clicking the red one close the window and keep the music going

At least this part works well and in a predictable fashion. It consistently follows Apple's Human Interface Guidelines since well over 30 years: Closing a window or document of a Mac OS application should not quit the application. (there are some exceptions, but that is the default behaviour).

> For example Firefox has the same design problem where its buttons have nor border and therefore have no clear place where draggable top space is and button is.

This can be changed by going to "about:settings" page and setting the option "browser.tabs.inTitlebar" to 0.

That about:config setting is a halfway okay solution for a single app, it loses vertical space however, which is my premium. Optimally I would like a way to (in all applications which has this problem) to _simply show me_ what is a UI widget/button and what part is "inert" draggable window chrome, like this older screen shot where the distinction is unambiguous and clear:

https://i.stack.imgur.com/Se6i0.png

It's actually trivial for a website to fill up that space with invisible tabs, too.

https://bugzilla.mozilla.org/show_bug.cgi?id=1749835

> what does fast forward and rewind do?

symbols in "traditional" media playback, the icon shown would traditionally be for fast reverse/forward. skip back/forward to the previous/next would had a vertical bar to the point of the triangle. some also go so far to differentiate skip/scanning where scanning uses two triangles while skip uses one triangle with the bar. not really sure what Apple has done to them though. i would almost expect them to be skip instead of the scan with Apple expecting you to use the playhead (in whatever format it is made available) for scanning.

the play button in Apple's use is typically action instead of state. so in this state, clicking it would start play, and then the button changes to the "pause" symbol (an = rotated 90°).

so this is a really good example of mixing usage.

>> This is one of may things we lost in the war on skeumorphism. The skeumorphic interfaces could mix both more clearly, using shading and texture and "lights" to indicate that a play button was pressed down and active.

I suspect a lot of the choices also have to do with saving screen space, but in the end a checkbox is one of the best ways to indicate "enabled" on a settings screen.

I'm designing an app right now with this pattern and I'd love to get it "right".

We've got a video playing and an icon button which controls whether the video is muted. We've got a "playing speaker" and a "muted speaker" icon.

What's the correct pattern? Should the icon reflect the current state, or the expected state after pressing the button?

One button one function if you ask Dieter.

https://en.wikipedia.org/wiki/Dieter_Rams#/media/File:Dieter...

Although not standard, I'm thinking that a slider with a muted speaker icon to the left and a playing speaker icon to the right would be unambiguous.

a dedicated mute button for single click action is much appreciated instead of several clicks or click-drag to get to the desired state

Sorry, I used the wrong word. I had an iPhone-style switch in mind which slides when you tap it.

I think, bizarrely, the control pattern for mute "flows" the opposite way to the control for pause/play. If there's a play icon, and you click it, you expect it to play the video. If there's a pause button, you expect it to pause the video. Going against this pattern, if I see a speaker icon, and I click it, I expect it to transition to a crossed-speaker, and mute the video, and vise versa. That is: the current button state in play/pause reflects the action of the button, while the current button state in volume reflects the state of the button.

I think these conventions are easily solved for video, anyway, because it's obvious when the video is muted or not (hopefully).

> it's obvious when the video is muted or not (hopefully).

It isn’t always obvious to me. Sometimes I can’t tell if a video player is muted vs the system volume being low. There’s also the situation where a video is silent and I don’t know if I’m supposed to be hearing anything.

I think these conventions come from actual players like VHS and walkmans. The play, pause, stop,… where actual buttons and mute was an icon on the status display. Buttons are actions while icons are state. The rare case where there was a mute button, it was toggleable (or have a led on it) and these always reflect the state.

my memory of a Walkman had a wheel for volume but a mute button was not something I'm familiar on this device. see this image for reference:

https://vintomatic.com/wp-content/uploads/2022/11/Vintomatic...

They frequently had a "click" at the end of the volume wheel that would fully mute.

In my experience, that click also acted as power off.

The correct pattern is to use the platform’s native video player because the user is already familiar with how it operates instead of reinventing the wheel with web jank.

It's actually a C++ app related to music visualization and the video player is one for a preview. I agree in principle though, if there were the equivalent of a <video /> tag in ImGui and OpenFrameworks I'd happily use that :)

They probably have a reason why their product is not just a video. They need integration. Going with what the platform thinks should happen, if it even offers such a control, will probably be a UI disaster in its own right.

If you have one button, I think it has to match what people are familiar with, and the major players all show the current state. If you have a volume slider or buttons, the mute button is adjacent to the silent end (bottom or left for me; I don't know whether RTL languages flip volume controls).

How about a slightly larger button that has a bit more complex graphic:

(speaker emitting sound / speaker crossed over). Ie the button has two icons with a slash between them.

One of the icons is in black outline and one is in grey outline. Pressing the button switches between what is black and what is gray.

If speaker emitting sound is black, then sound is on. If crossed speaker is black, then sound is muted.

For muted audio I think a muted speaker icon on a button displayed in clicked/active state would be the most intuitive version.

Aside from that roughly 100% of applications I've been using use the "show current state" approach in this specific case. I don't think I've seen a media player which does it differently.

Radio buttons:

   Microphone Status:
     ( ) Muted
     ( ) Unmuted

Unambigious. Add icons if you like.

This solution is far from compact though, right? If you show it at all times, it takes space and adds clutter. If you hide it behind a menu, it adds extra clicks.

If this was meant (semi)ironically and mainly as a reference to the OP link, then sorry for the earnest response!

No I meant it seriously. It's clear, even if it takes a bit more space. And it's accessible whereas something like color changes on an icon are not.

And very inefficient.

For a one-button option, I think I'd like something like a knob pointing to the current state (like a label saying ON), which when clicked would point to the other state (OFF). Both labels should be visible at all times. I think people may understand knobs. I'm an absolute fan of skeuomorphism but you may be able to design something more abstract (but that's a slippery slope so hopefully not).

The icon should depict a muted speaker and shouldn't change. Then add a LED-like dot to show when the function is active.

Not as unambiguous as it sounds. My keyboard has an led that lights up when the speaker or microphone is muted. But the camera only lights up when it is on. Do we want to show when the function is active, or when the device being controlled is active? I would say the latter is generally better, since it indicates a potential vulnerability / exposure. But then we have to deal with security devices!

The LED should be on when the function is on. The function is whatever the icon depicts.

If the icon is a loudspeaker, then the LED should be on when the audio is on; but if the icon is a microphone with a bar across it, the LED should be on when the mic is off.

I have a button labelled "ASR OFF" in my car. Its LED is on when ASR is off and vice versa. I don't find it confusing.

Another example: my TV has a standby LED. It's off when the TV is on, and on when the TV is sleeping. Again, I find it correct.

Then we need to standardize how we name functions. For example, never talk about a mute function, but just sound on. All function names should indicating turning something on, and never off, or vice-versa.

I absolutely agree with this. Especially with buttons that toggle state, you need to be careful to use the right terminology. But I think we can say “Mute on” and be understood: TVs would often display text like “Mute on” while silencing the volume and the status would disappear when the mute button was pressed again. Likewise, adjusting the volume should turn off mute, and doing so would hide the “Mute on” text. It bothers me when a website tells me a video’s sound is off or “click the tiny mute button to unmute and listen to this,” I’d often instead prefer that the video start playing without sound to get my attention but then stop and wait for me to interact with it. And if I interact, just throw up a countdown timer that says “Video starting (with audio) in 10 seconds…” and toss in a cancel button. Alternatively, forget the unmute toggle and show a giant volume slider. Let me drag the volume to the level I want it to be at and I won’t be surprised if it’s suddenly unmuted and too loud. We really need to work on these conventions a bit more…

I always appreciated Mackie's Rude Solo Light. It was very difficult to not realize it was enabled.

This nails it! It’s essentially equivalent to a Boolean property, muted = true|false.

current state - this easily generalizes to settings with multiple options.

This is the correct pattern. It's usually a good idea to also add a tooltip that clarifies the action (although that doesn't help on mobile).

Don't use icons then, use words. Words like "video is muted" or "mute the video".

Long ago, Apple's HI group had a saying: "a word is worth a thousand pictures".

I strongly disagree.

In a conferencing app, for example, "mute" could mean switch audio off, or just the mic, or both.

And consider that a word, even "mute", might not have an equivalent in every languages.

words take up precious real estate and makes the UI look congested/cluttered and is exactly the opposite of the desired clean look. if things are more ambiguous, it is just something for the user to come to terms with. --Jony Ive in some unwritten extract of thoughts

wow, what a great slogan. It seems so far removed from modern, minimalist-flat-icon-obsessed design which Apple is now the poster child for.

Canon does this everywhere in their camera UIs, e.g a button with "(eye-tracking icon) ENABLE". Gotta open up the full settings UI to remember which way it works. IIRC, they actually show the current state (ENABLE = ENABLED), not the action that will be taken when you tap the button, but I might be misremembering... again.

I think this is because the English concept doesn't map into Japanese. I've seen plenty of times where shops would have signs/labels saying OPEN and… CLOSE.

The toggle is supposed to convey immediateness, like a light switch turning on bluetooth is immediate.

A checkbox is like filling a form, it requires submission for the action to take place.

The real reason is that in contexts like the Settings app, where toggleable items are mixed with other items, checkboxes on the left would take too much space on mobile (especially on the early small-screen iPhones), because it would require the left margin to be increased for all items. Checkboxes on the right are awkward though, and thus were replaced by the toggle switches. The immediateness argument is just a convenient excuse. Immediately-effective checkboxes weren't uncommon on desktop before. In addition, there is "previous art" in the form of boolean-toggle menu items that are immediately effective and show a checkmark when active.

This assumption breaks if you use macOS. Windows uses (or used to use) Apply button in its settings. Macintosh OSes were reactive from the start. Which means that checkboxes have immediate-ness on Macs.

That was true in the 90’s when you’d post a whole page but these days the individual checkboxes are more likely to have event handlers that transmit state to the server immediately.

> That was true in the 90’s when you’d post a whole page

I'd say that to the extent that is true, it was equally true for radio buttons in the 90s.

These days I find myself scrolling around pages to look for submit/save/apply buttons to determine whether checkboxes and radio buttons are intended to have immediate effects or have to be submitted to be applied, because there really seems to be a lack of consensus on what these elements mean in those terms.

The parent comment is talking about how the colors are often set on a toggle.

That the user never knows if the toggle is in the on or off position.

Your parent is talking about their parent's second paragraph, about toggles in settings.

That is what I am talking about as well

>When the icon is white, is it on? Is it off?

They reinforce this with another example of ambiguity.

The user can’t be suggested to take any actions if they can’t figure out what the default settings are.

lstamour talked about two things, the proliferation of toggles, and the unclear toggle buttons.

ncruces replied clarifying the former, that the toggles proliferate because they convey immediateness. They didn't say anything about the "unclear toggle button" point.

Your comment, then, aimed to correct ncruces' comment, clarifying that lstamour was talking about unclear toggles, when ncruces was talking about the other point in lstamour's comment, and thus was already correct.

> Likewise I thought the article’s punchline was going to be the increasing use of on-off toggles instead of checkboxes.

That's the second paragraph. This would be those left/right toggles that became popularized with iOS on the original iPhone (since you could physically slide them with your finger). These also do have color insanity associated, though.

The third paragraph used "toggle" in a more general sense.

To be fair, the comment has a lot going on.

White/black "indicators" of toggles are horrid. A lot of phone and meeting apps do this and it's horrible.

As for mute, I think it's pretty objective at this point that an icon based toggle should show the current state, not the state that tapping on the icon will produce. That's because the icon is serving two jobs: Convey the state and let the user change it. When a developer gets this wrong and shows a crossed out speaker while audio is playing, that's just frustrating.

> As for mute, I think it's pretty objective at this point that an icon based toggle should show the current state,

I can't see this holding up as the primary UI rule. And exceptions only for things like mute toggles are seldom a good thing in interfaces where predictability should be the king. It breaks down on play/pause toggles. The answer in my opinion is to separate the concern of the action and the state and distinctly show both at the same time.

That's true, but I just can't live in a world where mute goes the opposite way. I'm not aware of a major media player that doesn't cross out the mute when audio is muted (assuming it uses a crossed out icon at all).

I also can't live in a world where play/pause is opposite to the way it is now: play icon should mean the media is paused, pause icon should mean the media is playing, as you suggest.

If we constrain ourselves to only having two buttons (one play/pause, one mute/unmute), and only differentiating them by the shown icon, then I'm afraid it just has to go with the convention. They are inconsistent with each other, but intuitiveness beats consistency I guess.

> The answer in my opinion is to separate the concern of the action and the state and distinctly show both at the same time.

I don't think this is practical, especially on mobile. There is a need for these UIs to be concise, and even if there is enough space, each visual element comes at a cognitive premium to the user.

> each visual element comes at a cognitive premium to the user.

As someone who studied two years of cognitive sciences as part of my degree, this is not necessarily true. Lack of information can often lead to even more cognitive load as the user then has to imagine virtual scenarios, an cognitive process which is linear. Visual processing however is largely parallel, faster and less consuming, as we have evolved to live in a visually complex and noisy environment.

Fair, but I think there's a middle ground here, obviously an entire screen of buttons on top of a video occludes the content that you want to watch. Even if our visual cortex can handle it, I don't think its desirable if it can be avoided.

Of course, admittedly if all you have is a play button and a mute button (or some other very simple player) it probably doesn't matter much.

I think Twitch's UI is a good example of where the clutter goes too far. It's loaded with tons of distracting bits and bobs. Makes sense for their business model (most of these relate to how you can spend money on the platform), but from a user perspective it's unpleasant.

Discord is the same. They target kids, and kids love things that repel adults, like confusing user interfaces.

The mute on the touchbar on my MacBook Pro has a slash when unmuted (and also when muted).

It looks like this unmuted: https://discussions.apple.com/content/attachment/e909bffc-81...

and this muted: https://discussions.apple.com/content/attachment/e3e9c230-e4...

I believe the reason it always has the slash is to distinguish it from the "change volume" button (which, when pressed, pops up a volume slider). But it's still confusing.

Traditionally, the play / pause button is labeled with both icons. It has no need to display state, because the state of playing or being paused is obvious to the user. That button would be telling you the same thing you see by watching your video.

But a mute indicator isn't telling you how other people appear to you. (That would be "deafen".) It's telling you how you appear to other people, which you have no other way of knowing.

> I think it's pretty objective at this point that an icon based toggle should show the current state, not the state that tapping on the icon will produce.

What about a play button? On YouTube, or any music app, the button will show the Play symbol when the media is paused, and the Pause symbol when the media is playing.

I’m ashamed I never noticed this until you pointed it out. Standards can be broken insidiously, and it’s disappointing that a company that cared about consistent UI enough to put out the HIG. Having typed that, I read the HIG on toggles and realized that those items in iOS aren’t checkboxes. A checkbox turns something on or off. The “round checkboxes” used in iOS are to select multiple items for further action. I don’t know what those are, or if/where they’re covered in the HIG.

https://developer.apple.com/design/human-interface-guideline...

Ha! That‘s a surprise to me, I never noticed.

So, checking out Apple‘s first party apps it seems that checkboxes are either solid color round circles (just the outline when unchecked) with a checkmark in the middle (for multi selections in lists) or just toggles (typically in settings).

Those round checkboxes I could only find being used for list selections (even when the list is horizontal, e.g. when sharing a photo). Toggles for settings.

Radiobuttons seem to always come with one element already selected. I couldn’t find an instance of an empty list where you select one element. In those cases (e.g. when picking your WiFi network) they are just a solitary checkmark on the left without the circle.

It‘s internally consistent (as I assume visionOS is, too) and the checkbox design in visionOS is actually closer to iOS than macOS. I assume that‘s the origin with quite some history behind it. Nearly two decades.

I think the more exact statement would be that as far as iOS is concerned the checkbox already was dead for nearly two decades.

As far as UI conventions go I‘m not too worried. What worries me a bit more that this much more clearly frames visionOS (as well as running iPad apps) as a iOS descendant when this might be the platform with the space to be more clearly in the tradition of the Mac.

> Radiobuttons seem to always come with one element already selected.

This Apple behaviour follows the HTML spec:

> At all times, exactly one of the radio buttons in a set is checked. If none of the <INPUT> elements of a set of radio buttons specifies `CHECKED', then the user agent must check the first radio button of the set initially.

https://www.w3.org/TR/html401/interact/forms.html#radio

The current standard says something else:

> If none of the radio buttons in a radio button group are checked, then they will all be initially unchecked in the interface, until such time as one of them is checked (either by the user or by script).

That behaviour makes more sense for the Web, so that the user is required to make an explicit choice, and I'm not sure if browsers ever cared about this little part of the standard. When interacting with OS components, it makes sense that there's some default or already configured value.

https://html.spec.whatwg.org/multipage/input.html#radio-butt...

Huh, that's odd that it got changed. I can't think of any valid case where [no option] checked is part of a set of radio buttons. The user must be presented by a default, their entire reason for existing as is that one of them is checked all of the time.

Microsoft's Windows guidelines implicitly says that one option must always be checked: https://learn.microsoft.com/en-gb/windows/win32/uxguide/ctrl...

> If none of the options is a valid choice, add another option to reflect this choice, such as None or Does not apply.

Surveys are a valid use case for radio buttons that come unchecked by default.

You do not want to influence people by presenting them with a default (already checked) choice. (You also typically want to randomize the order, at least when there is no inherent order to the options, e.g. when you are asking about frequency.)

Surveys are also the place where that distinction between single choice (radio buttons) and multiple choice (checkboxes) becomes most apparent because surveys tend to liberally mix the two, so any additional UI signposts you can use to help people filling out the survey are helpful. (The typical recommendation for multiple choice is to still explicitly call out in text that multiple options can be checked.)

Surveys sometimes also have the absolutely wild combined list with checkboxes and – typically as the fixed last option even if you randomize the rest of the options – a radio button (e.g. “None of the above”) that automatically unchecks all other options (and is unchecks itself if any other option is picked).

I don’t think this exists in any spec anywhere but is the most normal thing in the world in most survey software.

I‘m always very precise with whether I use checkboxes or radio buttons when designing surveys.

> I can't think of any valid case where [no option] checked is part of a set of radio buttons. The user must be presented by a default

In a political vote, wouldn't that be untolerable bias?

I would never use a group of radio buttons in such a case, would you?

But if hard pressed and not allowed to design a better UI I would do the following options with radio buttons:

( * ) blank vote

( ) Option A (potentially in random order vs other non-blank options)

( ) Option B (potentially in random order vs other non-blank options)

( ) Option ... n

Why would you not use radio buttons? And what pattern would you use instead? I don’t get it …

Radio buttons are the correct metaphor for picking one option among a list of options. Why use something else? What use interface element do you think exists that works for this kind of interaction?

I’m honestly confused why you think radio buttons are the wrong type of interface element for this interaction. What‘s the reasoning as to why this seems so obvious to you? I’m honestly just trying to understand you.

Because voting is a multi-step process often involving more than one action. I have experienced all the below votes at governmental level, they are not hypothetical to me:

Sometimes the voter has the ability to add arbitrary options to the ballot.

Sometimes multiple values are allowed.

Sometimes there are positional votings.

Sometimes there is ranked-choice.

Sometimes you do not even want to submit the vote.

Looking only at "these are the options available, choose one and only one" is not a valid strategy for reaching the conclusion on what UI idiom to use.

I protest against the default assumption that radio buttons (no matter how much I like them) should be the default go-to for voting interfaces because of the context of voting is too complex.

That is such a weird perspective not at all relevant to this discussion.

Obviously all the examples you named are not a good fit for radio buttons. Except maybe the last one where you can just add an “invalid vote“ radio button choice.

But that doesn’t mean that for a fairly standard “pick one” vote radio buttons aren’t a good choice! You don’t have to be consistent within the concept of voting, you just have to be consistent for the one relevant use case!

> iOS has had round checkboxes since forever?

but iOS hasn't been around forever. In the spirit of TFA, iOS marks the start of the Vandals climbing over the gates and sacking what had been to melt it all down and make a soup of melty things.

I also absolutely hate switches in almost all contexts. In some applications it can make sense, like the UI that controls your WiFi or something.

The reason why a light switch is so effective is because we can see an immediate response/impact on our action, the direction that the toggle points in is actually irrelevant, because either the lights are on or off, and toggling the switch changes that state, and I can verify with my eyes. Usually it's safe to toggle the switch back and forth until the desired state is achieved.

In software that's not always possible, and often changing the state has destructive results. So you can't experiment.

And then you get the abominations that bring in double negatives, and things that use switches to control something more complex than a simple boolean state.

"Disable the nuclear missile warning test = ON/OFF" - like what the hell does this even mean, and how can the user be expected to understand what the right option is without trying first.

I find toggles very confusing. Is it showing the current state, or what happens when I toggle the state?

This doesn't need to be the case, though depending on context extra design elements (colour, descriptive text, …) may be needed to make the interpretation truly unambiguous.

Sometimes (advert stalking preferences being the key example) the confusion is very deliberately not dealt with, and furthermore on occasion extra steps are actively taken to ensure the confusion.

I've never seen toggles show "what happens", they're mimicking the real-life toggle. Accent color means "I'm active"

unless you're on an email newsletter subscription settings page, in that case beware

That reminds me of how every other time I silence/unsilence my iPhone, I stare at the "Silence activated" / "Silence deactivated" and work out in my head if it means the phone will make noise or not. Despite doing it thousands of times.

I suppose "Sound on" vs "Sound off" would be better because in the moment I'm thinking of noise and sound, so silence is the inverse of that and kinda forms a double negative situation. "Not-noise mode activated / not activated".

Toggle buttons are hard! I tried making some for a game I made once but ended up just using text because half the people thought it meant the opposite of what it did

So why not use a check box?

Re-inventing the wheel I guess

As a non iOS user, I always get thrown by the horizontal slider toggles. I can never tell by looking at one if it is on or off. And sometimes on touch screens I try to slide them sideways and it doesn't work.

Tabs in Gedit are the same. Whenever I have two text files open, I always understand the tab bar wrong: the item I read as active is inactive and vice-versa. All becuase they doing follow the traditional tab design and use some sort of pills instead.

Yes absolutely this —

> my fav pet peeve remains the unclear toggle button. When the icon is white, is it on? Is it off? Does the line through the microphone mean it’s muted? Or that it mutes when tapped? No one knows, tap it a few more times to find out…

There’s no UX consideration just design by committee, looking at static renders of the “design language”

On iOS the toggles are off left, and shown as dim grey. They turn green when you shove them to the right into the on position. That's about as much as my brain can process.

In many other environments these clues are more subtle or completely absent and I never know which is which.

I don't necessarily wish my check-box back, because I think a slider is easier to handle on touch devices[1], but it should be done in a way that indicates the status clearly. Apple's use of color is also not perfect, but at least they did not fall into the trap of using red and green. Light grey and vibrant green should be distinguishable for most people with color deficiencies even.

[1] At least when implemented properly. I am looking at you Ninebot. Your huge on/off slider only let's me turn off my scooter when the stars are aligned right. I don't even bother anymore and just use the button on the scooter.

> because I think a slider is easier to handle on touch devices

I guess because the toggle has more real estate for you to tap? If so, then couldn't you just make the checkbox bigger and get the same ergonomics?

The must microphone is a great example. I'm often finding it hard to find out whether that type of input means "change state to this" or "this is the state".

Most confusing is when the text changes along with the checkbox, I just go from one unknown state to another.

> Likewise I thought the article’s punchline was going to be the increasing use of on-off toggles instead of checkboxes

It kind of was. The last line of the article is “Kids these days will just use a toggle anyway”

Yes, but it took awhile. :) Also, I feel like the era when checkboxes were actually filled squares or Xs within square braces were less “checkboxy” in that they filled a box but were not “checkmark” shaped. It’s arguable they were toggles already, just data-constrained design variations of them.

An app I use regularly and have introduced numerous people to uses a small toggle slider next to text that reads "Yes, [enable this feature]". Both I and literally every person I have introduced the app to have made the mistake of assuming that the "Yes" text described the current state. What's worse is that the "on" state of the toggle is just slightly more activated-looking than the "off" state. You could hardly design it worse on purpose.

>>>"...increasing use of on-off toggles instead of checkboxes"

One of the most egregiously angering thing to me is toggles that self un-toggle:

"Disconnecting Bluetooth Until Tomorrow"

WHAT?

I literally just commanded the device to turn something off which required me to pick it up, unlock it with a biometric identification, navigate to the settings containing the option I want to control with my physical hands, look at the screen, read the results for the object I want. Make the decision to turn a thing off. Do so by physically touching the device and adjusting the setting - not the Device says

"Oh you want that off? More than for just a little bit? Well, I'll have you know that we use your Bluetooth radio for a lot of our data tracking systems, so its important to us that its on - so we've coded your device's operating system to only allow you to turn off your Bluetooth radio temporarily so you feel like you're in control of it. Why? Because Fuck You Thats Why. Now go back to browsing reddit"

I find that kind of "feature" frustrating as well, but I'm pretty certain that the reason it's there is that otherwise they get a constant deluge of support requests from people who forgot they turned it off.

I fully believe you and I are both correct. Yours is so "Benevelant Big Brother", mine is the 'Sinister Big Brother' <- Evil twin.

If only Apple had the resources to create and enforce a UI that would make disabled Bluetooth obvious. /s

I've only seen round checkboxes used in the context of selecting multiple things in a list of indeterminate size, like emails in your inbox, photos in your gallery, etc.

In my mind this is a slightly different application to the classic "form" that you fill out with data and options before submitting.

Google Mail and Google Photos on Android also have round checkboxes.

Yeah Gmail immediately came to mind for me. It feels natural tbh

I could swear Discord inverted its mic button on vs off convention sometime last year.

Of course the entire point of the article is whining about the web and web developers.

The articles punchline IS the use of toggle buttons?! Or have I misunderstood you?

I was using punchline to actually mean “point”, as in: I assumed the article would show some examples of toggle buttons, but the _point_ of the article was whether the checkboxes were round or square in shape.

Yes, literally, at the very end there is a punchline on toggles. But it’s more for the laughs - a literal punchline - it doesn’t change the focus of the article.

> Kids these days will use a toggle anyway.

From the end of the article

Reply on news.ycombinator.com