There are two conflicting schools of thought that I suspect will never reconcile.
the people who think the button should show what state it is in.
and the people who think the button should show what state it will change to when activated.
the people who think the button should show what state it is in.
and the people who think the button should show what state it will change to when activated.
Should this show the state or the action?
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".
"Flubber enabled" [toggle ON]
"Flubber disabled" [toggle OFF]
The toggle being off means it looks like "Flubber disabled: off" or "Flubber disabled: no" but it means "Flubber disabled: yes"
Flubber disabled [ ] <-- Does that mean that flubber is not disabled ?
Never touch the label, and never tell state outside of the checkbox:
Flubber [X] <-- Clearly, flubber is enabled.
Flubber [ ] <-- Obviously, there's no flubber.
Enable Flubber [X]
But not when labeled
Flubber Enabled [X]?
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.
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.
"UnFlubberize:disabled [__O] enabled"
The ARIA guidelines for switches even have a big warning about not doing this[1].
On a similar note, I find it hard when I don't know if I need to save or submit.
However when I make textual change and there's no save button I'm still confused.
There's no standard how to indicate imediate change in textbox.
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.
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.
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.
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.
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.
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.
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.
Fnurbification disabled
O
|
Fnurbification enabled
Fnurbification enabled
|
O
Fnurbification disabled
This really depends on the part of the world you are living in.
When I was living in Central Europe the light switches were on when they were in the up position.
Edit: Even all my Canadian switches are like this. Up is 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.
Off: https://media.istockphoto.com/photos/light-switch-in-off-pos...
Also off: https://upload.wikimedia.org/wikipedia/commons/thumb/6/65/Ro...
Unless you mean this kind that offer either way: https://m.media-amazon.com/images/I/71BTb1oUUYS.jpg
(B) The standard three way* switch would like a word.
* Which actually means two switches (or more).
FNURB
NORM c- ALTN
FNURB
[ ] < normally blank
[ ] < shows ALTN when selected> 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".
It says what it is, and the toggle says if it's on or off.
The toggle is just a visual, it can be tapped just like a checkbox.
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.
Non-default state should also be indicated
With toggles, I'd almost rather see them aligned center with explicit state description to either side.