1)I'm going to give you an easy one to start. You see a toggle switch. It is set to on (probably - the little colour bar in the switch is coloured in).
It is labeled "Disable fnurbification".
Okay now what? Does "on" mean I'm going to be fnurbified? Does switching the switch disable the fnurbification so I actually have to switch it to "off"? No that's crazy. "on" means "disabled", cognative dissonance aside.
2) You see a toggle switch. It is set to on like before. It is labeled "Disable fnurbification".
We learned before that "on" meant "disabled", but that filled us with a vague sense of unease. For whatever reason we try toggling the switch. The text changes to just "Fnurbification"
Okay really now what? Is my fnurbification on? You try flicking the switch back. The colour fills in and the label changes to "Disable fnurbification" again. Okay what are we supposed to do?
What's happened is the designer has read a post on medium about accessibility and that screen readers don't read out the colour of the filled in part of a toggle switch, and has decided to help by changing the label when the state of the switch changes.
The problem is now the label could either be describing the current state or be describing what happens when you flip the switch. And there's really no way of knowing. I've seen this very often with the UX for boolean selectors where they use things like buttons rather than toggle switches. Does pressing the button do the thing it says on the label or does the label describe where we are now and pressing the button will reverse that? No way to be sure.
Postscript: Notice that whatever you decide is correct in the second case could change what you would do in the first case if the first type of selector is one that would change label when you toggle it.
This UX headache turns into an evil dark pattern real quick when it’s combined with privacy toggles that are conveniently never defaulted to the way you would want them.
The less cynical take is that you only ever interact with privacy controls when they’re wrong, and the subset of those which are confusing are the most salient.
Just the other day I've encountered a cookie modal, where the enabled option was grayed out and when disabled it was colored. Only noticed this because the required cookies toggle was obviously on (though gray in color). For someone in a hurry (like we are all when dismissing those modals), you would expect to gray those out, which would actually make you opt-in to all those advertising cookies. Talk about dark patterns.
> Just the other day I've encountered a cookie modal, where the enabled option was grayed out and when disabled it was colored. Only noticed this because the required cookies toggle was obviously on (though gray in color). For someone in a hurry (like we are all when dismissing those modals), you would expect to gray those out, which would actually make you opt-in to all those advertising cookies. Talk about dark patterns.
I realized the same pattern but in reverse in my phone provider's app. When you're making a payment with your credit/debit card, there is a toggle that you can turn on for them to tokenize your card. By default, the toggle is to the left side and it's colored light blue. When you toggle it to the right it become gray. I believe they have done it on purpose to confuse prople who don't want their card tokenized.
I've previously assumed that the choice there is either:
a) don't save CC info at all
b) save CC info in tokenized form (whatever that means)
And since I never save CC info on websites (only in the phone wallet feature) I've always rejected these "tokenized" prompts. But it seems I need to research this thing more next time.
> I've previously assumed that the choice there is either:
> a) don't save CC info at all
> b) save CC info in tokenized form (whatever that means)
> And since I never save CC info on websites (only in the phone wallet feature) I've always rejected these "tokenized" prompts. But it seems I need to research this thing more next time.
Tokenization means that the payment processor saves your cc information for "easier" use when you make purchases/pay bills in the future. The seller/service provider can of course use that token to charge you anytime they want. I hope this helps with understanding how it works(and why I am hesitant to allow tokenization of my cards).
Also curious. The only thing I can imagine is wanting to call customer service and have them say “you paid your last bill with the CC ending in 1234” and knowing which of your card that is? Seems like a stretch.
> the enabled option was grayed out and when disabled it was colored
In the old, default browser UI, buttons had black labels when enabled, and grey ones when disabled.
Then web designers started making button widgets that looked "cooler" than button elements. Then they realized that they could use the new "buttons" to make indicators as well; so they repurposed the enabled/disabled idiom to mean instead "on/off" or "yes/no". So now the idiom is ambiguous.
If you want a dual-purpose button/indicator, emulate those old keyboards that had an on/off neon in the CAPS-lock key. I prefer a separate indicator, but at least those old CAPS-locks were ergonomically unambiguous.
If I understand, bad (against user interest) defaults can be called a dark pattern, but shouldn't purposely misleading state indication also deserve the direct label: deceptive practice?
> privacy toggles that are conveniently never defaulted to the way you would want them
Or conveniently defaulted the way you want them, but with wording and other visual clues twisted in such a way to make you question that and maybe accidentally opt in.
I've been winding down my Facebook over the past year or so. Unliking things, unfriending friends, and deleting posts. If you try to unfollow a page on Facebook, the "Unfollow this page" button is turned off, and you must turn it on/check the button (which changes it from gray to blue) to UNfollow the page. One of the many reasons I've been winding down my Facebook.
Why? It feels better on the right, imo. It’s more natural, I see what it is, and then decide at the end to select or deselect. If it’s on the left, I now have to return to the beginning of the word. It’s not very natural.
More broadly, this is a consequence of English being a LTR language. The eye scans from left to right when reading these languages, so one naturally wants to place important visual symbols (bullets, controls, etc.) firstmost where they'll offer maximum contextual impact for the proceeding information.
The fixed-width nature of these elements is more of an afterthought that emerges because neat grids make information easier to parse and are generally considered to be visually pleasing. In RTL languages, the movement of the eye is mirrored, so the natural position of these elements also gets mirrored to the right-hand side. Of course, the fixed-width nature does not change because the instinct to craft neat grids exists regardless of directionality.
Recently, however, we have begun to see certain touch-based interfaces adopt right-aligned controls specifically, even in LTR configurations. This evolved to compensate for the fact that most people are right-handed and generally cannot reach across the width of a modern touchscreen one-handed. It's effectively a concession to accessibility and is best implemented as a toggleable feature to avoid disadvantaging left-handed users.
The checkbox is closer to the text on the left. If it's on the right, there will be a gap that varies with the length of the longest item, making it harder to line up with its associated item.
But but but but skeumorphism is unfashionable and apple said it wasn't good anymore!!!!
You are supposed to design your UI as if it was made in ten minutes by a lazy high schooler making a powerpoint with all the defaults and just bulleted text on a blank background.
This can lead to additional problems. Say Fnurbification is a setting in code wrapped in an if block. Great, on or off is easy to follow. Now say the Disable Fnurbification is what is actually in code. Now, when someone has a problem with Fnurbification, you have to map state back and see that the inverse was coded for the IU and follow that down the stack. Don't even get me started on defaults. There is no good/easy answer here.
There is an easy answer: "Disable Fnurbification" is not what should be in the code. Present the right interface to the user, and fix the code when practical. Presenting something backwards to the user only makes it harder to fix later.
I deal with hundreds of these types of selectors from some inherited code. When a disable changes 2 lines of code to wrap functionality in an if block v adding many scattered if blocks to accommodate the enable case, I'll probably go with the low code solution. If I can easily accommodate enables then sure but it's just not always that easy.
This gets messiest imo when it's a toggleable button like thing, or an unclear link. Buttons seem good candidates for "trigger an action", checkboxes instead suit "this is the state".
I think checkboxes is 'the state to be if I click save'. I don't generally expect checkbox to change the state instantly if I don't click 'submit' or something similar.
I remembered that some sites use a small spinner on the edge of textarea or something similar to indicate "I am uploading your text to cloud / I am saving your text to disk".
I think it's a good design that tell users your changes are persisted "now" ?
And this can be probably applied to all options that take effects instantly.
Good idea about small save indicator on every change.
Another idea:
When you start typing textarea visually changes style to indicate editing. Once you leave it it changes style back to indicate that this new content is written.
Optionally additionally while editing small X icon might show up and clicking it might cancel the change instead of saving it.
Interesting, I don't look at the same way - which is another reminder to me why good UX design is hard as my own interpretation of something as simple as a checkbox isn't universal.
On a similar note, I find it hard when I don't know if I need to save or submit.
Maybe stop using necessary "preceeding" verbs and actions to indicate state, but use explicit ON or OFF to match the desired result?
It is common in telling someone how to use a UX that they need to "disable" X or Y option, but, again, that is to say that the intended state is on or off.
To me there problem here is understanding if the toggle is displaying a state or action because English is limited. But in the past tense version that is far less confusing because it clearly expresses that this is a state and cannot be an action (i.e. "Would you like to Flubber Enabled?" doesn't work nor does "Would you like to Enabled Flubber?" but "Would you like to Enable Flubber?" does). The "ed" matters as well as the word positions. The reason being is that the second word describes the state of the first which is why you can change it. In your example it is easy to understand with the checkbox but the thread at hand is about how toggle switches' visual appearance is confusing so your example is clearly not obvious (otherwise this thread wouldn't be on the front page). The idea of toggling the label means that there are now two indicators of __state__ that should verify one another and thus reduce confusion.
This is the worst possible solution because you're now showing the state and the action simultaneously, arguably making it less clear about the meaning of the toggle.
The ARIA guidelines for switches even have a big warning about not doing this[1].
I don't really like this as it's not clear to me until I use it that I see it's a changing label. I don't want to have to interact to discover what will happen if I do.
The toggle being off means it looks like "Flubber disabled: off" or "Flubber disabled: no" but it means "Flubber disabled: yes"
Most comments are in favour of the former, but we've been trained by every media player UI to understand that a button with a pause symbol means that the media is currently playing.
It's worth noting that physical media players (VCRs, CD players, Tape players) usually have separate play and pause buttons. The Winamp default skin did also. Most of us were trained to expect that before contemporary media players started showing up.
I think it's also worth noting that it is usually very obvious what state a media player is in, so it makes sense we would have different expectations from that UI vs one where we aren't sure of the current state.
Tape players have it because buttons were used to physically actuate controls of the deck.
It was easier to have "stop" be mechanics to disengage head, "play" to engage head" and "pause" being just on/off switch for the motor than trying to merge play/pause into 1.
> Most of us were trained to expect that before contemporary media players started showing up.
CD players started getting play/pause precisely because they didn't need to. Most VCRs also had digital controls (coz moving mechanisms via push of button would be harder with big tapes and heads) and they also did often have play/pause integrated.
Some opted for copying tape 1:1, some merged play/pause into one button, it certainly wasnt that all of them had separate pause.
> It's worth noting that physical media players (VCRs, CD players, Tape players) usually have separate play and pause buttons.
Anecdotally (in UK&EU) every old tape, CD, or VCR player I ever had combined play and pause on a single button, even devices where there was no screen to show current state it was just the norm that the same button toggles the current state.
Media players should have a "playing" indicator that is separate from the play/pause control. Not just because of the ambiguity between state and action, but also because there is difference between the requested state and the actual state!
A media player can be in the "user wants to play" state and not be playing, because buffering is taking place. This is a very common state, yet all the media players I've seen have an ambiguous or confusing display during this state.
> a pause symbol means that the media is currently playing
Except when it isn't playing. It get confusing/frustrating when dealing with low volume, buggy software like the Iphone Podcasts app or Bluetooth. Then you think, oh, maybe it's in a paused state.
If it's a switch, I don't understand why it can't be represented as a switch:
Fnurbification disabled
O
|
Fnurbification enabled
Of course, UX design metaphors based on actual mechanical devices aren't cool anymore, but a brave enough soul can ignore coolness in favour of functionality.
The UK and many ex-colonies that also maintain plug/outlet switches seem to generally use down for on, while the US/Canada/Central Europe often use up for on.
Especially annoying are the posh toggles, unnecessarily popular in some European countries (e.g. CH) that don’t have any physical indicator of on-off status.
It’s fine for multi-way switches, and probably even better than confounded switches, but as I mentioned they’re unnecessarily common which in this case means that they’re often used (at least in some settings in CH) for single-switch setups as well. For instance, my apartment had around 8-10 push switches of this type, with only 1 that was a three-way switch.
Here in USA, single-gang switches have "on" and "off" embossed on the switch, so the state is shown based on the position (oriented up is on). Multi-gang switches have no embossing.
Sometimes it can even be either way, because there are two switches and toggling one of them toggles the light in any case; they essentially act as a XOR circuit and are most commonly seen in corridors.
The apartment I live in has switches that turn the light on in its down position in some rooms and switches that turn the light of in its up position in other rooms. Fun!
Yeah, I've lived with dual switches my whole life. Hallway in my childhood home, the two entrances to my kitchen now. Also my bathroom switch is left/right. I had no idea "up is on/off" was even a thing until someone referenced it a few years ago (in my 30s).
It depends entirely on how they were mounted/wired and if the person doing it cared. Where I live the inconsistency is real, even inside a single home, though most people seem to not care. In my own home I fixed everything which was in the subjectively wrong position, it was trivial to do.
Yes. An electrician re-wiring my kitchen had three adjacent switches differently up / down when all off. He happily redid them when asked, but clearly himself didn't care about the consistency.
The analogous case being a horizontal circuit laying on a table with the crossbar switch up in the air causing an open circuit & being down closing it.
First, checkboxes and toggles are not buttons, so that's a slightly deceptive way to describe it. If you use "checkbox" instead, it's immediately clear who's right:
> and the people who think the [checkbox/toggle] should show what state it will change to when activated
These people are wrong. The simplest thing should be the default and this adds extra indirection (projecting future state from current state), therefore it's not the simplest, therefore it's wrong.
Unless of course you mean something strange by "activated".
Three, apparently: there are the people (such as me) who think the button should "show" what it does when you click it. It shouldn't indicate anything else (except it's enabled/disabled state, i.e. whether you are allowed to click it). Button text should be constant. If you need an indicator, that should be another widget.
It's very easy to reconcile. If you have to have inverse logic in UI (which is wrong, but designers gonna design despise logic or usability), you can just have "Enable"/"Disable" but use other hint showing the current state, say paint the disabled ones red and enabled ones green .
Bethesda (e.g. Fallout) are masters of the label as current state versus label as next state paradox.
On Fallout 76's "PIP Boy" UI, button tips for things that toggle or rotate settings like "(X) Allow Friends Only" arbitrarily mix states and actions, in the same UI!
That particular option is on the Private World creator and the only way to figure out which it is is to create a world and see who can join. There are many such examples with several buttons/action/states listed where some work one way and others the other. It's so bananas it's almost endearing.
It's very common for developers to make accessibility worse by doing things like this. I have seen things where the two states to a screen reader are something like: "disable foo toggle button pressed" and "enable foo toggle button not pressed". Why not just a checkbox labeled "foo"?
There are many instances where the default is set at enable fnurbifucation with white text on a black background. Disable is shown as black text on a white background. When you change the state the text and background color inverts.
There is no way of knowing for certain what position is on and what is off without assuming that the first displayed state is on.
I believe recently I setup a nest with this issue. There is no way of knowing what is specifically selected unless there are three options. With three exclusive options you can compare to determine what the current state is because two of them will look the same thus must be off.
Ti-89 93... calculator settings can have this issue but some of the options have 3+ states and once you see the schema it's quite easy to deal with.
> Aiming for all options to be "on" or "off" is some pedantic nightmare that makes settings harder to navigate
This probably stems from config files or in-app defaults where a feature is default-on and so the existence of a value means something is disabled. And then some dev comes along and mindlessly transcribes a bunch of boolean flags into a settings menu and here we are.
I think rectangle switch with active light on one end is good. I believe the confused one people talking about is the rounded slide toggle whose body color is used as status (the bolt head left right is equivalent to meaning nothing)
Not sure we are on the same page, the two lines is only for demonstration, the real ui is going to have that one line at a time. And the latter is custom radio button, I think it's up to 5 short name items before consider making it a dropdown.
200%. I find them "cute" so tried to use them in some internal tools with React. And.... I confused myself on this very exact issue you describe so I changed to a regular checkbox.
You're mixing two different concepts. One is how to design a graphical gadget, which is a problem for front-end art work. Another is how a boolean variable should be implemented, a problem for your back-end logic. Computer-engineering ancient wisdom says always use positive logic. If you have a choice, never label a boolean something as 'disable', always 'enable'. Use positive logic, avoid negative logic.
Of course. I’m not saying it’s good I’m describing stuff that I see widely in apps and sites I use.
3) You see a toggle switch. It is labeled “Fnurbification”. It is set to “off”.
You want fnurbification. Do you flip the switch?
As we’ve established in 1 & 2 if you know that flipping the switch won’t change the label then clearly the label describes the thing so you should flip it.
If on the other hand flipping the switch is going to change the label then we’ve established that the label probably describes the current state. Flipping it would probably change the label to something like “Disable Fnurbification” and turn it off. So you should leave it off so fnurbification remains on.
But this is your first time using this app. How do you know whether or not the label is going to change? You could toggle the switch, but what happens if the action of toggling the switch is expensive or safety-critical?
4) Let’s raise the stakes. You see a switch. It is set to off. It says “Nuclear reactor safety protocol”. You want a safe nuclear reactor don’t you? Do you switch on or leave it off?
No, the label should always say what the toggle or checkbox does when it is enabled. If you want to make it extra extra clear (because so many apps have muddied the water by doing it wrong) you should probably put additional small text nearby that changes. Like this:
[ ] Foo
*Foo is disabled*
[X] Foo
*Foo is enabled*
Also you should not have double-negative check boxes ("disable foo").
I'm not a UI designer but I think this is pretty obvious to anyone that has used bad checkboxes (like OP). (I don't think the problem is unique to slide toggles; I've definitely seen similarly bad checkboxes.)
Hmm, I'd like it if that always made sense, but sometimes the default state, with nothing active, is for Foo to be on. So "Disable Foo" is doing something not normally required, or something most people don't want. Sometimes it does make sense that _not_ performing a reduction in Baz is default, and that default is off.
You could probably solve it by renaming a feature to used an antonym, but not everything has an antonym [that people know, or that makes sense].
I’m puzzled why you equate “default state” with “nothing active”. If the default should be that thing the button says is on, then have the button default to being in the active state.
The language even for discussing this is tiring to read…
> Hmm, I'd like it if that always made sense, but sometimes the default state, with nothing active, is for Foo to be on.
Then foo will be checked on by default. That's not a problem.
[X] Send notifications
Is perfectly unambiguous.
What I'd like to see with every option like that is something showing whether it is in default state or not so user can easily glance what was changed from default. "reset to defaults" per page of settings is also appreciated.
The better solution to "is this the default" is to just have some mechanism for indicating whether the value has been changed, and a way to reset it to its default.
This is quite common in UIs. It also has the benefit of working for all controls, not just checkboxes.
For sure, there are ways to not have it ambiguous.
That said, people use this UX pattern all over the place, and sometimes I'm sure on purpose. Istr one iteration of facebook's data privacy and sharing dialogue used to have it. There was a switch called something like "Enable privacy protection" and you see it set to "off". So you switch it "on" and the label changes to "Disable privacy protection". So which one gives me the privacy protection?
I find it very hard to believe that the ambiguity isn't deliberate.
I imagine at least 90% of people, upon seeing an option to enable privacy protection, would enable it. But by making the option confusing, you'll end up with people that want it on and inadvertently turn it off.
It certainly wouldn't be Facebook's only dark pattern.
This is literally in Brave's settings: you see the "Block sites from autoplaying videos" and next to it, a switch that's turned off. And you think "Okay then, autoplay blocking must be off", but nope! Makes me a little less sane every time I use it, this UI.
I honestly always test this with with video chat Mute buttons. I feel like it is only recently that UX designers designed a way to show that you are muted that is different from the Mute switch, which is a complete guess as to what state you are in.
That's like this function in this legacy code I am working on has an alert function for creating the bootstrap alerts with options like "dismissible_off" and "autohide_off" instead of just "dismissible" and "autohide", also they're just integer values (0 or 1) instead of boolean. I have to think about it way too much when I use it wondering if I have the setting correct.
For me, it’s quite clear in the reading, though. You have to read as it presented (label + switch).
For example:
vSync ==> [On]
vSync [Off] <==
I honestly can’t think to read it otherwise.
For the negative labeling, it’s of course unfortunate. But it’s in general the case for all negation. Thus, I try to avoid using negation when ever possible.
Good design is always hard to find, my personal solution would be a drop-down with the title: "fnurbification" and the options "Enabled" and "Disabled". More systems ought to be built like this, ambiguity is a black check for later economic loss.
For the second case the play-pause button has the same problem: what does the 'play' button mean? That it's currently playing, or that when you click it, it will play? Same with paused. Is it paused now or does it pause when I click it?
That one wouldn't be confusing if people didn't attempt to save space by making it one button.
The tape recorders, vcr and dvd players I've seen mostly have them on two different buttons: pause which stops the current recording or playback and separate play and record buttons. There is nothing confusing to PLAY / RECORD / STOP.
Although I guess sometimes you have a joint pause play button especially on tv remotes and those ARE confusing.
ETA: apparently HN doesn't like the pause button emoji so i had to use text.
Consider the UI design from the perspective of someone whose goal is to make it less obvious for how the user can disable cookies, sorry, fnurbification, while still technically providing the user with the option to do so.
Another version of hell is a checkbox being replaced by 2 radio boxes. But on page load none is selected, so UX changed 2-state piece for 3-state one (a small win is if they are at least grouped together so only 1 can be selected).
Thank you for putting this into words! It gets worse when it is for handling destructive actions. And it is not clear which way it is or it isn't destroying things. Actual nightmare material.
1)I'm going to give you an easy one to start. You see a toggle switch. It is set to on (probably - the little colour bar in the switch is coloured in).
It is labeled "Disable fnurbification".
Okay now what? Does "on" mean I'm going to be fnurbified? Does switching the switch disable the fnurbification so I actually have to switch it to "off"? No that's crazy. "on" means "disabled", cognative dissonance aside.
2) You see a toggle switch. It is set to on like before. It is labeled "Disable fnurbification".
We learned before that "on" meant "disabled", but that filled us with a vague sense of unease. For whatever reason we try toggling the switch. The text changes to just "Fnurbification"
Okay really now what? Is my fnurbification on? You try flicking the switch back. The colour fills in and the label changes to "Disable fnurbification" again. Okay what are we supposed to do?
What's happened is the designer has read a post on medium about accessibility and that screen readers don't read out the colour of the filled in part of a toggle switch, and has decided to help by changing the label when the state of the switch changes.
The problem is now the label could either be describing the current state or be describing what happens when you flip the switch. And there's really no way of knowing. I've seen this very often with the UX for boolean selectors where they use things like buttons rather than toggle switches. Does pressing the button do the thing it says on the label or does the label describe where we are now and pressing the button will reverse that? No way to be sure.
Postscript: Notice that whatever you decide is correct in the second case could change what you would do in the first case if the first type of selector is one that would change label when you toggle it.