[HN Gopher] Should toggle button show its current state or the s...
___________________________________________________________________
Should toggle button show its current state or the state to which
it'll change? (2010)
Author : wscourge
Score : 349 points
Date : 2024-02-12 08:13 UTC (14 hours ago)
(HTM) web link (ux.stackexchange.com)
(TXT) w3m dump (ux.stackexchange.com)
| BLKNSLVR wrote:
| I agree with the conclusion, but would like to add that it should
| be obvious what the current state is, and what the state will
| change to when the toggle is changed; too often I have to change
| it in order to work out that I didn't need to change it.
|
| The point about play/pause is really interesting because it goes
| against the conclusion. However, it's following physical
| precedent that's well understood. It's also (usually) obvious
| when music or a movie is playing, so the button icon wouldn't
| even need to change for the user to understand what pressing it
| will do. This stands it separately to the toggle question, I
| think.
|
| Back to toggles and UIs, changing the colour of the toggle from
| light grey to slightly lighter grey is unhelpful in the extreme.
| Give me labels. If labels don't fit your motif then get better
| designers.
| Fluorescence wrote:
| > However, it's following physical precedent that's well
| understood
|
| The physical precedent would be to show the behaviour as the
| button image (play) and then the depressed/undepressed visual
| state would show if the behaviour was active or not. Software
| designers didn't follow this and invented swapping between the
| play/pause icons causing this new confusion. Not for any user
| friendly reason, more because skeuomorphic 3d buttons went out
| of fashion.
|
| > It's also (usually) obvious
|
| The only virtue of indicating the state at all is for when you
| have a problem. Very common for audio at least (muted sound,
| unplugged headphones, linux audio drivers have become borked
| again... sigh).
|
| I still get that twang of cognitive dissonance when I see
| play/pause buttons and have to think about it and might just
| double toggle it anyway when I've got an issue because I can't
| be 100% sure what a pause button means.
| chatmasta wrote:
| > it should be obvious what the current state is
|
| Yeah, I don't need to know which direction of my light switch
| means "on" (and in fact I don't know), because I can see
| whether the lights are on.
| xamde wrote:
| Unless there is an issue with either the light source or the
| power source. Muted/unmuted is also a pair where unmuted
| often does not equal "we can hear you"
| crazygringo wrote:
| > _Give me labels. If labels don 't fit your motif then get
| better designers._
|
| That's unhelpful and unreasonable, particularly on mobile.
|
| There's no room on Spotify for labels behind every button, for
| instance.
|
| Not if you want room to show the cover art, which I do.
|
| It's not a question about "better designers" -- space
| constraints are real, and sometimes you really need things
| available at a single tap. I don't want shuffle to be buried
| behind a pop-up menu.
| sitzkrieg wrote:
| have you tried to use spotify with a screen reader lately?
| crazygringo wrote:
| Not being vision-impaired, no.
|
| Can you elaborate what your point is, since not having done
| so, I can't begin to guess?
| IggleSniggle wrote:
| I just opened Spotify on my iPhone mini, just to check, and I
| really have to disagree. Spotify has TONS of wasted space.
| Even when you _do_ want to pull up the "extra" menus (which
| is frequent for me, since it seems like that's the only place
| to get to the album for a given song), they practically throw
| the space away. The hamburger menu can only fit _two items_
| on its list of 10, because they waste so much space. I 'm
| sorry, but 10 options can easily all be visible
| simultaneously while still showing the current context of
| that menu (the song).
|
| But that ethos abounds. They hid all the controls, and make
| many of the controls that they do show ambiguous. Am I going
| to be shuffle-play on the queue? Is my queue currently
| autogenerating songs at its end or is it going to stop at the
| end of queue? And long presses / hovers provide zero extra
| information for what the unlabeled buttons mean / do.
|
| I'm pretty satisfied with Spotify UI on the whole, mostly
| because of how easy they make it to toss the currently
| playing song around to different devices and they handle
| shared control well, but I do wish it didn't require three
| taps and a scroll (in a context where it's not even obvious
| that scrolling is possible, because the list is so sparse
| that it doesn't look like there are any more items at the
| end) to get to an album, which is almost always the context
| in which I want to listen to a search result.
| crazygringo wrote:
| > _Spotify has TONS of wasted space._
|
| Not on my iPhone SE screen.
|
| I wouldn't want the buttons or even menu items to be any
| closer together. It's not about information density, it's
| about tap areas.
|
| And I'm tapping the screen on the go, on a bumpy bus, being
| jostled in the subway.
| Waterluvian wrote:
| I can't find it but one of my favourite designs was a switch with
| a "light" beside it that lit up when the state was "on."
|
| The best thing was that it also solved the latency of an async
| operation. You'd click the switch which toggled, and then some
| moment later the light came on. It felt incredibly satisfying and
| gave confidence that yes, this interaction has done something.
| vsnf wrote:
| Without seeing the design in question, I think this still
| demonstrates the ambiguity the post is discussing. Is the icon
| what will happen, or what is currently happening? Is it the
| state, or is it the action? Maybe this particular design was
| unambiguous, but the description of it isn't.
| robinsonb5 wrote:
| If the light is beside the switch (rather than being the
| switch) then I'd say it clearly and unambiguously indicates
| the current state of whatever the switch operates?
|
| (A light also has the advantage of being a skeuomorph - much
| as those are now out of fashion - we all know how to
| interpret indicator lights in the real world.)
| Waterluvian wrote:
| > A light also has the advantage of being a skeuomorph
|
| Unless you're my TV and it's completely backwards for some
| reason.
| Sindisil wrote:
| The standby light on a TV in on for standby and off when
| viewing because a) it could be distracting and annoying
| for the extra LED to be shining while viewing in a
| darkened room, and b) the "on" state should be pretty
| obvious because of the stuff on the screen.
| continuational wrote:
| And also, putting the TV in standby mode is an offense
| punishable by a denial of darkness attack.
| piva00 wrote:
| In electronic music instruments (which derived interfaces
| from electronics lab equipment) it's quite intuitive there's
| a switch with a light on next to it the next state is off and
| the light switches off.
| mapreduce wrote:
| > I can't find it but one of my favourite designs was a switch
| with a "light" beside it that lit up when the state was "on."
|
| So when I revisit that page after a long time and see that the
| light is lit, does it mean that the state is currently ON or
| does it mean that the state will change to ON when I click it?
| How can I tell this by instantly looking at the lit light?
| zmgsabst wrote:
| On is active.
|
| Just like most devices with signal lights -- which have been
| that way for decades. Historically, the lights are signaling
| power being supplied.
| tsimionescu wrote:
| It's also quite common to have a light indicator that goes
| away when the device is turned on. TVs often do this - they
| have an indicator LED to show that they are plugged in, but
| turn that LED off when the screen is turned on, because it
| can be distracted, and is anyway no longer needed.
| 01HNNWZ0MV43FF wrote:
| We should go back to checkboxes. The problem here is having
| the text change and be too clever.
|
| [x] Mute
|
| [ ] Mute
|
| "Oh the X means it's muted"
|
| Windows 95 and probably an older Mac had it all figured out.
| pbhjpbhj wrote:
| "Mute [x]" means that 'mute is false', so I click to make
| it say "Mute []" but instead you take the "x" away, ... so
| is mute no longer false?? If sound isn't working then this
| can be difficult to determine. You can fix it with a
| tooltip and/or familiarity with the system.
|
| Buttons have more affordance too.
| wolverine876 wrote:
| Use an adjective? [ ] Muted [x] Muted
| jodrellblank wrote:
| ... just the one adjective?
| esafak wrote:
| I would not use that word because it is a negative, so it
| makes the user think. "Mic on" and "Mic off" are better.
| Izkata wrote:
| This interface has both a toggle switch and a light indicator
| next to it. Both state and action (ish).
|
| The light is independent of the toggle and shows the current
| state, which is why they mentioned a delay - clicking the
| toggle doesn't immediately change the light indicator next to
| it, clicking the toggle tells the system to turn it on and
| the toggle changes immediately to show desired state, and
| only after the system changes and sends back "I'm on now"
| does the light indicator change.
| unnah wrote:
| That would be a great use for an HDR screen - make the
| "indicator light" extra bright compared to the rest of the
| screen, to make it really obvious that the light is now "on".
| Of course this would only work as long as the user doesn't keep
| their screen too bright to begin with...
| maicro wrote:
| That sounds like an interface feature found on "smart" devices
| - I'm only familiar with TP-Link Kasa switches, but I think I
| remember their app UI having a similar feature where a color
| icon had multiple states, the most "on" of which is "confirmed
| with the switch it turned on".
| laserbeam wrote:
| The link should include a year in parantheses, as it's a 13 year
| old question.
| mapreduce wrote:
| It has answers as recent as 2022 though and it could get more
| answers now that it is on HN. What's the accepted practice for
| putting year in parentheses for links like this that contain
| user-written content that could be much more recent than when
| the link was created?
| mhb wrote:
| > What's the accepted practice
|
| How about (2002-?)
| derekp7 wrote:
| This has been really frustrating to me lately with Microsoft
| Teams. If I'm in their app, the mute button is a microphone with
| a line through it (if mute is activated, i.e. if the mic is off).
| And the icon changes to a microphone without the slash over it to
| indicate that you are no longer muted. Makes sense.
|
| But if I join using the phone app on my phone, the same
| microphone with a line through it (that means you are muted on
| Teams) indicates that you are currently NOT muted, but you can
| use that button to activate mute. After pressing it, the icon is
| still a mic with the line, but it changes to a filled in
| background (reverse video).
|
| Is this because in one case, that button is a "mic on" button,
| but in the other it is a "mute on" button, using the same icon?
| And the button still does an OK job of indicating what state you
| are currently in, as long as you know what the button looks like
| in the opposite state (I always have to toggle the mute button a
| couple times to observe what paradigm the given app is using).
|
| I wonder if this is the price we pay for "flat UI", where
| designers are still figuring out design elements without a real-
| world reference to look back on.
| Kuraj wrote:
| Man... That's one button where you really DON'T want to be
| confused
| m463 wrote:
| I have a hardware button on my headset mic.
|
| Wish there were a hardware button for "accept cookie" or "yes
| send me email offers" dialogs to conquer the not clearness.
| the_other wrote:
| There's a pretty interesting (to me) aspect of the mic
| indicator/controller problem: without direct visual feedback,
| you can't tell what mode your mic is in until _other people_
| respond, or don't. It's a very laggy tool in terms of feedback
| even when it's "on". In fact, you often need to test it two or
| three times to be sure, because your fellow meeting members
| might have frozen, might just be thinking before they respond,
| etc
|
| It's quite different from, say, dark mode, which is pretty
| obvious when toggled on/off.
|
| So the feature benefits a lot from a visual indicator of
| current state regardless what you choose to do for the button.
| It's unsurprising people try to smudge the "state" and
| "control" together, for the mic more than many other controls.
| ambigious7777 wrote:
| I think the solution to this problem would be to have a
| indicator on your profile that say is green when you can
| talk, but red or gone when you can't.
| semi-extrinsic wrote:
| On the flip side, a red light has been the symbol for
| "recording" for several decades. If you do an image search
| for "record button", it is invariably red.
| pavel_lishin wrote:
| Discord is worse. Their buttons for mute-microphone and turn-
| off-camera are inverses of each other.
| causal wrote:
| Yes! So confusing.
| FridgeSeal wrote:
| I hadn't noticed- or struggled with this, but I guess it
| makes sense.
|
| The channels are primarily audio and stream focused, with
| users video being second in priority (makes sense when you
| consider its initial target audience).
|
| So by default mic is active, video is not.
|
| When you mute yourself, you get a "muted" indicator next to
| your name anyway.
| gedy wrote:
| This is a case where I think the indicator (LED in real world)
| should be separate from the button, which label does not have
| to change.
| cobbal wrote:
| Should the LED indicate mute on or mic on? I could see it
| both ways, and so I would also have a hard time trusting this
| UI at first.
| SoftTalker wrote:
| Should be a text label in present tense not (or not only)
| an "LED". I like radio buttons but something equally
| unambiguous could also work. Microphone
| Status [ ] Muted [x] Unmuted
| gedy wrote:
| Amen on radio buttons. It's been really challenging to
| get UX people in my companies to use these for some
| reason.
| terribleperson wrote:
| This takes up a lot more space, but I like how absolutely
| unambiguous it is.
| kqr wrote:
| It should have a label saying "recording" or something to
| that effect. I don't know microphone terminology, maybe
| it's "picking up".
|
| With a label, a light indicator is unambiguous.
| spookie wrote:
| Wholeheartedly agree with your conclusion! Thankfully we're
| seeing a shift to more nuanced skeuomorphism called
| neuomorphism.
| AceyMan wrote:
| When I was just starting in IT (~1999) it was already a joke
| that you could identify where different MSFT teams wrote
| elements of software (say, Outlook) when a common action was
| implemented two different ways (explained by Conway's Law as I
| know now).
| kqr wrote:
| This is an older joke than that. My parents used to say the
| same about switches in cars going the opposite direction for
| activating stuff.
| kortex wrote:
| I think part of this confusion stems from the "default mic on"
| mindset, where "mic active" is assumed to be the default, and
| mute is a deviation from that state. We can trace this pattern
| back to the UI of phone conference systems, back through analog
| phones, back to the time of a literal wire connection between
| parties.
|
| Many/most audio mixers (in the context of live music and
| recording) and their digital brethren use the same pattern - a
| "Mute" button which lights red to indicate that channel is
| silenced. But a few have an ON button above the fader which
| lights to indicate the channel is active.
|
| I think it's about time conference applications rip off the
| bandage and take the "audio off by default" approach. We can
| kinda see it already with UI elements that light up when a
| speaker is talking.
| FridgeSeal wrote:
| I think Discord gets the UX right:
|
| Default state is mic active. There's no slash through the
| mic, when you speak (and it's above the noise cancellation
| threshold) you'll get a green indicator on your name in the
| participant list. Press mute, you get a slash through the mic
| _and_ you get the same indicator, in red, next to your name
| in the participant list. So in many ways they do both.
| citrin_ru wrote:
| With a good UI one should not know what is the default - the
| current state should be clearly indicated. Different
| backgrounds / colour shades is not a clear indication even if
| it looks nice this way.
| empath-nirvana wrote:
| Slack is similarly confusing. I've really never seen a
| conferencing app that does this well.
| beezlewax wrote:
| Zoom has mute or unmute coupled with icons the least silly
| choice I've seen regarding this.
| FridgeSeal wrote:
| Unfortunately, every other UX and technical choice zoom
| makes is so pants on head dumb, that is disqualifies them
| from being taken seriously.
| mvdtnz wrote:
| I have a similar frustration with UI differences between apps
| with Plex. If I look at a TV show season on my phone, episodes
| I've watched have a blue check mark. When I look at the same
| season on my TV, there's no blue check but episodes I haven't
| watched have a yellow triangle. It always makes my brain double
| take when moving between them.
| zamadatix wrote:
| This isn't the case for me, I wonder what's different between
| us as I just tested:
|
| Desktop: slashed = currently muted, plain = currently listening
|
| Phone: slashed = currently muted, plain = currently listening.
|
| I'm using the latest version of Teams for Windows and iPhone
| respectively.
| csydas wrote:
| I don't mean to just blanket shit on Teams, but Teams is just a
| confusing mess of UI choices and UX design that makes no sense
| even within the context of using Teams. The meeting icons are
| of course pretty awful as you cited, but it's even more things
| for me [0]:
|
| - When joining a Teams call, the toggle for video gets
| "selected" so that pressing Return or spacebar (I think one or
| both) will toggle the video on -- noticing that you did this or
| that the video toggle is selected is a matter of chance as it's
| hard to see
|
| - For some bizarre reason Teams has a "start call" shortcut
| that just immediately starts a call without the usual pre-call
| warning items. Joining a meeting from your calendar gives you a
| "pre-meeting room" where you can confirm your mic/video
| settings before joining, but hitting the call shortcut or
| button immediately starts a call
|
| - Sometimes right-click menu loads slowly and additional
| options load after you right-click and move the mouse -- it so
| happens this will usually put the cursor on Pinning the message
| instead of selecting reply or edit
|
| - Regarding Reply/Edit, there is a nice button to jump right to
| both, but for chats one button is showed, for private messages
| another is shown
|
| - All teams messages are linkable; whether or not you right-
| clicked on a link in the message and are copying the link or if
| you're getting a link to the message itself depends on if you
| happen to notice whether you have 2 options on right-click or
| 3+ options
|
| - Copying a linked item (e.g., document, media, picture) will
| have Download or Copy Link button. Copy link for some reason
| puts up a text box across the conversation you're having that
| is dismissible with escape or clicking usual x in box corner --
| other "copy link" options just copy the link normally, other
| ones (like copying channel link) will open a window with the
| link for you to copy
|
| - it is huge pain for me personally that the links you copy
| from Teams are Sharepoint links and pasting it in a browser
| tries to open files in Sharepoint browser, even if Sharepoint
| absolutely cannot display a preview of the file: you sit while
| Sharepoint tries to load a preview, and only after a few
| seconds of Sharepoint trying does it show you a download button
| to get the file (thankfully there are browser extensions like
| Redirector [1] which can be used to create redirects for auto-
| downloads...just Microsoft likes to change the URL for actual
| downloads relatively often so occasionally you need to update
| your redirects..)
|
| Teams is so inconsistent and the UI and UX are equally
| inconsistent -- Teams is also not shy about showing tutorial
| prompts for features just whenever it wants to, no matter how
| long you've been using Teams, sometimes it will just block the
| entire app to highlight some feature it wants to advertise. I
| honestly don't think this or anything has to do with flat UI
| versus other ones, it's just plain lack of attention. maybe
| flat ui's give the impression of a "completed" thing, but I
| just can't see that most of the UI/UX issues for apps like
| Teams are about the aesthetic so much as just a complete lack
| of concern over what actually using the app is like.
|
| 0 - All points here were observed on vanilla teams
| installations on different computers -- maybe my work just has
| weird defaults, but I'm not confident that is the case
|
| 1 - https://github.com/einaregilsson/Redirector
| beezlebroxxxxxx wrote:
| One thing absolutely bizarre with Teams is that if you copy
| and paste the contents of a message most of the time it will
| paste the contents as plain text with a weird timestamped
| wrapper including the senders name. That makes passing a
| filepath or any text super annoying through Teams, most of
| all because it's a seemingly random behaviour --- sometimes
| it does it and sometimes it doesn't.
| csydas wrote:
| Ah I know of this one and yes it's very annoying. But I can
| explain the behavior for you, though it won't be any less
| random-seeming in my experience.
|
| Depending on where you stop your selection with the cursor,
| Teams will think you either only have text selected, or
| you've selected the message itself. The latter is what adds
| the message data to your clipboard, and the border between
| text and message selection is impossible to tell. On MacOS
| I can _barely_ see some text highlighting when I grab the
| message, but it's not always clear.
|
| Edit: additional complaint
|
| Teams is bad with text in general. It inserts so many
| random new lines and hidden characters for cosmetic
| purposes only, and unless you've dealt with the issue
| before, you have no way of knowing why the powershell one-
| liner you copied from teams has a bunch of ????????? at
| random places like code blocks.
| semi-extrinsic wrote:
| It also parses certain C++ and Fortran syntax as
| smileys...
| tomsmeding wrote:
| It had ( _had_!) a multi-line code block option. Now it
| still does, but only in the desktop app, not in the
| browser.
|
| I'm sure they need some native platform APIs to enable
| entering multi-line code blocks.
| xahrepap wrote:
| I agree. Teams is an app of a constant stream of little
| frustrations to me. It's led me to believe that no one who
| develop/designs uses this tool at all internally.
|
| Not just confusing UI, but buggy UI. It's not abnormal for
| people on my team to have "unread" indicators of messages
| they can't get rid of. When you focus the app it does a
| silent refresh and if you start typing too soon the refresh
| finishing will delete what you typed.
|
| Tons of stuff like this. It's infuriating.
| clolege wrote:
| IMO "muting" as a user-facing concept should be done away with.
|
| It's inherently negative, basically meaning "not enabled" and
| as such, `not muted` == `not not enabled`.
|
| Just say whether their mic is on or off, and reflect that with
| the UX elements and writing. Done.
| 6510 wrote:
| I do keep doing it myself but combining multiple things into one
| button is a bad idea. What if the toggle action is just slightly
| delayed? What if the system is frozen, do you press toggle again?
| when do you know your click didn't register? Was freezing not
| annoying enough by it self?
| InCityDreams wrote:
| Are you a British Postmaster?
| knallfrosch wrote:
| The solution that reliably works are lots of switches on the same
| screen. The user extrapolates from a single known state.
|
| Mobile users might be confused about whether Auto-Rotate is on,
| but they do know whether Airplane mode is on.
| maicro wrote:
| Mobile users shouldn't be confused about whether Auto-Rotate is
| on, because Auto-Rotate should always be off. /rant
| mhb wrote:
| Using words often works. But let me chime in with some outrage
| about the icons on an Android tablet - a triangle, circle and
| square with no discoverability and no ability to add text to
| icons on the home screen? WTF?
| freitzkriesler2 wrote:
| Can you clarify what you mean for discoverability?
|
| As for the 2nd one, I would download a different launcher. I
| know Nova lets you do that.
| mhb wrote:
| I mean that it's impossible to discover what will happen when
| I push on them before I do it.
|
| I'll take a look at Nova. Thanks.
| freitzkriesler2 wrote:
| Ah yeah I know what you mean. For what it is worth, they've
| been pushing a new gestures system that supercedes the old
| tool belt buttons. Not sure your tablet has that.
|
| And you probably know now, but just in case Triangle: back
| Circle: close Square: task manager
| lupire wrote:
| It takes 1 day to learn, to avoid years of extra clutter on the
| screen. But an option or a long press tooltip would be nice for
| special cases.
| CamperBob2 wrote:
| Legibility isn't clutter. We moved away from hieroglyphics a
| _long_ time ago because alphanumeric characters are
| objectively better.
| thaumasiotes wrote:
| Hieroglyphics _are_ alphanumeric characters. We moved away
| from them because they are much too detailed to be
| convenient to write.
|
| You could make a case that alphabetic characters are
| "objectively better" than syllabic characters, but you'd
| have to do it on some other basis than "we moved away from
| them a long time ago"; syllabaries are very common today
| and don't cause problems.
| CamperBob2 wrote:
| OK, as I'm not an Egyptologist, let's substitute any
| other language whose orthography is based on icons and
| pictograms. There aren't many, and there's a reason for
| that. They suck.
|
| Certain Asian languages come to mind, something they
| started to regret grievously around the time the
| typewriter was invented.
| thaumasiotes wrote:
| OK, here's an example of some written language with a
| heavy reliance on logograms:
|
| > omg how r u doing that
|
| > lmfao
|
| > c u 2nite
|
| (2nite is especially interesting because the icon is used
| to represent just part of the word!)
|
| This is mostly notable because the formal written system
| didn't allow it, and the logographic forms were
| introduced spontaneously as a result of large numbers of
| people being literate. In other words, they are an
| example of the direction of change pointing _toward_
| logograms, not away from them.
|
| > Certain Asian languages come to mind
|
| Japanese is the only one that might fit this description.
| teddyh wrote:
| Sometimes called "Mystery meat navigation".
| marcosdumay wrote:
| Newer Android uses a hamburger, a square, and an arrow. It's
| not obvious what they are, but the shapes are very mnemonic.
| 1letterunixname wrote:
| Words are terrible and provincial. Symbols are universal and
| clear when used correctly and precisely.
| Izkata wrote:
| If you're using Samsung, they have an app called Good Lock that
| lets you change the icons to pretty much whatever you want.
| Mine are the same as the original Android icons: a curved back
| arrow, a little house, and two overlapped rectangles.
| Definitely agree the defaults are bad though.
| wodenokoto wrote:
| In defense of the ambiguity of digital toggles, I'd like to add
| that this is unsolved on most, if not all, physical light
| switches in homes and offices.
|
| Despite having existed for more than 50 years and most people are
| using multiple toggles a day with its labels, most people are
| unaware of the meaning of power symbol
| (https://en.m.wikipedia.org/wiki/Power_symbol)
| master-lincoln wrote:
| Really? For me this always made intuitive sense reading it as
| one and zero, where zero would be off.
| wodenokoto wrote:
| You probably also work in IT and might even now what binary
| is not to mention what boolean means.
| master-lincoln wrote:
| fair point
| CalRobert wrote:
| It always seemed backwards to me, since a circle should
| represent a closed circuit
| lupire wrote:
| An open circuit would then be a C not a |
| crazygringo wrote:
| Those wouldn't be easily distinguishable though.
| kragen wrote:
| this is backwards from the perspective of digital logic
| circuits
|
| physical light switches toggle between closed-circuit and
| open-circuit, not high and low voltage levels. 'on', where
| current can flow, is a closed circuit; 'off' is an open
| circuit
|
| in digital logic, when there _is_ a correspondence between
| closed /open and high/low, the correspondence is _virtually
| always_ that closed is low and high is open. for example: ttl
| inputs always treat open-circuit as high; the can bus and i2c
| bus "recessive" states (when nobody is transmitting) are
| high; avrs have optional pullup resistors on their gpios but
| no optional pulldowns, so if you want to connect a pushbutton
| or toggle switch to a gpio, you have to connect it between
| the pin and ground, not between the pin and vcc; 8051s'
| 'quasi-bidirectional' i/o ports similarly feature a weak
| pullup and a strong pulldown, so that, again, an open circuit
| is a logic high level
|
| (and normally high is 1, low is 0, though sometimes this
| convention is also violated)
|
| the only exception i know of is that 60-milliamp and
| 20-milliamp digital current loop interfaces, as used on
| teletypes, treat a closed circuit (current flowing) as a
| logic 1 ('mark'), and an open circuit (no current flowing) as
| a logic 0 ('space')
|
| incidentally, 'closed circuit' and 'open circuit' are _also_
| confusing. a closed circuit is 'closed' in the sense that a
| plane curve is 'closed' if it divides the plane into an
| inside and an outside region. on a closed curve, you can walk
| around the whole circuit and return to your starting point
| without turning around, which is in some sense what the
| electrical current is doing. but of course actual electrical
| circuits exist in three-dimensional space, where a 'closed'
| curve does _not_ divide space into an inside and an outside
| region, because you need a _surface_ for that. and in all
| other contexts, something that is 'closed' is something that
| does _not_ permit flow: a closed barn door, a closed window,
| a closed valve, etc. nevertheless, it is far too late to
| eliminate this two-dimensional flatland thinking from our
| vocabulary
| bee_rider wrote:
| Oh, of course that must be what closed circuit meant.
|
| For some reason I just thought "looks like the switches are
| little doors, like in a floor plan, and they are all closed
| now" and I never examined it.
| wolverine876 wrote:
| Most people haven't even heard of binary.
| jodrellblank wrote:
| Silicate chemistry is second nature to us geochemists, so
| it's easy to forget that the average person probably only
| knows the formulas for olivine and one or two feldspars.
|
| https://www.explainxkcd.com/wiki/index.php/2501:_Average_Fa
| m...
|
| See also this comment (
| https://news.ycombinator.com/item?id=39344935 ) "it's
| pretty obvious" that computers use the opposite symbol than
| the name says.
| gsich wrote:
| People are aware.
| NeoTar wrote:
| Isn't that a feature and not a bug for light switches?
|
| It's not uncommon to have multiple light switches control a
| single light socket - switching any of them changes the state
| of the light, therefore you cannot consistently say state-x =
| light on, state-y = light-off.
| marginalia_nu wrote:
| Because language works through association and analogy, you
| don't actually need to know the etymology of a word or symbol
| to use or understand it.
|
| Any English speaker can understand perfectly well the words
| manual, manufacture and manicure without ever reflecting on the
| fact that "manus" in latin means "hand".
|
| We clearly haven't needed to rename these words "handual",
| "handufacture" and "handicure" for these concepts to be
| understood by people who aren't fluent in Latin.
|
| In much the same way, even a person who has never seen a floppy
| disk will associate its likeness with the action of saving if
| it appears next to enough save buttons.
| wolverine876 wrote:
| > you don't actually need to know the etymology of a word or
| symbol to use or understand it.
|
| Etymology, etc. helps to understand what other people mean
| and have meant by the word, and what others will understand.
| thaumasiotes wrote:
| No, it doesn't?
| jodrellblank wrote:
| > " _We clearly haven 't needed to rename these words
| "handual", "handufacture" and "handicure" for these concepts
| to be understood by people who aren't fluent in Latin._"
|
| "manual" is "by-hand".
|
| "hand-made" is the literal meaning of "manufacture" (make by
| hand), if not the industrial meaning used today. From Old
| English hand-wrought, apparently:
| https://www.etymonline.com/search?q=handmade
| btbuildem wrote:
| While the NEC does not specify light switch toggle orientation,
| there seems to be a general convention among electricians and
| installers for the toggle switch to be positioned up for "on"
| and down for "off."
| ComputerGuru wrote:
| Yes, until you throw a second switch in the same circuit.
| Then you'll never know.
| Austizzle wrote:
| In the United States at least. I spent a few years in
| Australia and it was universally the opposite!
| thaumasiotes wrote:
| > In defense of the ambiguity of digital toggles, I'd like to
| add that this is unsolved on most, if not all, physical light
| switches in homes and offices.
|
| What? This has been solved for physical light switches since
| _before_ physical light switches existed.
|
| If the light is on, the switch is set to "light on". If the
| light is off, the switch is set to "light off".
| resters wrote:
| A toggle button should show its current state. A checkbox is a
| good example.
|
| Muted []
|
| vs
|
| Muted [x]
|
| It's pretty obvious.
|
| What gets tricky is when designers create UI that does not have
| as clear a connection between the word used and the visual
| design, such as:
|
| Mute Off [---( )]
|
| Mute On [( )---]
|
| I have no idea what either of these mean because they include the
| action in the description of the state.
| sfn42 wrote:
| "Mute" "Unmute"
|
| I want a button to tell me what it does if I click it. If you
| want to show the current status that is a different thing, not
| a button. A button exists to be clicked, it should communicate
| what it will do if you click it.
| NegativeK wrote:
| Verbs, not nouns.
|
| Which means making sure that the verb form doesn't sound like
| the noun form.
| navjack27 wrote:
| So, while the button is not interacted with (unmuted) and not
| hovered over you would like a mute button to be what? Would
| you like it to be black and white with a microphone symbol
| where the microphone is white and the background is black?
| When you hover your mouse over it should a no symbol in red
| appear over it which could appear black for color blind? When
| you toggle this mute button should that no symbol stay on the
| icon and invert all of the colors so now the background is
| white the microphone is black and the no symbol is white?
|
| I'm really confused by the concept of a button showing me
| what a button should do All of the time because if that
| button is showing me what the button should do then that
| button is indicating to me that that button is doing what
| that button is doing not what the button should be doing.
| That's why there is a hover over state if you're using a
| mouse things become more complicated when you're using touch
| which is why I think the button should not communicate what
| the button should do when interacted with but the current
| state.
| sfn42 wrote:
| Why are you making this so complicated? The simplest
| solution is just a button with text on it. But sure, maybe
| you want a symbol instead, they do look nice and take less
| space.
|
| So when sound is playing, the button should have a symbol
| that conveys "mute", like a speaker in a stop symbol. If
| you hover over it, the tool tip should say "Mute" or
| something to that effect.
|
| If the button is clicked, then the sound is muted. Now you
| could change to a symbol that conveys "unmute" like just a
| speaker symbol. Or you could let go of the whole button
| concept here because it's pretty clumsy and ambiguous, and
| just use a toggle switch instead. Could just have the text
| "Sound on" - "Sound off" on either side, or symbols if you
| prefer that.
|
| You should never assume that the user knows anything. The
| UI should convey everything the user needs to know, trying
| to use some sort of convention doesn't work because there
| is no convention. Avoid using signal colors because as you
| alluded to that also gets complicated.
| krab wrote:
| If there's enough space, a toggle emulation with two labels
| works well.
|
| Loudspeaker [()---] Crossed-out loudspeaker
| ysavir wrote:
| This is what I like to use. Two states with a clear selection
| of one, all visible at all times.
| deepsun wrote:
| And should the sides switch in right-to-left scripts? :)
| croes wrote:
| A checkbox show both, the current state and the possibility in
| form of a simple yes/no option.
|
| A toggle button is confusing because I don't know the designers
| intention unless the button shows both options beside it
|
| Mute On[---()]Off
| jodrellblank wrote:
| > " _A checkbox is a good example. It 's pretty obvious._"
|
| A check is a tick[1]. On a status page[2] a tick means
| "working" and a cross means failed. The "pretty obvious" view
| is that "Muted [x]" has failed in some way. To know any
| different comes from learning computer UX, the opposite of
| obvious. (Or is it "X marks the spot", that's the target I
| should click if I desire "muted"?).
|
| [1] Unicode U+2714 https://www.compart.com/en/unicode/U+2714
|
| [2] e.g. https://www.githubstatus.com/
| serf wrote:
| I just want it to mimic the physical thing if it's going to mimic
| something at all.
|
| A push button toggle stays clicked in, or better yet clicked in
| and illuminated, to indicate that it's on.
|
| a traditional 2 way toggle exposes the state that its' in by the
| position of the knob relative to center.
|
| I mean anyone can flip states around behind the scenes, but if
| we're talking about a switch/wires/battery/light it all works out
| as supposed. Let's follow that example.
| thinkmassive wrote:
| The Tesla app is horrible about this.
|
| What does a greyish padlock icon indicate? Let me tap it twice to
| cycle through states, then I'll click once more if the original
| state needed to be toggled. If there's any delay in the car's
| response, prepare to complete another lock/unlock cycle, more
| slowly this time to be certain.
| tshaddox wrote:
| It's also inconsistent. From what I remember, the padlock
| toggle shows the current state (an unlatched padlock means the
| doors are unlocked, and pressing it will lock the doors), but
| the trunk button shows the opposite (an open trunk means the
| trunk is closed, and pressing it will open the trunk).
| Agraillo wrote:
| The designers of everyday things also fall into this trap. My
| favorite example is the hammer drill, this kind should had the
| mode switch. I have a very decent device but implementing the
| same problem on/off approach showing and hiding the state. I
| almost always pause before choosing the right one. The example of
| the better design (mention in the stackexchange answers) is
| visible at the hammer drill polish wiki page:
| https://pl.wikipedia.org/wiki/Wiertarka_udarowa
| sojournerc wrote:
| I have a welding mask with a "grind" mode that has the same
| issue. Not exactly something you want to get wrong when
| welding.
| rjmunro wrote:
| The absolute worst example of this I have seen is the Tesla
| dashboard screen UI. It shows a car with labels on it, not
| buttons, that say "Open". That unambiguously means that the
| particular part is open. But that's not what it means. The labels
| are in fact buttons to open the parts, and you have no way of
| knowing.
| dhc02 wrote:
| Yes! I was just driving a borrowed Tesla this weekend and
| several times I had a moment of confusion/panic because I
| thought the trunks were both open.
| actionfromafar wrote:
| Can someone make a car which has _none_ of the complicated
| stuff?
|
| List of features I want:
|
| - automatic transmission (if ICE)
|
| - bluetooth and FM radio
|
| - no self _steering_
|
| - cruise control with "follow speed"
|
| - not-batshit-insane self-brake-system (use whatever Volvo
| uses, it works!)
|
| - good airbags and decent structural integrity
|
| - classic sedan height
| semi-extrinsic wrote:
| Oh look, it's the Dacia Sandero!
| toast0 wrote:
| > cruise control with "follow speed"
|
| If I'm reading you right, you want your car to follow the
| speed of the car in front of you? Usually delivered by radar
| assisted cruise control?
|
| That's complicated stuff, and you'll probably get lane
| keeping assistance too, because it's a package. At least on
| my car with lane keeping, there's a big button in the center
| console to disable it.
| thedanbob wrote:
| The last car I rented handled this package terribly. There
| was a way to disable the lane assistance, but it was a
| couple of steps and you had to perform them _every time you
| started the car_ because it wouldn 't remember your
| preference.
| ikealampe200 wrote:
| This is not particularly advanced. Mercedes offers
| "Distronic" since 1999 and it seems Mitsubishi developed
| something similar even around 1992.
| [https://en.m.wikipedia.org/wiki/Adaptive_cruise_control]
| delecti wrote:
| Oh is _that_ what "Distronic" does? I literally work
| there on a backend system that has that term for one of
| the features, and I've just never known. I always thought
| it sounded like something AV related (it sounded "disc"
| adjacent).
| samatman wrote:
| It is "disc" related, the discs in question are the brake
| discs.
| ChillyWater wrote:
| Or, the system automatically keeps your car a specified
| _distance_ from the vehicle in front of you.
| watwut wrote:
| Adaptive cruise control is fairly standard these days, even
| cheaper cars have it.
|
| You can easily turn lane keeping assistance off in my car.
| I guess it is necessary, because lane assistance massively
| sux when there is reconstruction. They are not really the
| same hardware wise, one of them requires radar in front and
| other camera thingy for lanes.
| GeorgeDewar wrote:
| The lane keep assist in my 2017 Leaf is awful. If I used
| it, anyone would take me for a drunk driver as it drifts
| to the edge of the lane and then corrects endlessly.
|
| Thankfully it can be turned off, and it stays off.
| furyofantares wrote:
| No, you can't get a car with exactly the feature set you
| specifically want and nothing more. This is because other
| people want a different feature set. It's even true of things
| that are vastly less expensive to produce than a car.
| samatman wrote:
| This is true in general (for all feature sets anyone might
| want, there must exist a car with those features) but
| doesn't have to be true in particular (for a given feature
| set, there may exist a car with those features).
|
| I suspect you have no idea if OP's feature set is available
| on the market. I certainly do not.
| furyofantares wrote:
| I would certainly be willing to bet there's nothing with
| speed-matching cruise control but none of the other
| features that depend on related sensors and software. Let
| alone one that also has the rest of the features and no
| more.
| superjan wrote:
| They won't. The car maker has the Budget product and the
| Premium product. The car maker wants to justify a high price
| for the Premium product, so they put in all conceivable
| features, useful or not. What you want is a Decent product.
| If they add it to the product line, it would cannibalize
| sales for the premium product, so they gain nothing. For the
| same reason my wife's Premium electric toothbrush has a color
| screen, shitty IOT bluetooth features and a terrible battery
| life.
| fckgw wrote:
| All these features are available in a base model $20k
| Hyundai Elantra though.
| fnimick wrote:
| Chevrolet Bolt EV? Physical buttons everywhere. No fancy
| features. It just works.
| Night_Thastus wrote:
| Most cars have that feature list, as for the things you
| _dont_ want, you can just toggle them off or not use them.
|
| Though sedans are a dying breed, so I'd get one sooner rather
| than later. Everyone and their brother wants SUVs/CUVs and
| sedan offerings are getting slimer by the month.
| kevin_thibedeau wrote:
| Disabling a feature doesn't protect you from firmware bugs
| or higher repair costs from the more complicated hardware
| you have but are not using.
| Night_Thastus wrote:
| If you're not using the feature, then a bug in it would
| be hard to manifest.
|
| And as for the more complicated hardware, I am afraid
| that ship has sailed.
|
| Cars have become incredibly complex in the last couple of
| decades. They are covered in sensors and filled with
| computers to handle everything, from the injection of
| fuel and shifting to acceleration and braking to
| infotainment and climate control.
|
| If you want Cruise Control with distance following that
| means you get brake-by-wire and accelerator-by-wire with
| a computer making decisions about when to do both.
|
| You cannot eat your cake and have it too.
|
| If you want a simpler car, then look to the 90's - they
| still had computers, but obviously the technology was
| more limited. You won't get radar cruise control or much
| in the way of blutooth though, obviously. You can still
| have an automatic sedan with pretty good safety. (Not as
| good as modern, but decent)
| fckgw wrote:
| You're looking for literally any Hyundai, Kia, Toyota, Honda,
| Chevy or Mazda sedan. Hope this helps.
| mywittyname wrote:
| Automatic Emergency Braking and adaptive cruise are
| difficult features to avoid. The IIHS dings vehicle safety
| ratings if they do not have AEB. Because of that, even
| entry level vehicles like the Elantra have AEB.
|
| Almost every manufacture has committed AEB on their entire
| lineup.
| fckgw wrote:
| They said they want adaptive cruise control but not lane
| keeping. Most automaker allow you to disable the lane
| keeping if you want while keeping cruise (my Ford does
| this)
| watwut wrote:
| He asked for "no batshit insane" breaking system. Sane
| systems that engage only when it is truly last moment
| rather then overeagerly or randomly exists. My seat
| basically never breaks despite having the feature -
| because itnis setup for actual emergency.
|
| Plus, you can turn it off.
|
| You can always turn off lane control too.
| stavros wrote:
| Mercedes A-class 2014 is this car.
| hbs18 wrote:
| You've described a 15 year old BMW 3 Series.
| skydhash wrote:
| That's basically my 2001 Toyota Rav4 and my brother's 2010
| Hyundai Creta.
| ZitchDog wrote:
| Yes, 100%! This is my second most frustrating UX gripe with the
| Tesla trunk UX - the first being the super long animation you
| have to wait through in order to open the trunk after putting
| the car in park. Overall tesla UX is miles ahead of other cars,
| but the little things like this are so frustrating!
| fnimick wrote:
| > Overall tesla UX is miles ahead of other cars, but the
| little things like this are so frustrating!
|
| IDK, I prefer my boring old UX of 'physical buttons on a
| dashboard', plus it's a lot easier to interact with without
| taking your eyes off the road ;)
| amarant wrote:
| Huh, I don't think it's confusing at all, the rendered car
| clearly shows the current state of the trunk, and when you push
| the open button, there's even an animation showing the trunk
| opening.
|
| To each their own I guess
| ljsprague wrote:
| Is this peculiar to English? For instance, in Spanish, the verb
| and the adjective would be different words.
| bckygldstn wrote:
| Yes, it is unfortunate that in English the imperative
| conjugation ("open this door") is typically the same as the
| present participle verbal adjective ("this door is open").
|
| In English you can also form an adjective from the past
| participle ("this door is opened"). Using "opened" resolves
| the ambiguity in one direction only: when you want the
| adjective. But when you want the verb you'd have to add
| context: perhaps "tap to open".
| signaru wrote:
| It is forgivable if the wrong choice is not so harmful (e.g.
| play/pause a video) and the effect is reversible. There's an
| e-commerce website I use that has an option to post product
| reviews as anonymous with a "slide toggle" typical of mobile
| devices. The only feedback is after the review gets posted which
| cannot be undone. I just learned by experience, but it is always
| confusing to interpret.
| bee_rider wrote:
| RIP Checkbox, 1990-2009, you were perfect and unambiguous but for
| some reason smartphone designers hated you.
| _0ffh wrote:
| Right, or use a 3D look or colour or backlight effect to
| indicate when a toggle is active.
| denton-scratch wrote:
| I agree that checkboxes are perfect; but that's because I never
| try to fill forms on a smartphone. Native browser checkboxes
| are often unusable on smartphones; too small to hit with a
| thumb.
| bee_rider wrote:
| True.
|
| It seems like an odd historical problem though. We could just
| render checkboxes bigger or with more white space around
| them, and make the touch area bigger in any case.
| denton-scratch wrote:
| Sure, you clould just fix checkboxes. But then you have to
| deal with select boxes, which also work badly on
| smartphones.
|
| Then you have the modern smartphone-driven practice of
| using multipart forms, with one field on each part. You
| can't see the whole form at once; you eventually find out
| that the very last field is a date-field with three badly-
| behaved drop-downs that you can't interact with.
|
| I just don't try to fill forms on my smartphone. In fact I
| only use it as a (shock!) phone.
| lowboy wrote:
| The checkbox label is often my thumb's target. A pox on the
| house of any dev who doesn't properly use a _for_ attribute.
| mywittyname wrote:
| Properly designed, the tapping/clicking the text should also
| trigger the checkbox.
| denton-scratch wrote:
| > Properly designed
|
| It shouldn't need designing; but I have a suspicion that an
| unstyled HTML checkbox input doesn't behave like that.
| pfg_ wrote:
| It does as long as you mark the label as being for the
| checkbox or put the checkbox inside the label, which you
| are supposed to do.
| kqr wrote:
| This is extra silly because you can make what's effectively a
| checkbox look really nice and toggle-y. Although this is a bad
| example it shows that it doesn't have to be a square with a
| check mark in it:
| https://www.ranecommercial.com/legacy/hal/MobileHelp/Advance...
| hombre_fatal wrote:
| Switches are already ubiquitous on mobile UIs:
|
| https://developer.apple.com/design/human-interface-
| guideline...
|
| But checkboxes and switches don't always make sense. You
| don't always have room for e.g. "Light mode <switch>". Every
| component that you give more room to takes room away from
| other UI.
|
| Rather than look at the obvious cases, the hard part is the
| periphery of what's obvious.
| alonsonic wrote:
| Issue is that modern UX designed moved away from this type of
| 3D buttons. There was a big transition from UIs using heavy
| skeuomorphism to a more flat and digital look.
|
| To achieve hat you're showing you need some depth to the
| button. Hard to accomplish with today's design trends.
| AlienRobot wrote:
| It's things like this that make me think the way to make a
| good UI is to look at what modern UIs do and do the exact
| opposite.
|
| 1. No spacing.
|
| 2. Information-heavy cluttered screens.
|
| 3. No auto-save. You have to click the save button to save.
|
| 4. Colored icons. Colored interfaces. Not "tinted" a hue of
| black or white. Actual vibrant colors. And not just one
| color either! Two colors, at least.
|
| 5. 3d.
|
| 6. Main menus.
|
| 7. border-style: ridge;
| bee_rider wrote:
| Sounds kind of hard to use on mobile, which is
| indisputably a popular set of platforms.
|
| No need to throw the baby out with the bathwater. Big
| (resizable) UI elements with poke-ability are fine. Auto-
| saving can be great depending on the application. Let's
| just ditch the false simplicity and flatness.
| AlienRobot wrote:
| Every single time I'm on desktop and I see a GUI that
| sucks, I know it's mobile's fault. Why this button so
| big? Mobile. Why spacing? Mobile. Why this list of 6
| clickable items with one line of text each takes up my
| whole screen's vertical space? Mobile. Why no more status
| bars and tooltips? Because you can't hover on mobile. Why
| is the filter of this table below the table instead of
| above the table's headers? Because the thumbs won't reach
| the top on mobile. Why the headerbar buttons have no
| labels? Because they wouldn't fit in the horizontal space
| in mobile.
|
| I'm really not a fan of mobile. If possible, I'd rather
| ignore it completely and just let mobile users rotate
| their screens.
| adamwk wrote:
| Screen size isn't the problem for mobile, it's tap
| targets
| FridgeSeal wrote:
| Peak UX design was the WinAmp and Windows media player
| skins of the Windows XP era.
|
| They exhibit almost all of these properties, and they
| were _glorious_ to use.
| AlienRobot wrote:
| Absolutely. I have a theory that "windows" are called
| "windows" because of the 3D ridges at the borders. The
| moment we stopped doing ridges, everything went the wrong
| direction.
|
| This translucent, rounded, acrylic, material, whatever,
| it's just not fun. We had the technology for making
| glorious media players in the year 2000. Where did our
| technology go?
|
| I'm on linux right now and I checked a bunch of desktop
| environments and every single one I checked the themes
| for (the theme browser sucks, by the way) what I see is
| dark theme with a blue tint, light theme with a blue
| tint, dark theme with a green tint, light theme with a
| green tint. A Windows 95, XP, and 7 clone. And that's it?
|
| It just blows my mind. I don't know if it's because the
| theme browser sucks (the websites to browse the themes
| also suck, by the way), but I can not find one theme like
| XP but not XP. I'm left wondering where did all those
| people who made so many beautiful, glorious, amazing
| WinAmp themes go to. Did they become extinct? Are the
| theming APIs too limited today to go all out? Is the
| technology not there yet to have border-image in your
| windows borders?
|
| This is just so depressing. I'm hoping the pendulum
| swings back in the next 10-20 years, and hopefully I'm
| still alive by then to see some cooler GUIs.
| skydhash wrote:
| I remember modifying the UI of Virtual DJ 6 for friends
| that wanted their logo on it. It was all bitmaps. And I
| guess the different skins were 3D renders on existing DJ
| decks. But they were beautiful, although there was a
| period there were some issue when laptops were moving to
| a wider ratio.
| phkahler wrote:
| >> To achieve hat you're showing you need some depth to the
| button. Hard to accomplish with today's design trends.
|
| This why some people complain about UI design "trends".
| They elevate an aesthetic choice over clarity, usability,
| or function (not sure which word is best here). Or in this
| case it seems part of the push was to reduce the screen
| space taken by a control.
| pera wrote:
| Who created the checkbox widget? System 1 (1984) had check
| marks on the menu and "x boxes", which are equivalent, but not
| checkboxes afaik
| bee_rider wrote:
| I actually have no idea, I made up 1990 completely, I bet it
| is way too late. In any case, I guess it is just the
| digitization of an existing UI element from paper forms,
| right?
| Someone wrote:
| > System 1 (1984) had check marks on the menu and "x boxes",
| which are equivalent, but not checkboxes afaik
|
| I think it had (https://andymatuschak.org/files/papers/Apple%
| 20Human%20Inter..., page 56)
|
| I don't know whether those were the first, but
| https://skeuomorphic.design/p/from-paper-ballots-to-
| pixels-t... claims they were, in the sense that the Mac made
| radio buttons different from toggle buttons.
|
| Does anybody know in what cultures a checkmark would be
| inappropriate, as that page claims?
| pera wrote:
| Thanks, that's a nice pdf: so what I called "x boxes" were
| actually named "check boxes" (although they didn't use the
| check mark symbol)
| silon42 wrote:
| Here are some samples from 1987... (CUA standard)
|
| http://toastytech.com/guis/cua1987.html
| klabb3 wrote:
| Yes obviously, because checkboxes need accompanying text,
| otherwise it's just a mystery fidget. Text on a small screen is
| a problem for obvious reasons.
|
| The you have the second problem: checkboxes were part of web
| forms, where you have a submit button. So a whole generation of
| users were taught the abstraction of "saving" your settings as
| an explicit gotcha step. The checkbox didn't _do_ anything on
| its own.
|
| Very likely, Apple wanted to start over with an element that
| was independent and immediate, in their preference panes. But
| checkboxes would have worked too, in _preferences_ - but does
| not solve the in-app problem:
|
| The _icon_ toggle buttons are not mobile designers faults -
| they existed way earlier, primarily known from text editors
| (think the bold /italics toggles). Who messed them up so badly,
| I don't know..
| 83457 wrote:
| A medical video conference / telehealth system my provider uses
| has broken the checkbox. In their direct message interface they
| change the a checkbox field label based on whether the box is
| checked. Unchecked has the label as "Not Urgent" and checked is
| "Urgent". On multiple occasions I have quickly checked the box,
| to indicated as not urgent, then clicked send.
| rconti wrote:
| There are a number of ways to get this wrong. The shuffle button
| in Spotify on our Tesla is a grey color, and you have to wonder
| if it's dark ENOUGH a grey to indicate that it's on, or a light
| grey to indicate that it's off. So then you go to toggle it on
| and off to see the state change, but actually it's buggy so it
| doesn't do anything.
|
| When you finally get it to toggle on, you realize the shuffle
| lines turn GREEN, not dark grey like most of the controls.
| _facepalm_
| 1letterunixname wrote:
| Some UI designers do not understand design, e.g., affordances.
| qingcharles wrote:
| Also, the problem with buttons like this is that the shade of
| grey depends on the angle you're looking at the screen, so you
| end up moving your head around trying to figure out if it is
| actually on or off.
| lopkeny12ko wrote:
| Why not just use a checkbox? Is anyone here a designer with a
| serious answer to this?
| bandergirl wrote:
| _Cuz they ugly_
|
| The dribblization of UI lead to a bunch of people trying to
| make things pretty for their own benefit. Then they look at it
| in Figma and it looks absolutely stunning. Never mind that
| actually needs to be understood and used by someone, that's
| irrelevant.
|
| Just today I saw a HSL color slider on Twitter that was a
| single hue slider with two half-arc sliders on the main
| slider's handle: one above for saturation, one below for
| lightness. It sounds like a joke but...
|
| https://twitter.com/jh3yy/status/1756429165803246028
| tweakimp wrote:
| I think toggle switches are newer and therefore designers think
| they are more fancy to use.
| koito17 wrote:
| I am not a designer, but I've always heard that the difference
| between checkboxes and toggles is that toggles are expected to
| immediately produce side effects whereas checkboxes aren't.
|
| That is to say, clicking on a checkbox shouldn't immediately
| mutate some state, whereas activating a toggle should.
| syngrog66 wrote:
| show an arrow from Now to Next state
|
| kids: get off my lawn. lol
| taeric wrote:
| I'm surprised we are still iterating on ideas like this, to be
| honest. Seems flight decks have been rather successful on
| complicated dashboards for a long time. Same with boats. Why can
| we take approximately no lessons from them?
| sitzkrieg wrote:
| overpriced ux designers
| spyke112 wrote:
| Perhaps what we do on a pc is not really that complicated or
| critical compared to flying a plane or steering an oil tanker.
| Just a thought.
| taeric wrote:
| I mean, sure? But, to that point, why discuss the
| conventions? If the goal is to have a predictable interface,
| it seems fair and in scope to study larger interfaces that
| people have to read quickly.
| spyke112 wrote:
| Don't get me wrong I actually agree with you. I'd also love
| to have more consistent ui's, but at the same time I get
| why the business wants to differentiate it self from the
| competition by not having a super effective "boring" ui.
|
| What I'm getting at is that it's a lot more nuanced than
| what I as a software developer might like.
| ZitchDog wrote:
| The interfaces you are talking about require years of training,
| study and passing multiple tests to demonstrate proficiency. In
| software UX we are talking about discoverability and
| approachability for the untrained operator.
| taeric wrote:
| Most of the training is to know which ones need to be on and
| which ones need to be off. Not how to read various buttons as
| on or off. And the point there is they are able to rapidly
| scan a dashboard to know what is on and off at a glance.
|
| Similarly, sliders and levers help you see which ones are
| maxed out and which ones are set at a rough 50% or similar.
| samatman wrote:
| Since failure to operate the controls correctly can get
| hundreds of people killed, there are detailed regulations
| governing how those controls must work.
|
| OP is entirely correct that the UI field could learn a great
| deal from those standards.
| karaterobot wrote:
| I mean, we do have solutions to this problem. You use them
| every day. The problem is that, unlike air travel or the
| military, nobody can say "everybody must do it this way". So, a
| lot of people do it their own way.
| sponaugle wrote:
| I have some old NASA push button switches that have two bulbs in
| them. When the switch is off both lights are off, when you click
| the switch the yellow bulb comes on and lights up the switch, and
| when the device you turned on actually turns on a green light
| turns on ( and the yellow turns off ). The idea is you push the
| button and the yellow state is the confirmation that you toggled
| the switch, but the green is the confirmation that the action you
| wanted occurred. Kind of an interesting 'state feedback'
| mechanism.
| 2OEH8eoCRo0 wrote:
| I like it. Why doesn't our "industry" look at aviation/military
| more often where miscommunication gets people killed.
| ajmurmann wrote:
| I think the answer is that "looking pleasant" is much more of
| a goal for commercial software. In usability terms the much
| denser GUIs of the 90s were arguable better in some ways than
| what we frequently see today, especially for power users.
| kfarr wrote:
| Yes just like the design of car infotainment systems --
| looking good resulted in the touch screen era. Luckily
| we're finally realizing our mistake and a few automakers
| are putting old school knobs back in.
| kqr wrote:
| This is a good one, and also what airplanes do[1]. These
| problems are solved by people who care a lot about usability,
| but computer people are slow to pick up this sort of stuff from
| other fields.
|
| Labels outside the switch also work.[2]
|
| [1]: https://my737ng.com/wp-
| content/uploads/2014/08/cp_mcp_header...
|
| [2]:
| https://i.pinimg.com/originals/2c/37/0a/2c370a3f4018cfa9c3ef...
| pjot wrote:
| My table saw has this as well. A green and red light, both
| with off/steady/blink states that indicates information about
| the blade and safety system.
| bqmjjx0kac wrote:
| Mine has this as well! I like the UX, but it's also kind of
| crazy that they didn't think about red/green colorblind
| users.
| kqr wrote:
| Are they incandescent or LED? Until recently red and
| green were the only LEDs possible and some industries
| move slowly on such things.
| thr33 wrote:
| colorblindness would have no effect on this ux pattern
| 1-more wrote:
| God are they ever nice saws too. Good for you big dog.
| Sohcahtoa82 wrote:
| > computer people are slow to pick up this sort of stuff from
| other fields
|
| Because computer people aren't optimizing for functionality,
| intuitiveness, or really any sort of UX.
|
| They're optimizing for some idea of "beauty" and whatever is
| trendy.
| mattmaroon wrote:
| And you don't die if your mute switch is in the wrong
| position at the wrong time.
| sumtechguy wrote:
| The real pain is this _WAS_ a solved problem in computers
| too. Almost all of the GUI OS 's had a style guide. Usually
| 2-3 pages at most (usually smaller) and fairly easy to
| follow. Then everyone went bonkers and wanted to make their
| own. Then dump that all into one desktop and good luck...
| Every app is special.
| pavon wrote:
| A chunk of my early career was writing GUI software to control
| and display state of remote hardware, and I quickly learned to
| banish any "stateful" UI elements - those that retained their
| own state and changed behavior based on that state, like
| toggles, switches, check boxes, radio boxes, etc - because it
| wasn't uncommon for the interface and hardware state to get out
| of sync.
|
| What I ended up settling on to replace them was a button for
| each option, where the respective button would light up to
| display the current state. For example, what would be an on/off
| toggle became two buttons labeled on and off. Initially both
| buttons were grey, and when the UI received SOH from the
| hardware indicating that the state was on, the on button became
| green, or for off, the off button became red. If communication
| was lost for some time all the colors became desaturated, to
| indicate the state was stale. When a button was pressed, the
| old state continued to be displayed, but desaturated (for just
| that button set), until a new state was received back. The user
| could always command the system on or off at any time (by
| clicking the respective button) regardless of what state the UI
| though it was in, unlike a toggle which only lets to you change
| to the "other" state. Likewise, radio buttons were replaced
| with a series of buttons labeled with their state, and the one
| the UI thought was current was colored (using blue for most
| "neutral" states and green/yellow/red if the state had a
| good/warn/bad meaning to the operator that they wanted to
| highlight).
|
| Despite the atypical design, I found that operators generally
| understood the interface without training - buttons looked like
| buttons so they must be clickable. The spacing of buttons made
| it clear they were a set, and since grey was the default color
| of everything in 90s UI, the button that was colored
| differently stood out and must be the current state. I don't
| know if that would be the case today, where UI element can be
| any color chosen for aesthetics or funneling and only sometimes
| communicate information.
|
| I did experimented with displaying both the commanded state and
| received state in various ways (akin to NASA's buttons), but
| all ended up being more confusing.
| mjamesaustin wrote:
| For an interface with hover interaction, a toggle button should
| show its current state by default and then on hover show the
| state it will switch to. This design pattern affords
| discoverability through safe interaction with the element.
|
| Unfortunately that design pattern fails for touch interfaces,
| which increasingly are our primary method of interaction.
| wforfang wrote:
| Tesla makes this mistake with their ambiguous "lock" button on
| the iOS app. The button toggles between an open/closed padlock
| icon. I often lock the doors remotely and since I can't
| physically see the car to confirm, I get paranoid about whether
| the icon is representing state or action.
| lxe wrote:
| We had radio buttons forever, but no, let's complicate things.
| Macha wrote:
| This is a problem for forms where companies are legally required
| to follow the users instructions but may not want to. I find
| myself not trusting them to not pick deliberately unintuitive
| interpretations. Think the kind of designer that comes up with
| "check this box to receive transactional emails but not marketing
| emails", when an unchecked box leads to marketing and
| transactional emails.
| alpaca128 wrote:
| The only two good suggestions I saw were radio buttons as well as
| toggles with labels on the left & right (so basically two merged
| radio buttons).
|
| I think the play/pause button in media apps is an acceptable
| exception simply because it's obvious whether it's playing or not
| - you could even use it without recognizing the symbol, if music
| is playing you know a click will pause it.
| apapapa wrote:
| I don't know how developers manage to make simple toggle switches
| confusing and it makes me scared of their code but sometimes I
| think it's done on purpose as a dark pattern (when you
| unsubscribe to spam for example)
| User23 wrote:
| UX novelty for its own sake is annoying. Just use a checkbox.
| 1970-01-01 wrote:
| There should be no ambiguity here! A toggle button is an analogue
| for a physical switch. Unless the switch state is dependent on
| other switches, it must always display its current state. i.e.
| ENABLED is always true unless POWER is OFF.
| kortex wrote:
| There is ambiguity in the physical world. Some audio equipment
| have what's called a ground lift. It physically disconnects the
| ground conductor between two devices, and it's usually a single
| push-toggle in/out button. I've seen some devices with "Ground
| On/Off" - does that mean grounded (not lifted) or not grounded
| (lifted)? IIRC one of the DI boxes I've used is the opposite of
| what you'd expect - "Off" means lift is off, meaning ground
| loop is connected. The sensible devices have two states
| "Lift/Gnd".
| 1970-01-01 wrote:
| That is a poor design choice. VERB STATE TRUE is standard for
| every toggle switch on all my hardware, including prosumer
| amps. Changing this can be deadly, and was found to be part
| of the reason for the 737 MAX going down in 2019:
|
| https://www.seattletimes.com/business/boeing-
| aerospace/boein...
| ww520 wrote:
| I usually make a toggle button reflects its current state and
| shows the next state in some other way, like in the hover over
| tooltip or small subscript text. That means a toggle updates two
| things, the button itself and the tooltip.
| mrighele wrote:
| The main issue with toggle buttons is that you have an object
| that at the same contain the state of the system and the action
| to change it.
|
| The consequence is that it is not clear if the "ON" that you see
| on it is the current state (so pressing on it will turn it to
| "OFF"), or the action that you will invoke when you press it.
|
| The solution is to separate (part of) state and action, and this
| can be done in a few ways. One possibility is to do like one of
| the answers in the link suggests, and write the label _outside_
| the button. If you don't have a switch but a toggle button (like
| the teams example in some other comment), leave the icon alone,
| and change some other properties of the button (for example
| leaving it pressed to signal the "ON" state, like it has been
| done for decades without any issue....)
| vleaflet wrote:
| System sound properties in Windows 11 has an option "Allow apps
| and Windows to use this device for audio" and a button labeled
| "Don't allow" next to it. So what is the current state? I have
| no idea.
| tootie wrote:
| The top answer references About Face 2.0 which I read at the time
| and it's still probably the best book on user experience design.
| I think there's newer editions, but the principles it laid out
| were really the fundaments that I still live by.
| brudgers wrote:
| Yes.
|
| Or both...like a real world toggle switch.
|
| Or have user configurable behavior (an idea that seems to be
| mostly out of fashion among designers...get off my lawn).
| continuational wrote:
| I think the iOS switch controls are pretty easy to read, even
| though the only real clue to the state is that off is gray and on
| is colored.
| SkyMarshal wrote:
| Should show both, just as analog switches do. You want it to
| clearly unmistakably show the current state, but also the state
| to which it will change.
|
| Apple has really nailed that with its sideways slider toggles.
| You can clearly see where the toggle is currently, what it will
| change to, and whether the current setting has made some feature
| active (blue background inside the slider) or inactive (grey
| background inside the slider).
| johnea wrote:
| It should display the current state, of course.
|
| Because when it's not being clicked, it is a status indicator...
| croes wrote:
| >Flip-flop button controls are very efficient.They save space by
| controlling two mutually exclusive options with a single control.
|
| Compared to what? Definitely not a checkbox.
|
| The problem of a checkbox is just it's not very visually
| appealing but pretty good on carrying zhe necessary information.
| pcwelder wrote:
| The second answer is the only correct solution.
| DanHulton wrote:
| Easy. It should be a checkbox.
|
| (If checkboxes are unavailable in your design system, you should
| have an unambiguous label next to it saying "On" or "Off", or
| better, describing the current state of the system in the
| terminology of the system, like "Background Noise Cancellation
| Enabled". But having a control label and a status label _should_
| be a clue that you should just be using a checkbox.)
| unsupp0rted wrote:
| When disambiguation matters, I always default to a label that
| says "press to ~".
| MattGrommes wrote:
| One of the worst cases of this is the 'Airplane mode' toggle on a
| Kindle. Airplane mode turns off wifi but the icon is an airplane
| that says 'On' when airplane mode is on. When you click it, it
| turns to 'Off'. But what you really want to do is turn the wifi
| off and on, which is the opposite of the icon. 'On' means the
| wifi is off, 'Off' means the wifi is on. Terrible.
| zamadatix wrote:
| Airplane mode status and Wi-Fi status are separate statuses.
| Airplane mode can be on and it tells you nothing one way or the
| other about the actual state of Wi-Fi. This ultimately comes
| down to some Kindles being like phones and having more than 1
| radio where you may want airplane mode on except for the Wi-Fi
| radio if you plan on using in flight Wi-Fi.
|
| Airplane mode is a convenience to conserve battery during a
| flight. If you judge it by how well it acts as a universal
| radios on/off switch it will measure accordingly.
| thih9 wrote:
| It also works if the button is not labeled, as long as the state
| is clearly visible in the environment and the link is clear.
|
| Consider the light switch - if there's just one, it's the best UI
| ever. You know what to do to turn the lights off, just flip the
| closest switch. Obviously if there's more than one then it's the
| worst UI ever.
|
| Another example, a smartphone's side button (screen on/off).
| layer8 wrote:
| This wasn't an issue when buttons were 3D. They had an icon (or
| text) indicating what they activate, and were rendered depressed
| when active and raised when inactive. Some color could optionally
| be added to the icon to reinforce the active state.
| brianstorms wrote:
| Any Tesla owner can relate to this, given the wide variety (read:
| no consistency, no standards) of toggle buttons the car's UI
| utilizes.
|
| For one, the HVAC. One button, showing temperature, which upon
| touched the system will react differently to depending on how you
| touch it and for how long. Touch it briefly, you get a little
| popup. Touch it slightly longer, and (hopefully, not guaranteed
| though) you get a bigger panel with full HVAC controls. Touch and
| hold for a couple seconds, and (hopefully, not guaranteed though)
| you turn off the HVAC if it's on. ALL WHILE YOU ARE DRIVING AND
| SUPPOSED TO WATCH THE ROAD. And if your hand/eye coordination is
| slightly off (and hey, when you're driving, going over bumps,
| etc, it very likely is) if you mis-aim by even a millimeter, you
| may touch another button and not realize it and do something
| unintended.
|
| Another disaster: Tesla's entire connect-a-Bluetooth-device UX is
| one of the worst mishmashes of disastrous UI design I have ever
| seen in a shipping product, at least the 2012-2022 Model S
| implementation. Just one example, a button label down at the
| bottom right that still says "Connect" long after the device is
| already connected, but meanwhile elsewhere on the opposite side
| of screen, up top at the left, that says "Connecting..." then
| indicates the connection is made. All this in a UI that you only
| have a split second to glance at because it's in a CAR and you
| very well might be DRIVING. The Tesla Bluetooth UI could fill an
| entire chapter of a book on UI, it is so magnificently bad. Maybe
| I should write it.
| sgustard wrote:
| Tesla's mobile app features inconsistent toggles right next to
| each other!
|
| - A closed padlock means the doors are locked. Tapping it
| unlocks the doors.
|
| - The word "Open" on the trunk means the trunk is closed.
| Tapping it opens the trunk.
| brianstorms wrote:
| Yes, so true! The inconsistencies and non-standardization
| continues in Tesla's mobile app. There are many other
| examples there too.
| esafak wrote:
| Actually Bluetooth works well in my 2023 Model Y, and I am very
| pleased because it did not in my old Audi and Ford. There has
| to be something seriously messed up with the Bluetooth spec if
| implementations are always so bad.
| willsmith72 wrote:
| you _should_ write it, i always find these kinds of writeups
| fascinating, and tesla (therefore elon) being the subject would
| only make for more general interest
| avgcorrection wrote:
| Not directly related but Bitbucket cloud has made some recent
| update where they started prioritizing reviewers over submitters
| in pull requests. One change is that you by default get the "I'm
| reviewing" filter turned on by default. Which I have to turn off
| most of the time. Anyway, sometimes I try to turn it off but
| _then it is toggled_ (it was off). What's going on? Well, the
| normal interface is that it's a combobox where no-text means no
| filter--that's where the I'm Reviewing by-default resides. But on
| a slightly different pull request view--which looks almost the
| same--the UI element is the same kind of thing... except here the
| combobox gets a black background _when toggled_! And the default
| is to show some option like I'm Reviewing but on a white
| background, which means not-toggled...
| e40 wrote:
| Google's Youtube TV. The UI infuriates me. To this day I can't
| remember which state the toggle is in. I do know it's the
| opposite to every other app on my Apple TV.
| ok123456 wrote:
| Use a skeuomorphic toggle switch modeled off a PDP-8/e panel
| toggle switch.
| riwsky wrote:
| I go back and forth on this one
| macspoofing wrote:
| Current state. Always current state.
| mathgradthrow wrote:
| In means yes out means no, avoid double negatives.
| p1mrx wrote:
| When I designed a lock/unlock button for my app, I added an arrow
| to indicate _what action occurs_ when you click the button:
| https://www.youtube.com/watch?v=9MZmwkn-2rw&t=117s
|
| For an unmute button, you could have a microphone with a line
| through it, and an arrowhead indicating that clicking the button
| will remove the line. Then the mute button could show a
| microphone with an arrowhead pointing inward from the corner,
| indicating that a line will be drawn.
| jonplackett wrote:
| I demand EU legislation!
| mark_undoio wrote:
| I once worked on an Optical Image Stabilisation system for mobile
| phones. I'd updated the stock Android camera app to show some
| icons from marketing for when the shake compensation was on /
| off.
|
| The icon for when compensation was on was a shaky camera. When it
| was off, it was a shaky camera with a line through it...
|
| Except, we asked, wouldn't the other way round make more sense?
| Doesn't line through shaky camera suggest we're removing the
| shake?
|
| We ended up using the icons and just colouring them green for
| "on" and red for "off" and hoping people would figure out what we
| meant. And, yes, that would _still_ be unhelpful for colour blind
| users!
|
| User interfaces are hard.
___________________________________________________________________
(page generated 2024-02-12 23:00 UTC)