[HN Gopher] In loving memory of square checkbox
___________________________________________________________________
In loving memory of square checkbox
Author : kevingadd
Score : 1801 points
Date : 2024-01-28 00:36 UTC (1 days ago)
(HTM) web link (tonsky.me)
(TXT) w3m dump (tonsky.me)
| romwell wrote:
| Windows 95 remains the pinnacle of clear, discoverable GUI.
|
| It's like the companies rolling out UI elements don't even bother
| running them past _people_ , and are guided solely by what the
| design department thinks looks cool that day.
| function_seven wrote:
| I'm might quibble a bit and choose Windows 2000, or even XP
| despite the Fischer Price skin, but generally I agree.
|
| Clickable things should have some minimal skeuomorphic detail
| and scrollbars need to be a minimum of some thickness.
| emayljames wrote:
| Especially scrollbars. For a webdev trying to figure out what
| element triggers the scrollbar is extremely difficult with
| thin disappearing scrollbars.
| ginko wrote:
| You could disable the Fischer Price skin in XP. Many people
| did.
| beders wrote:
| It was IBM who established the standards with its CUA books.
|
| https://en.wikipedia.org/wiki/IBM_Common_User_Access
| TheChaplain wrote:
| This with MacOS 9 and GTK2 not far behind.
| vultour wrote:
| Windows 7 was the last one that let you select the "classical"
| pre-XP theme. I was the only person I know who used it, and I
| miss it to this day.
| seabass-labrax wrote:
| Lots of educational institutions and public libraries used it
| here in Britain. I think it was good at squeezing a few years
| of extra life out of the hopelessly underpowered machines
| that they bought, but I rather think removing the myriad
| copies of Java Updater and the McAfee Virus* would have been
| more effective.
|
| * Officially called the McAfee Antivirus, but I've never
| understood why
| dexwiz wrote:
| I like the checkboxes and loath the toggle. But after surveying
| people outside of the tech scene, for anyone with processing
| issues like ADHD, they report check boxes as easy to
| misinterpret. Something about the physical movement of the toggle
| helps them. So I relent and implement toggles.
|
| But yeah, fuck round checkboxes. Shows the people driving now are
| more business oriented and have no love for the culture.
| dheera wrote:
| I like toggles, they are much larger touch targets and easier
| to hit one-handed when you're running late to a meeting and
| can't hold your phone still.
| orangepanda wrote:
| I dislike toggles as the on/off state is not always obvious.
| Some fun examples I've encountered:
|
| * red is "on" and by default already selected, black is "off";
|
| * black is "on";
|
| * saw one cookie consent form with red meaning "on", and green
| meaning "off".
| emayljames wrote:
| That is frustrating, and very bad accessibility.
|
| It should always be grey = off, darker = on.
| jameshart wrote:
| Except in dark mode when lighter should be on.
| mike256 wrote:
| If you like to design good UX, you shouldn't look at any
| cookie consent forms.
| masklinn wrote:
| > saw one cookie consent form with red meaning "on", and
| green meaning "off".
|
| Cookie consent forms are specifically designed with all sorts
| of misleading and user-hostile patterns, so I would not take
| them as an example of anything. I'm sure there are consent
| forms out there with checkboxes where checked means no.
| Too wrote:
| There is a significant difference between checkboxes and
| toggles. Checkboxes expect a secondary submit step, whereas
| toggles have instant effect. https://blog.uxtweak.com/checkbox-
| vs-toggle-switch/ explains this better. Especially the pizza
| toppings example, that obviously make no sense with toggles.
| emayljames wrote:
| Only if that is how you implement it.
|
| I have done tons of toggles that are not reactive, being a
| form submit
| Too wrote:
| You can...but it will be unexpected for most users and for
| most use cases. Look at the pizza toppings example in the
| link above again, it's a clear semantic difference.
|
| I can implement a radio button that allows multiple choices
| also, doesn't mean it is the right thing to do.
|
| Now there are of course exceptions to the rule. One case
| where instant reaction on checkboxes are common is filters
| in online stores. I think that's a leftover design from the
| days you had to actively click search on each change to the
| filters. Those will work equally good with toggles.
| zogrodea wrote:
| Checkboxes can also have an indeterminate state (usually with
| a "-" in place of the checkmark), like the ones you can see
| at the below link (and which your link also mentions).
|
| https://storybook.react95.io/?path=/story/controls-
| checkbox-...
|
| I think the ternary checkbox has two uses: when it's a master
| checkbox, showing whether all of the binary checkboxes in a
| group are selected, and it may also be used on its own (the
| UI may have different actions for the three possible states).
| Calzifer wrote:
| The first time my mother encountered a toggle she tried to
| actually slide it. I also once saw a website which replaced in
| a redesign checkboxes with toggles where the cursor changes to
| a "grab hand" but of cause you cannot grab and slide them need
| to click it. Imo it is not intuitive that you have to click
| toggles and they magically start sliding but you cannot slide
| them.
| Findecanor wrote:
| I've encountered many toggle switches where you _can_ grab
| the knob and drag it, but just clicking it will toggle it
| too. Sometimes the cursor has changed to a _pointing_ hand.
| Y_Y wrote:
| My particular cultivar of ADHD doesn't have a problem with
| check boxes, and in fact I dislike toggles for some reason I
| can't quite identify. That alone is not a very useful
| anecdatum, but I'm having trouble figuring out what it is that
| would cause different adhdemons to favour the toggles.
|
| There is a nice visual distinction for toggles, as if you have
| an "On" and "Off" column for each option. Then again that idea
| would have a conflict where it should be a radio circle because
| you can't be both On and Off, but a checkbox square because
| more than on option (row) could be On. Maybe a shape with a
| flat top and rounded sides (a "stadium") would be good for
| following the conventions while being worse and more confusing
| overall.
| masklinn wrote:
| > in fact I dislike toggles for some reason I can't quite
| identify.
|
| For me it's that the "on" and "off" state are styled
| inconsistently and can be difficult to guess without
| toggling. Whether a checkbox is checked or not is never in
| question.
|
| > There is a nice visual distinction for toggles, as if you
| have an "On" and "Off" column for each option.
|
| Except there is no such column, so the visual distinction is
| not self documenting, whereas a checkbox or radio very much
| is.
| moffkalast wrote:
| Toggles are better than checkboxes imo, but checkboxes are a
| lot harder to mess up design-wise. It's really easy to make a
| toggle that makes it completely impossible to tell if it's on
| or off.
| vasvir wrote:
| Nice Article with a lot of research to gather all these
| screeshots that sent me down the memory line.
|
| What can I say? The world (of computing) changes under our feet.
|
| Nostalgia on Sunday morning...
| ggm wrote:
| In a similar vein, try explaining to a senior with fading skills
| that under material design literally nothing is a clue that a
| region on your screen is a button you can press.
|
| Only prior use can inform what is active, and what is not.
| Dalewyn wrote:
| I am a mid-30s senior by this definition.
|
| Well, maybe I am a senior. I know I spend far more time
| screaming at clouds nowadays and grow increasingly distant from
| what kids today are into.
| sph wrote:
| I don't blame the kids: the brutalist yet colorful zoomer UI
| design is much easier to parse for 30 year old seniors than
| the flat UI/material crap our generation created.
|
| I have no way to defend this argument but my eyes, but I can
| say that Google's Material design is the most bland, insipid
| of them all, and I would rather see Bootstrap again than
| another Material-inspired with its white cards on white
| background and tap animations. Just kidding, Bootstrap was as
| bland.
|
| I miss Windows 2000 every day.
| zilti wrote:
| What is that zoomer UI you are referring to?
| sph wrote:
| I have heard it referred that way, I didn't use zoomer as
| a slur.
|
| I can't think of any example off my head, but I remember
| mention of a striking online clothing store with bold
| colours, thick black borders and large fonts that's very
| popular in that age range.
|
| From a quick search on google:
| https://thedigitalmaze.com/blog/three-awesome-ui-design-
| tren...
|
| See also the design for Gumroad: https://gumroad.com/
| zilti wrote:
| Ah, _that_ is what that design is called? Heh. I 've seen
| it, among other names, also been referred to as
| "chalkboard design". It also reminds me quite a bit of
| the style you use when drawing on flipcharts, and
| actually of 90s web design; the good parts of it, that
| is. I like the ideas behind it and the clarity, but I
| think everything tends to be hideously oversized on it.
| hydrolox wrote:
| Commonly called neo-brutalist ui, iirc. The only issue I
| have (well not only, but main), is that many have really
| really large text and it's hard to read. For example:
| gumroad
| KTibow wrote:
| At least M3's cards are slightly tinted
| Smoosh wrote:
| And making it worse, past experience with other apps cannot be
| relied upon.
| arcanemachiner wrote:
| And the UI completely changes every year or three, because
| progress or something.
| wolpoli wrote:
| Don't forget to explain that some buttons are inside faint pill
| shaped shading (or it could be a search field in which they
| could tap without consequence) and that chips (to show options
| for a specific context, so they could tap without consequence)
| are rounded rectangles.
|
| Except if the site is still on Material Design 2, then it is
| the reverse in which some buttons are inside rounded rectangles
| and that chips are inside pill shaped shading.
|
| Are we confused yet?
| Tempest1981 wrote:
| Can you share a picture of this?
| demondemidi wrote:
| > a senior with fading skills
|
| Recently had to help an aging parent use their phone to obtain
| medical care: an app was required to access their MyChart to
| get a message from their case manager. Having to explain what
| is "clickable" is infuriating. The race for UX/UI novelty is
| leaving seniors behind, which is tragic since hospitals are
| pushing them online.
| Tempest1981 wrote:
| What does the 2035+ version of this look like? Seniors pushed
| to VR UIs?
| demondemidi wrote:
| I hope not for my sake! Whatever it is I hope it is more
| reliable and HELPful. I expect it will be more seamless
| authentication with more general accessibility. Meaning I
| hope I feel safer proving who I am to the nurse at the desk
| without having to open a gadget I can barely focus my eyes
| on, and that the nurse will have the most up to date info.
| That's really all that is missing, sounds easy but it's a
| cluster fuck of record management. Note that digitally it
| is better today than it was 30 years ago.
|
| I think apps will die but not by 2035, probably 2055. Apps
| are fucking stupid and antithetical to the web IMHO.
|
| Oh and I hope phone trees die a horrible death especially
| ones that don't immediately put you through to a human. The
| biggest pain due to cost savings is not being able to get
| help via a goddamn phone call that doesn't go to a call
| center, or worse: a disconnect at the end of a long tree of
| number presses.
| resolutebat wrote:
| The annoyance this causes is not limited to seniors.
| WesolyKubeczek wrote:
| I have to argue that it's not the senior's skills that are
| fading.
| divbzero wrote:
| It's definitely not just seniors. If you watch young kids use
| apps, they tap all over the screen to figure out which elements
| are actually interactive.
| PennRobotics wrote:
| Android's own Gmail app is a prime example of shitty use of
| checkboxes in Material Design (or Material You or Material 3 or
| whatever the hell it's called now):
|
| There's a list of emails with a checkbox for each email on the
| left.
|
| If you want to quickly select a bunch of emails---for instance,
| to label or sort them---you quickly press all the checkboxes.
|
| If you _just barely miss_ a checkbox, you will open the email
| because you press the larger selectable region (which is, btw,
| invisible until selected---a nod toward your "prior use"
| statement) for one email where a checkbox happens to be fully
| enclosed.
|
| Now, if you are trying to label or sort some messages that have
| been opened and also some that are unread, you now have one
| extra task of going back after labeling/sorting and marking the
| one that you accidentally opened as unread---if you actually
| noticed in the first place whether it was already opened before
| you opened it!
|
| On my phone, Gmail checkboxes are about 3 by 3 millimeters. If
| I dip my finger in coffee and lightly tap the paper on my desk,
| it creates a circle about 5 to 6 mm in diameter. I've opened
| countless emails just trying to do routine sorting and labeling
| via checkbox. I know there are larger fingertips, smaller
| screens, and people with less stable coordination than mine.
|
| Google's nested, tiny checkboxes are a waste of time and a
| needless security flaw, as emails often contain info you'd like
| protected, and cameras are commonplace and usually legal, so it
| doesn't matter if you are quick to close the message you
| suddenly opened outside of your home.
|
| The alternative? Hold each message until the checkbox
| populates, which is noticeably slower but lowers the likelihood
| you accidentally open a message.
|
| I don't understand why the Gmail "open this message" region
| isn't a full 5+ mm right of the checkboxes (except _maybe_ at
| smartwatch resolutions). They shouldn 't be enclosed or nested
| AT ALL! Nobody reasonable is opening messages by clicking the
| little blank space to the left or top of the checkboxes. (...at
| least they weren't until they saw my statement and decided to
| do it from now on out of spite or curiosity.)
|
| I also don't know why Android Studio shouldn't/doesn't harass
| developers with "Attention! You are committing BAD DESIGN!"
| alert messages when they try to put small selectable elements
| on top of other selectable elements that perform an unrelated
| task.
| al_borland wrote:
| It sounds like this may be done in an effort to improve the
| reliability of eye tracking in VisionOS when dealing with
| checkbox, not Apple just throwing the design book out the window
| for no reason.
|
| >In general, prefer circular or capsule-shape buttons. People's
| eyes tend to be drawn toward the corners in a shape, making it
| difficult to keep looking at the shape's center. The more rounded
| a button's shape, the easier it is for people to look steadily at
| it. When you need to display a button by itself, prefer a
| capsule-shape button.
|
| https://developer.apple.com/design/human-interface-guideline...
| Mtinie wrote:
| I may be missing a fundamental point of your comment or from
| the linked content, but given the minuscule number of users
| who'd be concerned with this in practical presentation, I
| sincerely hope that the UXers involved didn't optimize for this
| use case.
| al_borland wrote:
| From the OP's article:
|
| >Apple is the first major operating system vendor who had
| abandoned a four-decades-long tradition. Their new visionOS
| -- for the first time in the history of Apple -- will have
| round checkboxes.
|
| So the death of the square checkbox they are predicting is
| only in the context of VisionOS. Apple's HIG explain why this
| decision was made (my link), so I don't think it is part of a
| larger trend and we shouldn't expect it to impact anyone not
| using VisionOS, or other such headsets with eye tracking. It
| was done for technical reasons relating how the person will
| interact with the device, not style reasons.
| hulitu wrote:
| > Apple's HIG explain why this decision was made (my link),
| so I don't think it is part of a larger trend
|
| After seeing everybody adopt the Android flat UI (win 10),
| i really think that stupidity is contagious.
| tadfisher wrote:
| Do you not remember when Apple started this trend with
| iOS 7?
|
| https://en.wikipedia.org/wiki/IOS_7
| andirk wrote:
| I think UI in general is changed so often for no reason
| other than because it's like art to the UI staff. And
| then others follow thinking that there is a good reason
| for those changes made by Apple or whomever. And some
| FOMO in there too.
| troupo wrote:
| > Apple's HIG explain why this decision was made
|
| Honestly, I wouldn't trust any modern Apple HIGs. After the
| UX butchery of BigSur they retroactively updated the HIGs
| to justify their decisions.
| n2d4 wrote:
| It's not a "minuscule number" because visionOS is controlled
| by looking at things and pinching your fingers. If people
| subconsciously stare at the edges of a square button, can you
| imagine how often they'll misclick? (mispinch?)
| layer8 wrote:
| Controls are highlighted in visionOS when you focus on
| them, making it clear when the pinching will or won't work.
| mrguyorama wrote:
| Other eyetracking software solves this and all related
| problems by simply showing you a pip of some sort where it
| senses you "looking". It's stupidly intuitive, low
| intrusiveness (and can go away when it senses you don't
| need to "look" at anything like when you are looking at a
| movie screen with no controls on it) and works just fine.
| Only Apple decides the solution to their broken UI is to
| break more of the UI.
| demondemidi wrote:
| I'm glad you actually brought a reason to this debate. Not sure
| I agree but there is at least a reason.
| kibwen wrote:
| Even a rounded rectangle would be more distinguishable than a
| circle. This is a poor excuse that decreases usability
| masquerading as an increase to usability.
| musha68k wrote:
| "The sudden realization that the throne was empty."
| Y_Y wrote:
| Is this a biblical reference?
| FrontierProject wrote:
| No.
| lucasban wrote:
| Looks like a misquote of a Slavoj Zizek tweet from 2016
| right after the U.S. election? That's as far as I got
| with 2 minutes of digging.
| endofreach wrote:
| Great point. Very disappointing to read an critique that tries
| to appear thoroughly thought through, but not even considers
| that the company that has been very consistent in UX design
| choices, might have thought about what they're doing in a
| system, that probably requires fundamentally different
| approaches to UX.
|
| I mean: > Apple is the first major operating system vendor who
| had abandoned a four-decades-long tradition. Their new visionOS
| -- for the first time in the history of Apple -- will have
| round checkboxes.
|
| And yet the author is too lazy to think about that this might
| have a reason other than "they're stupid, look at all my
| screenshots, i know better than them".
|
| Btw: not saying i agree with this decision. But why even take
| the time to write when not trying to actually think about what
| you're criticising?
|
| Laughable.
| toyg wrote:
| Dad must know better, surely! It's absolutely impossible that
| almighty Apple is now full of subpar UX wannabes.
|
| Apple design has been on a downright trajectory for a long
| time now, basically since Ive was promoted to the very top
| (yes he left now, but the damage was done). The Peter
| Principle doesn't make exceptions.
| MichaelZuo wrote:
| If someone spends over an hour writing a blog post than the
| normal expectation is that they at least spend a few
| minutes confirming the point based on information, or lack
| of, in publicly available resources, such as Apple design
| documents.
| endofreach wrote:
| Well i wasn't defending apple as if they wouldn't make
| mistakes or couldn't be led by people who don't know what
| they're doing. My point had nothing to do with the design
| choices themselves. But if the point isn't obvious, there
| is no point to be explained.
|
| Apple & elon musk make people on HN act so weird. Sad.
| wonrax wrote:
| Totally agree. I'm surprised that a post making a big claim
| with little research and shallow content like this got to the
| frontpage with over 800 upvotes. Sad you're being downvoted
| too.
| endofreach wrote:
| Thanks. I am baffled by the downvotes. It is not even about
| the design choice.
|
| Like i just said in another comment: apple & elon musk make
| people on HN act weird.
| brettermeier wrote:
| You get downvoted because you argue that Apple definitely
| has a great idea behind the change. Why do you think
| that? And what are they doing about the fact that
| checkboxes now look like radio buttons? All you're doing
| is paying homage to Apple without contributing anything
| meaningful.
| endofreach wrote:
| > You get downvoted because you argue that Apple
| definitely has a great idea behind the change. [...] All
| you're doing is paying homage to Apple without
| contributing anything meaningful.
|
| Yeah, no. Not at all. But if you still don't get that my
| comment has absolutely nothing todo with the design
| choice itself a t a l l , it's truly pointless.
| Asooka wrote:
| Well, the checkmark itself is pretty angular and hard to look
| at. I think we should take a page out of East Asian visual
| language and adopt the circle as the "yes" mark. That is, radio
| buttons and check boxes should look like this:
| ( ) Radio button off (*) Radio button on ( )
| Checkbox off (O) Checkbox on
| gcr wrote:
| It isn't clear which is which if they all are unchecked
| shrimp_emoji wrote:
| So we reduced surface area of elements and made GUIs worse to
| accommodate disability. Wasn't that Apple's MO all along?
| eviks wrote:
| While the checkbox is less confusing than a lot of toggles (eg,
| the ones in Windows' settings are bad), relying on the
| unintuitive distinction between a circle and a square is just one
| of those bad old UI traditions that, I guess, persist until the
| next tech generation, little to love here.
|
| The better UI would be for the circles to be visually connected
| somehow to illustrate that only one selection is possible like
| you have in physical switches with more than two positions
| saghm wrote:
| > The better UI would be for the circles to be visually
| connected somehow to illustrate that only one selection is
| possible like you have in physical switches with more than two
| positions
|
| This is an interesting point. Radio buttons are kind of weird
| in terms of their initial position because unlike with
| checkboxes, there's no way to get back to the "empty" state
| where none is selected. It took me a bit to wrap my head around
| what you described, but the more I think about it, the more it
| seems like a "slider" with clearly marked stopping positions.
| If it's too confusing for people to have some sort of "default"
| option, maybe having a different color for the part of the
| slider that's moved based on whether it's in a valid position
| could help; at the top of the slider, it could be one color
| indicating "must be moved", and then when you slide and drop it
| at one of the marked options (or click the option; it could
| move automatically to the position like a scrollbar), it
| changes color to show it's valid.
| wruza wrote:
| Radio buttons are always one-of. Initially unselected is just
| a bug.
| 8n4vidtmkvmk wrote:
| Not always. I've seen plenty of forms that are like "only
| fill this section out if XYZ" and if you accidentally start
| before reading that you're screwed.
| eviks wrote:
| Could be a slider with the same radio circles denoting the
| stopping position, could be those circle volume buttons with
| labeled marks, could be non-circle switches like these
| (other/position/steer on the right) https://img1.wsimg.com/is
| team/ip/b81ca6f4-730a-4561-852c-096..., etc
|
| Re. the missing default - you can have an explicit element
| "none selected" with the slider positioned there
|
| Plenty of options to make UI more intuitive
| xg15 wrote:
| Microsoft briefly experimented with this, in the "security
| zones" dialog in Windows XP:
|
| http://hs.windows.microsoft.com/resbox/en/6.2/main/9f04b9c9-.
| ..
|
| It's not the exact design you describe: The slider is there,
| but only the label of the selected option is shown, the other
| options are only represented as tick marks.
|
| I think there are two problems with the design though, (which
| would also still be there if all labels were shown):
|
| - The slider widget back then was normally used for selecting
| continuous numeric or at least interval scaled input values:
| That's what the mechanism of dragging it with the mouse was
| developed for. It _could_ be configured with a small number
| of discrete values as options, but then dragging became
| awkward: Either the ticks were spaced very far, then you had
| to drag the cursor a long distance before there was any kind
| of visual feedback at all - or the ticks were spaced closely,
| like here, but then dragging the slider to one specific tick
| became difficult.
|
| - It's possible to click the slider, but there is no visual
| indication that you can do so. In fact, the visual indicators
| are almost inverse to how you'd need them: The selected
| option has a big handle that you can _not_ click (only drag),
| the unselected options have no handle though you _can_
| actually click on the empty slider bar to move the handle in
| that direction.
|
| I guess that's why they never did this again after this one
| try - which is sort of a pity, because you could probably
| build a redesigned slider widget optimized for discrete input
| that solved those problems.
| 8n4vidtmkvmk wrote:
| But if it was implemented the way the parent poster said
| then it would be much more clear the discrete points are
| clickable.
| Oanid wrote:
| Microsoft leveraged this design once more with the UAC
| configuration screen.
|
| https://techcommunity.microsoft.com/t5/image/serverpage/ima
| g...
| laurent123456 wrote:
| > The better UI would be for the circles to be visually
| connected somehow to illustrate that only one selection is
| possible like you have in physical switches with more than two
| positions
|
| Normally they are within a radio button group so that they are
| visually connected: https://i.stack.imgur.com/03p3T.jpg
| eviks wrote:
| Nope, this group tells you nothing about the fact that these
| are mutually exclusive, you could just as well group
| checkboxes because they are all related to some "Icon"
| zilti wrote:
| That's why the idea is that radio buttons are round, and
| checkboxes are rectangular.
| wruza wrote:
| Your disrespect for tradition will vanish the moment you'll
| feel old and software that you were proficient with becomes
| inaccessible chunk of nonsense for no clear reason.
| eviks wrote:
| Or my disrespect for tradition will get reinforced when the
| old chunks of nonsense are replaced with something I can get
| proficient even when I feel old for the clear reason that
| it's so intuitive even the old folks can grasp it
| 8n4vidtmkvmk wrote:
| That's not the direction we're headed in though.
|
| Some things are swipeable with no indication, or long
| pressable with no indication, we've removed scroll bars
| almost everywhere so no indication that something is
| scrollable unless the content gets cut off and you have
| reason to try to get to the rest of it, but sometimes it
| aligns nicely so you assume that's the end. Links and
| buttons we not only removed the underlines from but now
| they're grey which historically meant disabled... So no,
| none of this is intuitive.
| wruza wrote:
| We'll celebrate this day all together! Meanwhile, let's
| make life for older people harder, cause round checkboxes
| are so much more proficient. /snark
| moffkalast wrote:
| Best joke I've heard this week.
| Findecanor wrote:
| For mutually-exclusive buttons with the labels _inside_ the
| buttons, there _exists_ such a convention: Group the buttons
| together with no space between them. Sometimes, the corners of
| the buttons at the far edges are rounded but the lines between
| them are not. You will often see these in word processors, for
| aligning text ( left | centred | or right ).
|
| A related issue with radio buttons and check boxes is that in
| _some_ GUIs, clicking the label next to the box /button also
| clicks the widget, but there was no visual indication that that
| is the case. Sometimes the clickable area even extends the
| whole width of the window. This carries the risk of users
| making a selection when all they wanted to do was to click the
| window in a _seemingly_ _inactive_ area to make it come to
| front.
|
| I think we could solve that issue and visually connect radio
| buttons by placing them onto a background rectangle with
| rounded corners -- thus adapting a visual cue from the button
| group widget. Then highlight the background portion that is
| clickable when the mouse hovers over it, and when the
| button/area gets clicked. Further, you could choose to make the
| colours consistent with those you'd use for selecting items in
| lists.
| eviks wrote:
| The text alignment buttons work because you know you can't
| have both centered and left, otherwise relying on subtle
| spacing would mostly signal some connection, not mutual
| exclusivity (similar to how those | symbols group related
| buttons together)
|
| One solution to selectable labels would be to add the indeed
| missing indicator, e.g., you could have the whole label have
| a border when it's active (though in this case maybe you
| don't need radio buttons, but just have multiple lines that
| look like distinct lines?)
|
| Hard to access the background group, I know it doesn't work
| if it includes labels like in the screenshot in another
| comment, but maybe only for buttons it'd be more
| understandable
| chrismorgan wrote:
| I _thought_ there was an actual difference in presentation
| back in the days toolbar buttons actually had borders, but
| no, when you look at https://winworldpc.com/res/img/screens
| hots/6x-a08a659bdbb00f..., Word 6, you see it's all just
| simple grouping of toolbar buttons, nothing to do with
| mutual exclusivity at all: New|Open|Save,
| Print|Preview|Spellcheck, Cut|Copy|Paste|PasteFormatting
| (if my memory serves me correctly?), ...,
| AlignLeft|AlignCentre|AlignRight|Justify,
| Numbered|Bulleted|Dedent|Indent.
| eviks wrote:
| I thought it was true when compared alignment group with
| bold/italics, in the Word Ribbon UI they do seem to have
| less space separating them, but then in Wordpad the
| paragraph button next to alignment group seems to have
| the visually very similar space width and the icon is
| very similar, so there is no way such poorly perceptible
| convention helps even if it does exist
| hulitu wrote:
| I agree. What the world needs, it is more circles. Damn those
| rectangular monitors. /s
| squarefoot wrote:
| Not to mention the confusion arising from checkboxes in web pages
| used in place of checkmarks. A checkmark alone should be the
| correct object to use for output only, while a checkbox normally
| would accept an input from the user. I don't recall where, but
| have seen this some times around the web and found it misleading.
| sumuyuda wrote:
| I think the difference with the square checkbox is that it is for
| desktop UIs and clicking with a mouse. The circle checkbox is for
| mobile UIs where you are tapping with your finger.
| emayljames wrote:
| It removes the ability to instantly know whether you have a
| multiselect situation or a select-one situation.
| hulitu wrote:
| It doesn't matter. The user is an idiot. Just make sure that
| he enters its credit card details correctly. /s
| mseepgood wrote:
| You can't tap a square with your finger?
| steezeburger wrote:
| You might cut your finger on the sharp corners
| antonyme wrote:
| Great article, and terrible idea. Wonder why the UI guidelines
| were bent here.
|
| It's astonishing how many web designers have no idea about the
| difference between inclusive and mutually exclusive options.
|
| I see checkboxes used all the time when they should be radio
| buttons. It's not rocket surgery.
| https://www.nngroup.com/articles/checkboxes-vs-radio-buttons...
| tussa wrote:
| All in the name of simplicity. Eventually Apple devices will
| just have one button that says "give us money".
| tialaramex wrote:
| Pressing a button would be optional. No need to give Apple's
| customers a confusing choice - just transfer all their money
| to Apple who can prioritise Apple's needs appropriately.
| 5- wrote:
| the technology is already there[0].
|
| we're just a few reforms[1] away from having that
| commercialised.
|
| [0] https://pubmed.ncbi.nlm.nih.gov/3492699/
|
| [1] https://reason.com/2021/04/03/abolish-the-fda/
| vitiral wrote:
| The MacBook Wheel!
|
| https://youtu.be/9BnLbv6QYcA?feature=shared
| ClassyJacket wrote:
| That's called a poker machine.
| __MatrixMan__ wrote:
| I think they're smart enough to stop at: "press this and
| we'll take your money and tell your friends you're cool."
| robador wrote:
| > Rocket surgery I'm gonna use this as the superlative of
| rocket science
| code_biologist wrote:
| I suspect that phrase may be a oblique reference to the
| absolutely lovely UI testing book "Rocket Surgery Made Easy:
| The Do-It-Yourself Guide to Finding and Fixing Usability
| Problems" by Steve Krug.
| stavros wrote:
| We've been using "rocket surgery" as a portmanteau of
| "rocket science" and "brain surgery" for decades, though.
| almostnormal wrote:
| The use of that mixture of rocket science and brain surgery
| predates that book from 2009 by at least 15 years.
| EasyMark wrote:
| The first time I heard it was on "trailer park boys" as a
| "Rickyism" so I suspect it would sneak into more people's
| vocabulary that way. No idea which came first.
| abraae wrote:
| Much as I love a good rant like this, I have to wonder if this is
| just the world moving on.
|
| I used to hate it (still do a little) when I toggle a checkbox,
| then go to hit "Save" and realise that the checkbox had immediate
| effect.
|
| Now I observe that this is almost the norm. I guess I need to get
| over it.
|
| I also hate it when people changed the scrollbar behaviour in any
| way. Then today I realised that one of my micro-frustrations with
| eclipse is that some UX genius decided to make the scrollbars
| fade away if there is inactivity. (Inactivity of a few seconds in
| an IDE is pretty normal - it represents thinking!).
|
| But then I reflect that eclipse is a hard core programming tool,
| used by exactly the kind of people I would have expected to hate
| on this kind of thing. Instead, it seems that this highly
| technical audience is OK with this.
|
| This article is absolutely on the money, and using rounded
| checkboxes is deliberately sabotaging one of the few strong
| mental models that we are able to hold about a UI.
|
| But maybe this battle is over, and the UX enshittifiers have won.
| demondemidi wrote:
| > hard core programming tool
|
| lol. eclipse is a bucket of rusty panels held together with
| duct tape, but embedded companies that can't afford software
| devs and have never heard of UX/UI cling to it.
| Kwpolska wrote:
| Eclipse is a hardcore masochism tool, try IntelliJ IDEA for
| Java or just about anything else.
|
| That said, is this behaviour actually Eclipse's, or is it
| following the settings of your OS? Windows 11, macOS, and
| probably some Linux things, decided that scrollbars are not
| cool and should be hidden or shrunk -- but there should be an
| option to disable that (in Accessibility settings in Windows,
| in Appearance on macOS). Eclipse might also have its own
| setting.
| hulitu wrote:
| > if this is just the world moving on.
|
| It is just running in circles. It took Microsoft 3 releases to
| insert a background color selection in Win 10. I think that
| around Win 12 it will regain the option for foreground color.
| /s
| rubymamis wrote:
| Apple ditched square checkboxes long ago in Apple Notes:
| https://imgur.com/a/HLrnXn3
|
| I believe it was this way since the introduction of iOS 7 in
| 2014[1] (article from 2016).
|
| [1] https://osxdaily.com/2016/01/25/how-to-add-checklists-to-
| not...
| deafpolygon wrote:
| This may be petty, but this is one of the reasons why I don't
| use Apple Notes. The design.
| rubymamis wrote:
| I like its design - it's simple and familiar and just works.
| The circular checkboxes are annoying tho.
| sph wrote:
| I bought a Macbook in 2015 because I always loved their UI
| design. Safe to say, whatever's going on with Apple Notes was
| not what I had in mind.
|
| The best designers in the world, keeping alive the worst UI
| trend of making everything flat and white without any
| separation, border or shading whatsoever.
| Calzifer wrote:
| If I think of square checkboxes I think of sharp corners. Maybe I
| should write an article "In Loving Memory of sharp corners"
| because I definitely miss them but they seem to be extinct from
| the modern Web and GUI in general. If I skim the article only old
| screenshots contain sharp corners. None of the new once.
|
| I have a browser where I configured "border-radius: 0 !importent"
| as userContent.css for fun. Was sometimes surprised how much it
| is used. Especially how many circles are today actually boxes
| with a large border radius.
| Kwpolska wrote:
| border-radius: 50% is the easiest and most compatible way to
| make a circle in CSS.
| chrismorgan wrote:
| > _Especially how many circles are today actually boxes with a
| large border radius._
|
| HTML is all about rectangles. If you want circles, your choices
| are a straightforward CSS border-radius, or an SVG <circle>.
| And let me tell you, if you can just slap style="border-
| radius:50%;overflow:hidden" onto an <img>, or faff around with
| <svg>, <image>, <clipPath> and <circle> (or maybe you can even
| use clip-path="circle() fill-box" these days, can't remember if
| support is there yet), I know which a sensible person will
| prefer.
| annabyrd wrote:
| This made me feel warm and fuzzy inside! TY
| hi083 wrote:
| me too
| lstamour wrote:
| I'm surprised nobody has mentioned that iOS has had round
| checkboxes since forever?
| https://ux.stackexchange.com/questions/116712/apples-round-c...
|
| Likewise I thought the article's punchline was going to be the
| increasing use of on-off toggles instead of checkboxes. Like how
| the settings app on macOS now has more on-off toggles than ever
| before.
|
| Personally though, my fav pet peeve remains the unclear toggle
| button. When the icon is white, is it on? Is it off? Does the
| line through the microphone mean it's muted? Or that it mutes
| when tapped? No one knows, tap it a few more times to find out...
| cyclotron3k wrote:
| Google Mail and Google Photos on Android also have round
| checkboxes.
| ncruces wrote:
| The toggle is supposed to convey immediateness, like a light
| switch turning on bluetooth is immediate.
|
| A checkbox is like filling a form, it requires submission for
| the action to take place.
| ratg13 wrote:
| The parent comment is talking about how the colors are often
| set on a toggle.
|
| That the user never knows if the toggle is in the on or off
| position.
| stavros wrote:
| Your parent is talking about their parent's second
| paragraph, about toggles in settings.
| ratg13 wrote:
| That is what I am talking about as well
|
| > _When the icon is white, is it on? Is it off?_
|
| They reinforce this with another example of ambiguity.
|
| The user can't be suggested to take any actions if they
| can't figure out what the default settings are.
| stavros wrote:
| lstamour talked about two things, the proliferation of
| toggles, and the unclear toggle buttons.
|
| ncruces replied clarifying the former, that the toggles
| proliferate because they convey immediateness. They
| didn't say anything about the "unclear toggle button"
| point.
|
| Your comment, then, aimed to correct ncruces' comment,
| clarifying that lstamour was talking about unclear
| toggles, when ncruces was talking about the _other_ point
| in lstamour 's comment, and thus was already correct.
| rezonant wrote:
| > Likewise I thought the article's punchline was going to
| be the increasing use of on-off toggles instead of
| checkboxes.
|
| That's the second paragraph. This would be those
| left/right toggles that became popularized with iOS on
| the original iPhone (since you could physically slide
| them with your finger). These also do have color insanity
| associated, though.
|
| The third paragraph used "toggle" in a more general
| sense.
|
| To be fair, the comment has a lot going on.
| ajitid wrote:
| This assumption breaks if you use macOS. Windows uses (or
| used to use) Apply button in its settings. Macintosh OSes
| were reactive from the start. Which means that checkboxes
| have immediate-ness on Macs.
| layer8 wrote:
| The real reason is that in contexts like the Settings app,
| where toggleable items are mixed with other items, checkboxes
| on the left would take too much space on mobile (especially
| on the early small-screen iPhones), because it would require
| the left margin to be increased for all items. Checkboxes on
| the right are awkward though, and thus were replaced by the
| toggle switches. The immediateness argument is just a
| convenient excuse. Immediately-effective checkboxes weren't
| uncommon on desktop before. In addition, there is "previous
| art" in the form of boolean-toggle menu items that are
| immediately effective and show a checkmark when active.
| mr_toad wrote:
| That was true in the 90's when you'd post a whole page but
| these days the individual checkboxes are more likely to have
| event handlers that transmit state to the server immediately.
| boomlinde wrote:
| _> That was true in the 90's when you'd post a whole page_
|
| I'd say that to the extent that is true, it was equally
| true for radio buttons in the 90s.
|
| These days I find myself scrolling around pages to look for
| submit/save/apply buttons to determine whether checkboxes
| and radio buttons are intended to have immediate effects or
| have to be submitted to be applied, because there really
| seems to be a lack of consensus on what these elements mean
| in those terms.
| weinzierl wrote:
| On iOS the toggles are off left, and shown as dim grey. They
| turn green when you shove them to the right into the on
| position. That's about as much as my brain can process.
|
| In many other environments these clues are more subtle or
| completely absent and I never know which is which.
|
| I don't necessarily wish my check-box back, because I think a
| slider is easier to handle on touch devices[1], but it should
| be done in a way that indicates the status clearly. Apple's use
| of color is also not perfect, but at least they did not fall
| into the trap of using red and green. Light grey and vibrant
| green should be distinguishable for most people with color
| deficiencies even.
|
| [1] At least when implemented properly. I am looking at you
| Ninebot. Your huge on/off slider only let's me turn off my
| scooter when the stars are aligned right. I don't even bother
| anymore and just use the button on the scooter.
| rezonant wrote:
| > because I think a slider is easier to handle on touch
| devices
|
| I guess because the toggle has more real estate for you to
| tap? If so, then couldn't you just make the checkbox bigger
| and get the same ergonomics?
| hermitcrab wrote:
| I find toggles very confusing. Is it showing the current state,
| or what happens when I toggle the state?
| dspillett wrote:
| This doesn't need to be the case, though depending on context
| extra design elements (colour, descriptive text, ...) may be
| needed to make the interpretation truly unambiguous.
|
| Sometimes (advert stalking preferences being the key example)
| the confusion is very deliberately not dealt with, and
| furthermore on occasion extra steps are actively taken to
| ensure the confusion.
| rezonant wrote:
| White/black "indicators" of toggles are horrid. A lot of phone
| and meeting apps do this and it's horrible.
|
| As for mute, I think it's pretty objective at this point that
| an icon based toggle should show the current state, not the
| state that tapping on the icon will produce. That's because the
| icon is serving two jobs: Convey the state and let the user
| change it. When a developer gets this wrong and shows a crossed
| out speaker while audio is playing, that's just frustrating.
| Y-bar wrote:
| > As for mute, I think it's pretty objective at this point
| that an icon based toggle should show the current state,
|
| I can't see this holding up as the primary UI rule. And
| exceptions only for things like mute toggles are seldom a
| good thing in interfaces where predictability should be the
| king. It breaks down on play/pause toggles. The answer in my
| opinion is to separate the concern of the action and the
| state and distinctly show both at the same time.
| rezonant wrote:
| That's true, but I just can't live in a world where mute
| goes the opposite way. I'm not aware of a major media
| player that doesn't cross out the mute when audio is muted
| (assuming it uses a crossed out icon at all).
|
| I also can't live in a world where play/pause is opposite
| to the way it is now: play icon should mean the media is
| paused, pause icon should mean the media is playing, as you
| suggest.
|
| If we constrain ourselves to only having two buttons (one
| play/pause, one mute/unmute), and only differentiating them
| by the shown icon, then I'm afraid it just has to go with
| the convention. They are inconsistent with each other, but
| intuitiveness beats consistency I guess.
|
| > The answer in my opinion is to separate the concern of
| the action and the state and distinctly show both at the
| same time.
|
| I don't think this is practical, especially on mobile.
| There is a need for these UIs to be concise, and even if
| there is enough space, each visual element comes at a
| cognitive premium to the user.
| Y-bar wrote:
| > each visual element comes at a cognitive premium to the
| user.
|
| As someone who studied two years of cognitive sciences as
| part of my degree, this is not necessarily true. Lack of
| information can often lead to even more cognitive load as
| the user then has to imagine virtual scenarios, an
| cognitive process which is linear. Visual processing
| however is largely parallel, faster and less consuming,
| as we have evolved to live in a visually complex and
| noisy environment.
| rezonant wrote:
| Fair, but I think there's a middle ground here, obviously
| an entire screen of buttons on top of a video occludes
| the content that you want to watch. Even if our visual
| cortex can handle it, I don't think its desirable if it
| can be avoided.
|
| Of course, admittedly if all you have is a play button
| and a mute button (or some other very simple player) it
| probably doesn't matter much.
|
| I think Twitch's UI is a good example of where the
| clutter goes too far. It's loaded with tons of
| distracting bits and bobs. Makes sense for their business
| model (most of these relate to how you can spend money on
| the platform), but from a user perspective it's
| unpleasant.
| esafak wrote:
| Discord is the same. They target kids, and kids love
| things that repel adults, like confusing user interfaces.
| waqf wrote:
| The mute on the touchbar on my MacBook Pro has a slash
| when unmuted (and also when muted).
|
| It looks like this unmuted: https://discussions.apple.com
| /content/attachment/e909bffc-81...
|
| and this muted: https://discussions.apple.com/content/att
| achment/e3e9c230-e4...
|
| I believe the reason it always has the slash is to
| distinguish it from the "change volume" button (which,
| when pressed, pops up a volume slider). But it's still
| confusing.
| thaumasiotes wrote:
| Traditionally, the play / pause button is labeled with
| both icons. It has no need to display state, because the
| state of playing or being paused is obvious to the user.
| That button would be telling you the same thing you see
| by watching your video.
|
| But a mute indicator isn't telling you how other people
| appear to you. (That would be "deafen".) It's telling you
| how you appear to other people, which you have no other
| way of knowing.
| SamBam wrote:
| > I think it's pretty objective at this point that an icon
| based toggle should show the current state, not the state
| that tapping on the icon will produce.
|
| What about a play button? On YouTube, or any music app, the
| button will show the Play symbol when the media is paused,
| and the Pause symbol when the media is playing.
| albert_e wrote:
| When a button displays the text "mute" ... does it mean that
| the status is CURRENTLY muted, or that pressing that button
| will make it MUTE?
| Y-bar wrote:
| Yep!
|
| When the _state_ and _action_ are intermixed it becomes
| ambiguous. This is one of may things we lost in the war on
| skeumorphism. The skeumorphic interfaces could mix both more
| clearly, using shading and texture and "lights" to indicate
| that a play button was pressed down and active.
|
| Look at this UI, it's mix of state and action:
| https://discussions.apple.com/content/attachment/861693040
|
| fast backward rewinds: Probably showing action
|
| Play: 100% ambiguous if action or state
|
| fast forward: Probably showing action
|
| Volume slider: showing state
|
| Back-forward buttons: showing action
|
| Select drop-down: Showing state
| iamtedd wrote:
| As someone who has no experience with this version of
| iTunes:
|
| - The lower row is definitely a row of buttons. Back,
| forward, categories in the library (?), I don't know what
| the last one is supposed to do.
|
| - Are the things above that row buttons? Why don't they
| look like them then?
|
| - If they are, what does fast forward and rewind do? Skip
| to the next track and to the beginning of the same track?
| Actually move quickly through the track (like fast forward
| and rewind used to do)? Does pressing rewind go to the
| beginning of the track or to the previous track? If it's to
| the same track, how quickly do I have to click again to go
| to the previous track?
|
| - Is that slider a progress bar or volume slider?
|
| - Where do I click and drag to move the window? If it's in
| that top row, why are there things cluttering up the title
| bar? How much space do I have left to move the window?
|
| - I assume the coloured things are the window management
| controls. Does clicking the red one close the window and
| keep the music going, or does it stop?
| Y-bar wrote:
| > what the last one is supposed to do.
|
| It's indicating an iOS device being locally, e.g. for
| administration, backup, file transfer and the like.
|
| > Are the things above that row buttons? Why don't they
| look like them then?
|
| Haha yeah. That's modern Apple for you!
|
| > what does fast forward and rewind do?
|
| They sort of behave the way ff and fr does on a remote.
| Click/press fast and you skip to the next/previous
| song/chapter or equivalent. Hold down and you scrub at
| something like 4x speed.
|
| > Is that slider a progress bar or volume slider?
|
| A volume slider.
|
| > Where do I click and drag to move the window? If it's
| in that top row, why are there things cluttering up the
| title bar? How much space do I have left to move the
| window?
|
| I ask myself the same thing every day and have the same
| problem with many many apps, also in Windows. For example
| Firefox has the same design problem where its buttons
| have nor border and therefore have no clear place where
| draggable top space is and button is.
|
| > I assume the coloured things are the window management
| controls.
|
| Yes, these have remained mostly unchanged for over 20
| years, they have gotten a bit flatter and lost some
| subtle small iconography.
|
| > Does clicking the red one close the window and keep the
| music going
|
| At least this part works well and in a predictable
| fashion. It consistently follows Apple's Human Interface
| Guidelines since well over 30 years: Closing a window or
| document of a Mac OS application should not quit the
| application. (there are some exceptions, but that is the
| default behaviour).
| Muehe wrote:
| > For example Firefox has the same design problem where
| its buttons have nor border and therefore have no clear
| place where draggable top space is and button is.
|
| This can be changed by going to "about:settings" page and
| setting the option "browser.tabs.inTitlebar" to 0.
| Y-bar wrote:
| That about:config setting is a halfway okay solution for
| a single app, it loses vertical space however, which is
| my premium. Optimally I would like a way to (in all
| applications which has this problem) to _simply show me_
| what is a UI widget/button and what part is "inert"
| draggable window chrome, like this older screen shot
| where the distinction is unambiguous and clear:
|
| https://i.stack.imgur.com/Se6i0.png
| joe_guy wrote:
| It's actually trivial for a website to fill up that space
| with invisible tabs, too.
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=1749835
| dylan604 wrote:
| > what does fast forward and rewind do?
|
| symbols in "traditional" media playback, the icon shown
| would traditionally be for fast reverse/forward. skip
| back/forward to the previous/next would had a vertical
| bar to the point of the triangle. some also go so far to
| differentiate skip/scanning where scanning uses two
| triangles while skip uses one triangle with the bar. not
| really sure what Apple has done to them though. i would
| almost _expect_ them to be skip instead of the scan with
| Apple expecting you to use the playhead (in whatever
| format it is made available) for scanning.
|
| the play button in Apple's use is typically action
| instead of state. so in this state, clicking it would
| start play, and then the button changes to the "pause"
| symbol (an = rotated 90deg).
|
| so this is a really good example of mixing usage.
| phkahler wrote:
| >> This is one of may things we lost in the war on
| skeumorphism. The skeumorphic interfaces could mix both
| more clearly, using shading and texture and "lights" to
| indicate that a play button was pressed down and active.
|
| I suspect a lot of the choices also have to do with saving
| screen space, but in the end a checkbox is one of the best
| ways to indicate "enabled" on a settings screen.
| joenot443 wrote:
| I'm designing an app right now with this pattern and I'd love
| to get it "right".
|
| We've got a video playing and an icon button which controls
| whether the video is muted. We've got a "playing speaker" and
| a "muted speaker" icon.
|
| What's the correct pattern? Should the icon reflect the
| current state, or the expected state after pressing the
| button?
| snet0 wrote:
| I think, bizarrely, the control pattern for mute "flows"
| the opposite way to the control for pause/play. If there's
| a play icon, and you click it, you expect it to play the
| video. If there's a pause button, you expect it to pause
| the video. Going against this pattern, if I see a speaker
| icon, and I click it, I expect it to transition to a
| crossed-speaker, and mute the video, and vise versa. That
| is: the current button state in play/pause reflects the
| _action_ of the button, while the current button state in
| volume reflects the _state_ of the button.
|
| I think these conventions are easily solved for video,
| anyway, because it's obvious when the video is muted or not
| (hopefully).
| onionisafruit wrote:
| > it's obvious when the video is muted or not
| (hopefully).
|
| It isn't always obvious to me. Sometimes I can't tell if
| a video player is muted vs the system volume being low.
| There's also the situation where a video is silent and I
| don't know if I'm supposed to be hearing anything.
| skydhash wrote:
| I think these conventions come from actual players like
| VHS and walkmans. The play, pause, stop,... where actual
| buttons and mute was an icon on the status display.
| Buttons are actions while icons are state. The rare case
| where there was a mute button, it was toggleable (or have
| a led on it) and these always reflect the state.
| dylan604 wrote:
| my memory of a Walkman had a wheel for volume but a mute
| button was not something I'm familiar on this device. see
| this image for reference:
|
| https://vintomatic.com/wp-
| content/uploads/2022/11/Vintomatic...
| fireflash38 wrote:
| They frequently had a "click" at the end of the volume
| wheel that would fully mute.
| dylan604 wrote:
| In my experience, _that_ click also acted as power off.
| augustk wrote:
| One button one function if you ask Dieter.
|
| https://en.wikipedia.org/wiki/Dieter_Rams#/media/File:Diete
| r...
|
| Although not standard, I'm thinking that a slider with a
| muted speaker icon to the left and a playing speaker icon
| to the right would be unambiguous.
| dylan604 wrote:
| a dedicated mute button for single click action is much
| appreciated instead of several clicks or click-drag to
| get to the desired state
| augustk wrote:
| Sorry, I used the wrong word. I had an iPhone-style
| switch in mind which slides when you tap it.
| cpsempek wrote:
| current state - this easily generalizes to settings with
| multiple options.
| yreg wrote:
| This is the correct pattern. It's usually a good idea to
| also add a tooltip that clarifies the action (although
| that doesn't help on mobile).
| 1over137 wrote:
| Don't use icons then, use words. Words like "video is
| muted" or "mute the video".
|
| Long ago, Apple's HI group had a saying: "a word is worth a
| thousand pictures".
| xp84 wrote:
| wow, what a great slogan. It seems so far removed from
| modern, minimalist-flat-icon-obsessed design which Apple
| is now the poster child for.
| teo_zero wrote:
| I strongly disagree.
|
| In a conferencing app, for example, "mute" could mean
| switch audio off, or just the mic, or both.
|
| And consider that a word, even "mute", might not have an
| equivalent in every languages.
| dylan604 wrote:
| words take up precious real estate and makes the UI look
| congested/cluttered and is exactly the opposite of the
| desired _clean_ look. if things are more ambiguous, it is
| just something for the user to come to terms with. --Jony
| Ive in some unwritten extract of thoughts
| kps wrote:
| If you have one button, I think it has to match what people
| are familiar with, and the major players all show the
| current state. If you have a volume slider or buttons, the
| mute button is adjacent to the silent end (bottom or left
| for me; I don't know whether RTL languages flip volume
| controls).
| teo_zero wrote:
| The icon should depict a muted speaker and shouldn't
| change. Then add a LED-like dot to show when the function
| is active.
| dylan604 wrote:
| I always appreciated Mackie's Rude Solo Light. It was
| very difficult to not realize it was enabled.
| pilgrim0 wrote:
| This nails it! It's essentially equivalent to a Boolean
| property, muted = true|false.
| sgc wrote:
| Not as unambiguous as it sounds. My keyboard has an led
| that lights up when the speaker or microphone is muted.
| But the camera only lights up when it is on. Do we want
| to show when the function is active, or when the device
| being controlled is active? I would say the latter is
| generally better, since it indicates a potential
| vulnerability / exposure. But then we have to deal with
| security devices!
| teo_zero wrote:
| The LED should be on when the _function_ is on. The
| _function_ is whatever the icon depicts.
|
| If the icon is a loudspeaker, then the LED should be on
| when the audio is on; but if the icon is a microphone
| with a bar across it, the LED should be on when the mic
| is _off_.
|
| I have a button labelled "ASR OFF" in my car. Its LED is
| on when ASR is off and vice versa. I don't find it
| confusing.
|
| Another example: my TV has a standby LED. It's off when
| the TV is on, and on when the TV is sleeping. Again, I
| find it correct.
| sgc wrote:
| Then we need to standardize how we name functions. For
| example, never talk about a mute function, but just sound
| on. All function names should indicating turning
| something on, and never off, or vice-versa.
| SoftTalker wrote:
| Radio buttons: Microphone Status:
| ( ) Muted ( ) Unmuted
|
| Unambigious. Add icons if you like.
| isametry wrote:
| This solution is far from compact though, right? If you
| show it at all times, it takes space and adds clutter. If
| you hide it behind a menu, it adds extra clicks.
|
| If this was meant (semi)ironically and mainly as a
| reference to the OP link, then sorry for the earnest
| response!
| SoftTalker wrote:
| No I meant it seriously. It's clear, even if it takes a
| bit more space. And it's accessible whereas something
| like color changes on an icon are not.
| esafak wrote:
| And very inefficient.
| callalex wrote:
| The correct pattern is to use the platform's native video
| player because the user is already familiar with how it
| operates instead of reinventing the wheel with web jank.
| incrudible wrote:
| They probably have a reason why their product is not just
| a video. They need integration. Going with what the
| platform thinks should happen, if it even offers such a
| control, will probably be a UI disaster in its own right.
| phreack wrote:
| For a one-button option, I think I'd like something like a
| knob pointing to the current state (like a label saying
| ON), which when clicked would point to the other state
| (OFF). Both labels should be visible at all times. I think
| people may understand knobs. I'm an absolute fan of
| skeuomorphism but you may be able to design something more
| abstract (but that's a slippery slope so hopefully not).
| alpaca128 wrote:
| For muted audio I think a muted speaker icon on a button
| displayed in clicked/active state would be the most
| intuitive version.
|
| Aside from that roughly 100% of applications I've been
| using use the "show current state" approach in this
| specific case. I don't think I've seen a media player which
| does it differently.
| Gravityloss wrote:
| How about a slightly larger button that has a bit more
| complex graphic:
|
| (speaker emitting sound / speaker crossed over). Ie the
| button has two icons with a slash between them.
|
| One of the icons is in black outline and one is in grey
| outline. Pressing the button switches between what is black
| and what is gray.
|
| If speaker emitting sound is black, then sound is on. If
| crossed speaker is black, then sound is muted.
| Zanfa wrote:
| Canon does this everywhere in their camera UIs, e.g a button
| with "(eye-tracking icon) ENABLE". Gotta open up the full
| settings UI to remember which way it works. IIRC, they
| actually show the current state (ENABLE = ENABLED), not the
| action that will be taken when you tap the button, but I
| might be misremembering... again.
| LeonidasXIV wrote:
| I think this is because the English concept doesn't map
| into Japanese. I've seen plenty of times where shops would
| have signs/labels saying OPEN and... CLOSE.
| arrrg wrote:
| Ha! That's a surprise to me, I never noticed.
|
| So, checking out Apple's first party apps it seems that
| checkboxes are either solid color round circles (just the
| outline when unchecked) with a checkmark in the middle (for
| multi selections in lists) or just toggles (typically in
| settings).
|
| Those round checkboxes I could only find being used for list
| selections (even when the list is horizontal, e.g. when sharing
| a photo). Toggles for settings.
|
| Radiobuttons seem to always come with one element already
| selected. I couldn't find an instance of an empty list where
| you select one element. In those cases (e.g. when picking your
| WiFi network) they are just a solitary checkmark on the left
| without the circle.
|
| It's internally consistent (as I assume visionOS is, too) and
| the checkbox design in visionOS is actually closer to iOS than
| macOS. I assume that's the origin with quite some history
| behind it. Nearly two decades.
|
| I think the more exact statement would be that as far as iOS is
| concerned the checkbox already was dead for nearly two decades.
|
| As far as UI conventions go I'm not too worried. What worries
| me a bit more that this much more clearly frames visionOS (as
| well as running iPad apps) as a iOS descendant when this might
| be the platform with the space to be more clearly in the
| tradition of the Mac.
| Y-bar wrote:
| > Radiobuttons seem to always come with one element already
| selected.
|
| This Apple behaviour follows the HTML spec:
|
| > At all times, exactly one of the radio buttons in a set is
| checked. If none of the <INPUT> elements of a set of radio
| buttons specifies `CHECKED', then the user agent must check
| the first radio button of the set initially.
|
| https://www.w3.org/TR/html401/interact/forms.html#radio
| Kwpolska wrote:
| The current standard says something else:
|
| > If none of the radio buttons in a radio button group are
| checked, then they will all be initially unchecked in the
| interface, until such time as one of them is checked
| (either by the user or by script).
|
| That behaviour makes more sense for the Web, so that the
| user is required to make an explicit choice, and I'm not
| sure if browsers ever cared about this little part of the
| standard. When interacting with OS components, it makes
| sense that there's some default or already configured
| value.
|
| https://html.spec.whatwg.org/multipage/input.html#radio-
| butt...
| Y-bar wrote:
| Huh, that's odd that it got changed. I can't think of any
| valid case where [no option] checked is part of a set of
| radio buttons. The user must be presented by a default,
| their entire reason for existing as is that one of them
| is checked all of the time.
|
| Microsoft's Windows guidelines implicitly says that one
| option must always be checked:
| https://learn.microsoft.com/en-
| gb/windows/win32/uxguide/ctrl...
|
| > If none of the options is a valid choice, add another
| option to reflect this choice, such as None or Does not
| apply.
| teo_zero wrote:
| > I can't think of any valid case where [no option]
| checked is part of a set of radio buttons. The user must
| be presented by a default
|
| In a political vote, wouldn't that be untolerable bias?
| Y-bar wrote:
| I would never use a group of radio buttons in such a
| case, would you?
|
| But if hard pressed and not allowed to design a better UI
| I would do the following options with radio buttons:
|
| ( * ) blank vote
|
| ( ) Option A (potentially in random order vs other non-
| blank options)
|
| ( ) Option B (potentially in random order vs other non-
| blank options)
|
| ( ) Option ... n
| arrrg wrote:
| Why would you not use radio buttons? And what pattern
| would you use instead? I don't get it ...
|
| Radio buttons are the correct metaphor for picking one
| option among a list of options. Why use something else?
| What use interface element do you think exists that works
| for this kind of interaction?
|
| I'm honestly confused why you think radio buttons are the
| wrong type of interface element for this interaction.
| What's the reasoning as to why this seems so obvious to
| you? I'm honestly just trying to understand you.
| Y-bar wrote:
| Because voting is a multi-step process often involving
| more than one action. I have experienced all the below
| votes at governmental level, they are not hypothetical to
| me:
|
| Sometimes the voter has the ability to add arbitrary
| options to the ballot.
|
| Sometimes multiple values are allowed.
|
| Sometimes there are positional votings.
|
| Sometimes there is ranked-choice.
|
| Sometimes you do not even want to submit the vote.
|
| Looking only at "these are the options available, choose
| one and only one" is not a valid strategy for reaching
| the conclusion on what UI idiom to use.
|
| I protest against the default assumption that radio
| buttons (no matter how much I like them) should be the
| default go-to for voting interfaces because of the
| context of voting is too complex.
| arrrg wrote:
| That is such a weird perspective not at all relevant to
| this discussion.
|
| Obviously all the examples you named are not a good fit
| for radio buttons. Except maybe the last one where you
| can just add an "invalid vote" radio button choice.
|
| But that doesn't mean that for a fairly standard "pick
| one" vote radio buttons aren't a good choice! You don't
| have to be consistent within the concept of voting, you
| just have to be consistent for the one relevant use case!
| arrrg wrote:
| Surveys are a valid use case for radio buttons that come
| unchecked by default.
|
| You do not want to influence people by presenting them
| with a default (already checked) choice. (You also
| typically want to randomize the order, at least when
| there is no inherent order to the options, e.g. when you
| are asking about frequency.)
|
| Surveys are also the place where that distinction between
| single choice (radio buttons) and multiple choice
| (checkboxes) becomes most apparent because surveys tend
| to liberally mix the two, so any additional UI signposts
| you can use to help people filling out the survey are
| helpful. (The typical recommendation for multiple choice
| is to still explicitly call out in text that multiple
| options can be checked.)
|
| Surveys sometimes also have the absolutely wild combined
| list with checkboxes and - typically as the fixed last
| option even if you randomize the rest of the options - a
| radio button (e.g. "None of the above") that
| automatically unchecks all other options (and is unchecks
| itself if any other option is picked).
|
| I don't think this exists in any spec anywhere but is the
| most normal thing in the world in most survey software.
|
| I'm always very precise with whether I use checkboxes or
| radio buttons when designing surveys.
| moontear wrote:
| The articles punchline IS the use of toggle buttons?! Or have I
| misunderstood you?
| grumbel wrote:
| My "favorite" toggle button is the one where they add on/off
| labels[1] to it, but only one, and the slider hides the label.
| So the label actually tells you the state, not the state it
| would be when you move the slider over the label. Or at least
| that's how I think how they work, it breaks my brain a little
| whenever I look at them.
|
| [1]
| https://itsfoss.com/content/images/size/w1000/wordpress/2022...
| mc32 wrote:
| Those are terrible. I think I've had analogs in the physical
| world where toggles indicated state by the color exposed
| (green = on, red = off) but this tries to be better by having
| both color indicator and text indicator) and you're left
| deciphering their language a bit. Yes, it is terrible.
| teo_zero wrote:
| > green = on, red = off
|
| Are you sure? I think the opposite is more common.
| djbusby wrote:
| I have at TV that is red-lamp off, blue lamp on.
| dylan604 wrote:
| where have you seen red = on, green = off?
| pwython wrote:
| Most safety switches on firearms expose a red dot meaning
| the weapon is "ON"/ready to fire.
| DiggyJohnson wrote:
| I agree with you on that, but I've never seen green be
| the contrasting or alternative color.
| teo_zero wrote:
| In electrical industry, red used to mean powered or hot
| or dangerous, green unpowered or harmless.
|
| All earth-leakage breakers in my area are like this: http
| s://en.m.wikipedia.org/wiki/File:Schneider_Electric_A9D3.
| .. https://i.ebayimg.com/images/g/sHYAAOSwu2ZkBk5~/s-l960
| .webp
|
| Electronics industry have diverged.
| Y-bar wrote:
| In security red generally means encryption/protection is
| active.
|
| And then there is this:
| https://en.wikipedia.org/wiki/Tally_light
|
| > In the active (on air) mode, tally lights are typically
| red.
|
| > Some cameras and video switchers are capable of
| additionally showing a preview tally signal (typically
| green) for when the camera is about to be switched to and
| become the main source of video signal. Once the switch
| happens, green changes to red.
| kwhitefoot wrote:
| red and green should not be used like that. A significant
| fraction of the population, especially males, has
| difficulty telling them apart.
|
| That's why mains wiring no longer uses red to mean live
| and green to mean ground.
| yabatopia wrote:
| I've seen it a few times on the web with cookie
| preferences pop-ups, to set your tracking and
| personalization preferences. Dark patterns to confuse and
| trick website visitors into enabling all tracking
| settings.
| Jasper_ wrote:
| The intended analog is lightswitches with the text on them.
|
| https://cdn.thisiswhyimbroke.com/images/lightswitch-
| identifi...
| ptx wrote:
| I've never seen lightswitches like those, but that's a
| terrible design as well, for the same reasons.
| nerdponx wrote:
| They're ubiquitous in America, but approximately nobody
| pays attention to the text because the position is what
| indicates on/off, where "up" in "on".
| HPsquared wrote:
| Huh, I'd always considered that toggle switches are "down
| is on". (UK resident).
|
| That way it's the same as a standard rocker switch (the
| direction of rotation is the same).
| ummonk wrote:
| I'd expect a rocker switch in America to also be the same
| as our light switches - pressed at the top for on,
| pressed at the bottom for off.
| nerdponx wrote:
| That's generally a rocker switches work on devices in
| America, e.g. guitar amps: the side that is pressed is
| "on" or selected/enabled.
|
| Last time I was in Europe (Portugal), I remember having a
| lot of difficulty making sense of the light switches, but
| it was one of those apartments where you have two or
| three light switches controlling the same fixture, which
| is always confusing.
|
| Still, I think the American light switches are actually
| pretty good. Maybe one day we will get a Technology
| Connections video about light switches around the world.
| DrSAR wrote:
| Until you encounter a switch that's part of a three-way
| switch arrangement where up can be on or off depending on
| the position of the other switch in the circuit.
| Izkata wrote:
| I've lived with these my whole life, in every place I've
| lived, plus with one or two switches that were sideways,
| so the first time I'd ever heard "up is on" was in a
| comment thread like this a few months ago. I didn't think
| there was any sort of standard, it's just always been
| "flip the switch if it's not currently what you want".
|
| This is in the US.
| nerdponx wrote:
| It's still "on" in the sense of the circuit being closed.
| nerdponx wrote:
| In this case I mean "down" as in "the long part is
| pointing toward the ground", not "some button-like thing
| is depressed towards the wall".
| Spare_account wrote:
| Agreed, in the UK:
|
| - 'angled towards the ground' is 'On' (https://cdn.aws.to
| olstation.com/images/141020-UK/800/10481.j...)
|
| - 'angled towards the ceiling' is 'Off' (https://www.tlc-
| direct.co.uk/Images/Products/size_3/MKK4870....)
| nerdponx wrote:
| But that's completely backwards from a normal rocker
| switch!
| perilunar wrote:
| In Aus most light switches are rocker switches that are
| also "down = on".
|
| In aviation (and old cars) switches are usually toggle
| switches with "up = on".
|
| Strangely I'm ok with both. I think of rocker switches as
| opposite to toggle switches automatically.
|
| - https://www.google.com/search?q=rocker+switch
|
| - https://www.google.com/search?q=toggle+switch
| beAbU wrote:
| With a light switch you can immediately verify that the
| switch is in the correct position by looking at the light
| you want to control. Text/labels/positions don't add
| anything of value. Also, it's _usually_ safe to
| experiment with the toggle until you get the desired
| state.
|
| In software often none of this applies.
| phkahler wrote:
| An icon or text should indicate the current state while hover
| text should indicate what will happen if you click. At least
| that's what we do. It's still confusing, but I agree you
| should be able to infer current state by looking at it. The
| person who designs it thinks it's obvious but it's usually
| not.
|
| Checkbooks are quite self explanitory.
| coffeebeqn wrote:
| Hover isn't really acceptable UX since the touchscreen era
| jfengel wrote:
| Even on desktops it's not great for accessibility. There
| isn't an indicator for what has tooltips, and they appear
| out of the usual flow of control.
|
| Accessibility guidelines usually allow them but encourage
| you to make it a last resort.
| caymanjim wrote:
| Not to mention that half the time tooltips don't show up
| until you wiggle the mouse over them a bunch, and tooltip
| delays are arbitrarily timed and usually far, far too
| delayed (often on the order of hundreds of milliseconds
| when they should be like 10-50ms at most). And my biggest
| pet peeve about them is that, at least in Chromium-based
| browsers, they really don't like to go away once they
| finally show up, to the extent that I can often scroll
| the page until they're offscreen and they still don't
| disappear. Or they leave the farm entirely and persist
| outside the browser window.
| WorldMaker wrote:
| Also, most windows aren't eligible for tooltips if they
| are not the focused, active window. I remember that
| difference being hard to explain to people when Windows
| 3.x and Mac Classic used entirely different title bars
| between the two states and sometimes even "shadowed" the
| window contents. It's especially hard to explain to today
| in a multi-monitor world and when inactive windows
| respond by default to all other inputs except some hover
| behaviors like tooltips. (I'm a software developer and
| know all this too well and I still tripped over it the
| other day wondering why tooltips wouldn't show up in a
| window and only realizing belatedly that the window
| wasn't active.)
| esafak wrote:
| It is ok; you just have to offer a different UX for each
| medium. And not every application is done on every
| medium. I don't code or write long-form on my phone.
| kwhitefoot wrote:
| Laptops have touchscreens too.
| esafak wrote:
| And trackpads or mice that let you hover.
| petee wrote:
| Some laptops fold so the mouse/trackpad is inaccessible
| and/or disabled.
|
| I have a Lenovo yoga, and its a constant nightmare of
| websites and apps that cannot figure out if I am a laptop
| or a tablet, even with tablet-mode fully off. I am
| usually offered whichever UI is least useful for my
| current configuration
| throwaway2037 wrote:
| Real question: Are there any touchscreens that provide
| the equivalent of hover with your finger?
| kmoser wrote:
| Would tap-and-hold be the closest equivalent?
| mananaysiempre wrote:
| At least that's how you get tooltips on Android. Of
| course, tooltips were designed to be discovered by a user
| hesitating with their mouse over an UI element (sometimes
| works, sometimes doesn't), while tap-and-hold on buttons
| you have to know about, and it's still scary when the
| button looks like it could do something potentially
| destructive and you want to find out.
| jerbear4328 wrote:
| I have an older Android (Samsung S5) with a physical
| hover feature - you literally hover your finger close to
| the screen and it triggers hover actions like previewing
| a message or opening a magnifier over text. It is called
| "Air View"[1] in Samsung lingo, and was coupled with
| other features ("Air Gesture"[2]) involving moving your
| hand over your phone to do things like scrolling or
| waking the screen.
|
| It's finicky on occasion, but when you are used to it,
| it's surprisingly intuitive practical! It wasn't super
| popular though, and I imagine it could be annoying to
| users who didn't want it. It appears they only did it for
| a few models, ending in the S5.
|
| That phone was pretty interesting, sensor-wise. I kind of
| miss using it, and I wonder if it would be practical
| nowadays.
|
| [1] Air View:
| https://www.samsung.com/hk_en/support/mobile-
| devices/what-is...
|
| [2] Air Gesture:
| https://www.samsung.com/hk_en/support/mobile-
| devices/what-is...
| phkahler wrote:
| >> Hover isn't really acceptable UX since the touchscreen
| era
|
| It's an augmentation that can be used on desktops though.
| I agree that it shouldn't be necessary but, but it can
| help. Some apps aren't meant for mobile either.
| Scarblac wrote:
| Depends on who your target audience is. Many applications
| can still safely assume they are for office workers using
| a desktop or laptop computer with a keyboard and a mouse.
| bmitc wrote:
| An element should do one thing, not two.
| vel0city wrote:
| Showing the current state matches light switches with the
| state on them.
|
| https://www.homedepot.com/p/Leviton-15-Amp-Single-Pole-
| Switc...
|
| Or car door locks which show red (unsafe) when unlocked. It's
| showing the current state, not the state that will be when
| toggled.
| lowbloodsugar wrote:
| Red means "stop" and green means "go". So how the fuck does
| red mean "this door is passable"??!
|
| "Unsafe" is contextual. If you are inside the car, and the
| car is on fire, then "locked" is very much the "unsafe"
| option.
| rpmisms wrote:
| On many guns, switching the safety to the "fire" position
| exposes a red dot, red meaning "hot" or "fire".
| lowbloodsugar wrote:
| Yeah my CZ pistol is like that and it's fucking
| terrifying because in my mind red means stop or locked. I
| actually feel more secure with my Glock because it
| doesn't have a safety so it's unambiguous. If I point my
| Glock and squeeze, I know it's going to fire.
| vel0city wrote:
| The red of a stop light makes a lot more sense in
| relation to the red of a fire mode on a gun when you
| think of red being "caution, unsafe" instead of just
| "stop". Just like the red of a STOP sign is to caution
| you into paying attention of the danger of the cross
| traffic, not necessarily _just_ stopping.
|
| Red lights on top of towers isn't trying to tell planes
| and helicopters to stop, its telling planes to exercise
| caution around the tower.
| lowbloodsugar wrote:
| Or like at a railway crossing. The flashing lights
| indicate danger, and the barriers drop. According to GP,
| the lights should flash when the barrier is _not_
| dropped, because now it 's unsafe, FFS.
| rpmisms wrote:
| Ah, my CZ is a DA/SA with a decocker. I'd recommend it!
| No manual safety, but you can hold the hammer forward
| while holstering.
| vel0city wrote:
| I've been in moving vehicles where opening the door would
| have been unsafe more than I've been in car fires. I
| often lock my car when leaving as well which usually
| unlocked is a bad state to leave it in, that normally
| happens more often than being in a burning car.
|
| Are you in burning cars often?
| lowbloodsugar wrote:
| Honestly, if I'm in the car and we're driving then I want
| to see a red light for same reason: red means stop and
| green means go. Or from outside after parking it: will
| this door open or will it stop somebody.
| vel0city wrote:
| Red also often means "danger, caution" not _just_ "stop".
| A red stop sign means "pay extreme attention here,
| there's danger, please stop and evaluate". A red DO NOT
| ENTER sign isn't just saying to stop, its saying there's
| danger heading that direction. If you just stop there its
| probably not going to end well, So clearly they're
| signaling more than just "stop".
|
| I'm still unsure, have you been in many burning cars
| before? More than just moving vehicles?
| wolfendin wrote:
| If you're inside a car and the car is on fire, you're not
| determining the state of the door lock by its position
| visually. For people inside the car unlocked is the
| unsafe position in most cases (leaving, driving.)
|
| (Do car still come doors that don't automatically unlock
| when the handle is pulled, if the child safety switch is
| disabled?)
| twixfel wrote:
| At my current workplace (particle accelerator) one
| control panel in particular has red for "good" as in
| "this is red, so don't go in here, because everything's
| fine and you have no reason to". Always amuses me.
| folmar wrote:
| The link is 403 for me.
| Spare_account wrote:
| It's been archived
|
| https://web.archive.org/web/20240128035720/http://www.hom
| ede...
| ajyotirmay wrote:
| I guess such interactive elements always show the current
| state of the system, and when they are interacted with, it
| changes the state it was in, examples: 1. Social media
| buttons for upvotes/likes/dislikes 2. on/off toggle
| switches for features 3. microphone/speaker buttons on
| desktop OSes
| dotancohen wrote:
| The YouTube play/pause button shows the action it will
| do, not the state that it is in.
| phkahler wrote:
| >> The YouTube play/pause button shows the action it will
| do, not the state that it is in.
|
| A lot of physical play/pause buttons show both symbols.
| Also in a lot of cases you can tell if a video is
| playing.
| dotancohen wrote:
| Not if it's buffering because you know that you have a
| bad internet connection. Around here, I often see people
| skip to an earlier portion of the video to check if it is
| playing or not.
|
| And that is anyway besides the point of consistent UIs'
| toggle switches describing their state, not their action.
| godshatter wrote:
| I miss the old convention of showing a button with
| shadows indicating it's been pushed in vs. showing it
| with just a flat plane when it's not pushed in. A button
| that shows that it's been pushed in with a triangle icon
| means it's playing, clicking or touching it will stop it
| from playing. A button that doesn't indicate it's been
| pushed in with a triangle icon is not playing, clicking
| or touching it will start it playing. Bonus points if
| there is a small virtual led that turns on when it's
| pushed in.
|
| Fewer and fewer devices we have access to these days have
| physical switches on them, though.
| cesaref wrote:
| And (as a european) i'm reminded of the confusing american
| light switches which show a light when they are off. Oh,
| and they toggle in the wrong direction (up is on?).
|
| By comparison, it's quite common here to have a switch with
| a lamp to indicate the light is on, which get used when the
| status of the light cannot be easily seen where the switch
| is located (e.g a switch for a light in the loft/outside
| light etc).
| bonton89 wrote:
| I believe American light switches are intended to confirm
| to a standard if installed correctly. But that all goes
| out the window with a 3 way switch.
| vel0city wrote:
| I'd say in a residential setting our switches make a lot
| of sense.
|
| The light up variety are mostly to aid turning on the
| lights in the dark and aren't usually the default. It's
| nice being able to see the switch when entering a dark
| room.In a residential setting it's a bit more rare to
| have a switch control a light you're not either
| immediately seeing or are often imminently going to see,
| like a closet or looking out a window next to the switch.
| It's not like you're often turning on and off lights
| across the house, so having it light up when the room
| lights up is rather redundant instead of offering that
| dark time help. Finally, having an on light would be
| really redundant since you can usually easily see the
| switch is physically pointing up or down and they
| sometimes even say ON or OFF.
|
| As for up being on and down being off, it's about being
| easier to toggle to the safer state. It's more likely for
| off to be a safer state (think changing a bulb, having it
| connected to a garbage disposal, etc.). It's generally
| easier to flip the switch down than flipping it up, so
| it's easier to toggle to the safe state rather than the
| unsafe.
| Scarblac wrote:
| > And (as a european) i'm reminded of the confusing
| american light switches which show a light when they are
| off.
|
| I have those in Europe. The point is that you can find
| the light switch in the dark. Why would it need a light
| when it's on, if it's in the room that it lights?
| wredue wrote:
| I actually hate this one because it's completely unclear.
|
| Does OFF there mean
|
| -the setting is off
|
| Or
|
| -Slide this thing over to turn it off
|
| I've seen it both ways. It's confusing and not clear.
| MrOxiMoron wrote:
| is the bridge open when it's up or is it closed when it's
| up?
| chrisweekly wrote:
| are you in a car or a boat?
| RunSet wrote:
| https://www.youtube.com/watch?v=Ljjns1Y1q-A
| mvaliente2001 wrote:
| My same thoughts. The inventors of that revolutionary toggle
| button should all be tied to the South side of an ass walking
| towards the North.
| HaZeust wrote:
| I don't like these. They can be mistaken to users as an
| indicator of what moving the "lever" to the other side of the
| toggle button will actuate - effectively reversing the user's
| intent of the button as compared to what the buttons do.
| plorg wrote:
| Or when you try to unsubscribe from a mailing list and are
| prompted: Unsubscribe from the following:
| [X] List A [X] List B [X] List C [ ]
| Unsubscribe All Lists
|
| But if you check the "all" button it clears all of the
| individual ticks.
|
| I would say a solid 80% of unsubscribe prompts have some sort
| of similarly confusing layout or verbiage.
| amenghra wrote:
| That's by design. They want to minimize the number of
| people who completely unsubscribe.
| neycoda wrote:
| Having an Unsubscribe All Lists checkbox doesn't minimize
| that. It just adds form noise and pointless work for a
| dev. The minimization already happens with the preceding
| checkboxes to select each list to unsubscribe from, but
| that's just as inherent to the form as the desirable
| feature of being able to keep certain subscriptions while
| unsubscribing from others in an efficient way.
|
| A button or link in place of the 'All' checkbox makes
| sense and is easiest for users to understand, and has
| less user actions required.
|
| Treat your customers well even when they're exiting
| (especially) so they remember something good next time
| they consider you. "Well at least they made it easy to
| unsubscribe" is better than "Well they made it
| unnecessarily complicated to unsubscribe". No need to add
| insult to injury.
| beAbU wrote:
| I have to admit I've never experienced this. When I check
| the "all" checkbox it goes and checks all the other
| checkboxen for me. Maybe I've only interacted with "nice"
| unsubscribe pages.
| neycoda wrote:
| I've seen both versions, and whether they check or
| uncheck all of the other options (behaving like a radio
| button), both versions are overcomplicated nonsense.
|
| The unsubcribe-all should just be a link or button with
| its own submit value or URL param (like unsubscribe=all).
|
| I don't know why people overcomplicate things.
| neycoda wrote:
| It makes no sense to have a checkbox for "Unsubscribe All
| Lists". That should just be a link. There's no point in
| adding a redundant form element even if it's only
| conditionally redundant.
| OJFord wrote:
| Or a radio button between all and choose which to
| unsubscribe from.
| no_wizard wrote:
| I think this is about confusing AI like that offered from
| gmail or iCloud email that will unsubscribe for you if you
| click on unsubscribe from their respective inbox /
| application. Fastmail offers this too.
|
| I noticed there are times I have to do it manually and
| can't take advantage of auto unsubscribe because the button
| layouts are like this.
| snowwrestler wrote:
| The unsubscribe buttons in email clients are powered by a
| header that the email includes. Google and Yahoo just
| started requiring these for all bulk senders (they were
| previously a best practice only). It doesn't rely on what
| the manual preferences page looks like.
| chazeon wrote:
| I remember when I designed a list of checkboxes this case
| was specifically considered. The last one needs to be
| updated when all of the checkboxes above are checked or one
| of them is unchecked.
| MarkLowenstein wrote:
| I would not be able to tell if these slider toggles were
| saying "yes" or "no" without them going from gray to green.
| How do colorblind people deal with them?
|
| That the whole world adopted these abominations, when there
| was absolutely nothing wrong with checkboxes, is immensely
| frustrating.
| sbuk wrote:
| Most of us cope just fine, so long as the contrast between
| the states is clearly different. My colour blindness is
| anomalous trichromacy, with a perception difference for
| red-green. Because the examples shared are a bright blue
| for on and black for off, I can see it just fine, however,
| I'd suggest making the switches off state back ground the
| same as the main background in this case. Aesthetically, it
| looks better.
| bonton89 wrote:
| Does green (usually these are blue) mean yes? Every time I
| see one of these I realize I don't understand them and I'm
| not even sure they are consistent in behavior. I usually
| use a context cue to infer what they mean. The dumbest part
| is there is plenty of room to just write "on" and "off"
| right on them.
|
| I think it is no coincidence these are the preferred
| control for all manner of dark pattern setting screens.
| marcosdumay wrote:
| Yes, green means "yes".
|
| Now, does light-green mean "no" because it's light, or
| "yes" because it's green? That one you have to check on
| each application.
| beAbU wrote:
| Yeah so in your example:
|
| "Disable all extensions" = OFF.
|
| Does this mean all extensions are currently on, or off? Does
| toggling the switch to on /enable/ the disable-all-extensions
| subroutine?
|
| A switch brings in a bunch of double negatives that can be
| avoided in most cases.
|
| Hella confusing!
| phkahler wrote:
| >> A switch brings in a bunch of double negatives that can
| be avoided in most cases.
|
| If you put the labels next to the switch: ON [xxxx] ----
| OFF then it's clear that sliding the switch toward the
| label puts it in the on or off state. But hey, we can save
| some screen real estate but swapping the labels and hiding
| the inactive one under the switch! Yay! For on/off a
| chechbox is much clearer for the size.
| marcosdumay wrote:
| Physical switches are labeled like that. Somehow, it's not a
| problem for them, but I do agree that on-screen ones are very
| unclear.
| neycoda wrote:
| It's rare to see physical switches like mobile toggles.
| Most switches show both labels with the switch pointing to
| the label. It's clear what the status of the switch is and
| what changing the switch will do.
|
| With software however, the inconsistency comes from
| knucklehead design. Hipster aesthetics. "But I want ours to
| be different!" They introduce toggles that don't follow
| convention and make unclear the status and behavior, or if
| touching it will even do anything. It then muddies up in
| people's minds how the conventional ones look and behave.
| marcosdumay wrote:
| Physical sliding switches usually look exactly like the
| ones on your link.
|
| Ex:
| https://www.chily.com/customer/chily/product/3331_350.png
|
| (Why selling photos of those things never seem to show
| the label?)
| fhub wrote:
| My "favorite" is when they use green color to indicate "Off".
| Like in this page
|
| https://www.istockphoto.com/plans-and-pricing
|
| The dark patterns here are something to behold (A bit like
| Adobe's stuff)
| LeonB wrote:
| Yes absolutely this --
|
| > my fav pet peeve remains the unclear toggle button. When the
| icon is white, is it on? Is it off? Does the line through the
| microphone mean it's muted? Or that it mutes when tapped? No
| one knows, tap it a few more times to find out...
|
| There's no UX consideration just design by committee, looking
| at static renders of the "design language"
| fsckboy wrote:
| > _iOS has had round checkboxes since forever?_
|
| but iOS hasn't been around forever. In the spirit of TFA, iOS
| marks the start of the Vandals climbing over the gates and
| sacking what had been to melt it all down and make a soup of
| melty things.
| coffeebeqn wrote:
| Toggle buttons are hard! I tried making some for a game I made
| once but ended up just using text because half the people
| thought it meant the opposite of what it did
| hn_throwaway_99 wrote:
| So why not use a check box?
| coffeebeqn wrote:
| Re-inventing the wheel I guess
| gcanyon wrote:
| I'm ashamed I never noticed this until you pointed it out.
| Standards can be broken insidiously, and it's disappointing
| that a company that cared about consistent UI enough to put out
| the HIG. Having typed that, I read the HIG on toggles and
| realized that those items in iOS aren't checkboxes. A checkbox
| turns something on or off. The "round checkboxes" used in iOS
| are to select multiple items for further action. I don't know
| what those are, or if/where they're covered in the HIG.
|
| https://developer.apple.com/design/human-interface-guideline...
| samstave wrote:
| >>> _"...increasing use of on-off toggles instead of checkboxes
| "_
|
| One of the most egregiously angering thing to me is toggles
| that self un-toggle:
|
| " _Disconnecting Bluetooth Until Tomorrow_ "
|
| WHAT?
|
| I literally just commanded the device to turn something off
| which required me to pick it up, unlock it with a biometric
| identification, navigate to the settings containing the option
| I want to control with my physical hands, look at the screen,
| read the results for the object I want. Make the decision to
| turn a thing off. Do so by physically touching the device and
| adjusting the setting - not the Device says
|
| _" Oh you want that off? More than for just a little bit?
| Well, I'll have you know that we use your Bluetooth radio for a
| lot of our data tracking systems, so its important to us that
| its on - so we've coded your device's operating system to only
| allow you to turn off your Bluetooth radio temporarily so you
| feel like you're in control of it. Why? Because Fuck You Thats
| Why. Now go back to browsing reddit_"
| djur wrote:
| I find that kind of "feature" frustrating as well, but I'm
| pretty certain that the reason it's there is that otherwise
| they get a constant deluge of support requests from people
| who forgot they turned it off.
| neuromanser wrote:
| If only Apple had the resources to create and enforce a UI
| that would make disabled Bluetooth obvious. /s
| samstave wrote:
| I fully believe you _and_ I are both correct. Yours is so
| "Benevelant Big Brother", mine is the 'Sinister Big
| Brother' <- Evil twin.
| dartos wrote:
| > Likewise I thought the article's punchline was going to be
| the increasing use of on-off toggles instead of checkboxes
|
| It kind of was. The last line of the article is "Kids these
| days will just use a toggle anyway"
| amadeuspagel wrote:
| Of course the entire point of the article is whining about the
| web and web developers.
| stevage wrote:
| As a non iOS user, I always get thrown by the horizontal slider
| toggles. I can never tell by looking at one if it is on or off.
| And sometimes on touch screens I try to slide them sideways and
| it doesn't work.
| Gabrys1 wrote:
| Tabs in Gedit are the same. Whenever I have two text files
| open, I always understand the tab bar wrong: the item I read
| as active is inactive and vice-versa. All becuase they doing
| follow the traditional tab design and use some sort of pills
| instead.
| hombre_fatal wrote:
| That reminds me of how every other time I silence/unsilence my
| iPhone, I stare at the "Silence activated" / "Silence
| deactivated" and work out in my head if it means the phone will
| make noise or not. Despite doing it thousands of times.
|
| I suppose "Sound on" vs "Sound off" would be better because in
| the moment I'm thinking of noise and sound, so silence is the
| inverse of that and kinda forms a double negative situation.
| "Not-noise mode activated / not activated".
| djur wrote:
| An app I use regularly and have introduced numerous people to
| uses a small toggle slider next to text that reads "Yes,
| [enable this feature]". Both I and literally every person I
| have introduced the app to have made the mistake of assuming
| that the "Yes" text described the current state. What's worse
| is that the "on" state of the toggle is just slightly more
| activated-looking than the "off" state. You could hardly design
| it worse on purpose.
| ummonk wrote:
| I could swear Discord inverted its mic button on vs off
| convention sometime last year.
| dusted wrote:
| The must microphone is a great example. I'm often finding it
| hard to find out whether that type of input means "change state
| to this" or "this is the state".
|
| Most confusing is when the text changes along with the
| checkbox, I just go from one unknown state to another.
| harperlee wrote:
| > Kids these days will use a toggle anyway.
|
| From the end of the article
| beAbU wrote:
| I've only seen round checkboxes used in the context of
| selecting multiple things in a list of indeterminate size, like
| emails in your inbox, photos in your gallery, etc.
|
| In my mind this is a slightly different application to the
| classic "form" that you fill out with data and options before
| submitting.
| beAbU wrote:
| I also absolutely hate switches in almost all contexts. In some
| applications it can make sense, like the UI that controls your
| WiFi or something.
|
| The reason why a light switch is so effective is because we can
| see an immediate response/impact on our action, the direction
| that the toggle points in is actually irrelevant, because
| either the lights are on or off, and toggling the switch
| changes that state, and I can verify with my eyes. Usually it's
| safe to toggle the switch back and forth until the desired
| state is achieved.
|
| In software that's not always possible, and often changing the
| state has destructive results. So you can't experiment.
|
| And then you get the abominations that bring in double
| negatives, and things that use switches to control something
| more complex than a simple boolean state.
|
| "Disable the nuclear missile warning test = ON/OFF" - like what
| the hell does this even mean, and how can the user be expected
| to understand what the right option is without trying first.
| pgeorgi wrote:
| I suppose people forgot what "radio buttons" are (and where the
| name comes from). At least I haven't seen them on non-vintage
| devices in ages.
|
| WIth that, it might make sense to reevaluate if they're still a
| useful UI language idiom, and if the different handling is still
| necessary.
| Kwpolska wrote:
| The name might be antiquated, but the difference is still
| important and understood.
| skgough wrote:
| I also think the visual idiom doesn't hold up, especially since
| implementers don't use radio buttons correctly half the time.
| To help people get the idea that they are possible choices for
| the same attribute, I like to wrap them in a <fieldset> with a
| <legend> that explains what their [name] attribute is
| associated with. I think this is how Win95 did it back in the
| day too
| NoZebra120vClip wrote:
| Around 2015, I authored my resume in LibreOffice, and I sprinkled
| in an assortment of bullet points. Some were indented. I used
| open squares, filled squares, open and filled circles, right-
| arrows, stars, etc.
|
| I brought it into an employment center for critique, and my
| mentor informed me that those shapes all had different meanings
| and functions. It was a wake-up call for me.
|
| I am not a UX/UI designer, so my experience with the UI elements
| in applications had been intuitive, and moreover, disconnected
| from the activity of authoring a non-interactive document.
|
| So I believe that these UI features were imitating paper-based
| forms. Those ovals or circles on Scantron sheets: you'd better
| not fill in more than one per line! And being named "radio
| buttons": yes, if you pressed "AM" then the "FM" button popped
| out. If you had six presets in a car--wait a minute, those were
| oblong...
| teddyh wrote:
| > _my mentor informed me that those shapes all had different
| meanings and functions._
|
| I have never heard of this. It sounds dubious, like those
| "flower language" lists which are all different.
| xg15 wrote:
| My impression is that in modern UIs, both checkboxes _and_ option
| buttons are being phased out: Checkboxes seems to be replaced
| with apple-style toggle buttons, which I guess are more intuitive
| for some people?
|
| Option buttons don't have any direct replacement that I can think
| of, you just see them incredibly rarely. My guess is that they
| always were one of several possible means to have the user select
| from a set of choices, the other prominent ones being a plain
| listbox widget or a combobox/dropdown widget - or of course, just
| use plain buttons.
|
| For some reason, designers seem to prefer plain buttons or a
| dropdown for this usecase today.
| toyg wrote:
| _> apple-style toggle buttons, which I guess are more intuitive
| for some people?_
|
| You seriously overestimate the average competency in UX
| circles.
|
| The algorithm outside Apple is basically "what would Apple use
| here?".
|
| The algorithm inside Apple is basically "what will make people
| talk about us?"
|
| Serious studies are for boring people. Design hipsters don't
| want to look boring.
| lou1306 wrote:
| Toggles are actually not that bad as a checkbox replacement.
| But I feel they convey a lot of meaning through color (in iOS,
| sliders turn green when selected), whereas checkboxes reimain
| immediate even in b/w. I wonder whether people with severe
| colour blindness have any issue with that?
|
| Ahh why didn't I take interface design as a career :)
| ipsum2 wrote:
| TIL radio buttons were named after the physical buttons used on
| older radios to select preset stations[0]. IMO they look nothing
| like the actual buttons on radios.
|
| 0: https://en.wikipedia.org/wiki/Radio_button
| eskodhi wrote:
| Yeah the name definitely refers more to the
| functionality/behavior of the buttons.
|
| You'd push one of those buttons in to select a station and it'd
| stay pressed. When you push another button in to choose another
| station, the previously pressed button would "pop" back
| up/depress (thereby "unselecting" itself), thereby enforcing
| the mutual exclusivity of a station selection.
| thaumasiotes wrote:
| That wasn't anything to do with radios though. That was just
| the way mutually exclusive buttons worked. I had a portable
| tape player where the playback controls were the same way.
| jeroenhd wrote:
| We have controls that mimic the actual radio buttons in the
| form of toggle buttons (buttons that stay depressed after
| pressing them), but in many APIs the programmer needs to toggle
| the press state of all other buttons in the group to use them.
|
| Preset radios came in a huge variety and some of them were
| actually round. Car radios (the radios that have stuck around
| the longest) need big and bulky buttons so you can operate them
| without taking your eyes off the road, but some home radios had
| smaller, circular buttons instead.
|
| The "radio" buttons I used as a kid were small, rectangular
| sticks poking out of a metal plate that you pushed in. Every
| brand had their own shapes and designs. Unfortunately, I can't
| find any pictures of older radios on the internet because every
| image searching site seems to have been overtaken with badly
| generated AI art, stock photos, and cheap, plastic "retro
| vintage" Amazon listings.
| hnbad wrote:
| Here's one that seems genuine and has round radio buttons: ht
| tps://i.pinimg.com/originals/f4/c8/8b/f4c88b861769e24674b4...
| jeroenhd wrote:
| Thank you!
| vitiral wrote:
| Huh, I thought they were "radio" because they communicated with
| each other. Still not a bad mnemonic IMO
| crucialfelix wrote:
| Actual radio buttons in cars were for the most part rectangular
|
| https://www.shutterstock.com/search/radio-buttons-old-car-ra...
|
| There's a good explanation of how they worked here:
|
| https://www.physicsforums.com/threads/how-do-old-timey-radio...
| barnabee wrote:
| It's obvious with hindsight, but I had never realised that
| _that_ is why they 're called radio buttons!
| arcanemachiner wrote:
| Imagine the poor bastards in the future trying to
| comprehended the floppy-disk "save" icon.
| crucialfelix wrote:
| Those poor bastards are here now. I'm teaching my 7 year
| old all these strange words and icons. We carry so much
| historical garbage.
| Izkata wrote:
| I remember seeing a post like a decade or more ago of
| someone asking why you click on a little TV to save
| documents.
| seabass-labrax wrote:
| Me too! I had assumed that 'radio button' was a
| bastardization of ' _radial_ button ', referring to the very
| shape which the author notes is conventionally used for them.
| at_a_remove wrote:
| If it is round, it isn't a check _box_ , it is a check _hole_.
|
| People see something round, "box" isn't the first word that comes
| to mind.
|
| In my previous history as a ... as a _web person_ (I think that
| 's both broad and vague enough to encompass the yes-I-did-that-
| too sense of things), I had an ever-growing disdain for the
| designers who were off on their own flights of fancy. Usable?
| Explainable? Accessible? Senior-friendly? Then, late to the
| party, I got this iPhone thing and I was astonished at how much
| the device expected me to know about how the interface worked, on
| a deep level. I tried to get my mother into an iPad and,
| frustratingly, could find no good cheat sheets on the "gestures,"
| to the point where I made a laminated, color-coded and numbered
| set of sheet on gestures, screen, etc. I help out an even older
| senior with her computer and ... well, I think the i-UX people
| are frankly out in their own la-la land and their hubris is
| sustained only by Apple's inertia/network effect/market
| dominance.
|
| In a kinder, gentler world, these UX teams would be required to
| make a general style sheet document, which would be applied to
| various real-world applications, and then they would be forced to
| watch a senior citizen attempt to navigate their trash to, say,
| get a test result from the hospital. Should this not be
| accomplished in under five minutes, they are thrown into a hell
| of leather-clad demons who beat them with sticks while patiently
| explaining that their design, in fact, sucks.
|
| UX design has begun to resemble fashion in an Oscar Wilde manner,
| "so intolerable that we have to alter it every six months." It's
| getting divorced from meaning and utility, and worse yet,
| _constancy_. Nobody wants to relearn UX for your crap app just so
| you can be cutting edge with sliders that resemble the phases of
| the moon.
| wruza wrote:
| This makes me rethink the idea of buying i-things for my
| grandma, thanks. That said, I see her struggle with android-
| based devices everyday. Both get shittier and shittier with
| years, we just tend to suffer less due to the boiling frog
| situation.
|
| I fully support the proposed initiative.
| userbinator wrote:
| Apple seems to have been one of the main forces behind the trend
| of adding rounded corners everywhere in UIs, which frankly is a
| style I don't like at all.
|
| The irony is that some of their hardware has painfully sharp
| corners, the one place where rounding them would greatly improve
| comfort --- anyone touched the edges of a MacBook or Mac Mini and
| thought "why did they not smooth these off"?
| thaumasiotes wrote:
| When I had a macbook, I had to buy a plastic case for it,
| because otherwise its hard, pointy metal surface damaged my
| fingernails.
| yreg wrote:
| That's a matter of preference. I like the sharper iPhone forms
| more (4, 5, the first SE, 12 and onwards). I also love the
| sharp look of Mini and iMacs (especially the 2007 - 2015 ones).
| seydor wrote:
| they are replaced by those slider-switch that came from mobile
| and are supposed to resemble lightbulb switches. A specific type
| of switch that seems to be popular in america, and it s hard to
| immediately grasp for most others
| its-summertime wrote:
| > That's why it's common to see radio buttons containing
| checkmarks
|
| The radio-buttons prior all included an additional inner circle
| to imply a selected state. You can't just have empty and filled,
| since filled could be off, and empty could be a filled circle
| over a filled circle, in other words on.
|
| La, the prior was only good design because it was common design.
| the_gipsy wrote:
| It's the same for radio and checkox. All combinations of
| checked/unchecked, enabled/disabled, and focused/unfocused
| exist.
| alentred wrote:
| I remember reading a book about UX years ago, and one of the
| fundamental principles there was the discoverability and the
| intuitive use, which boiled down to sticking to conventions that
| are rooted in everyone's experience. Stuff like using check boxes
| and radio buttons properly, having the "OK" and "Cancel" buttons
| in their regular places (and not a "Maybe later"), using
| unambiguous confirmations (unlike the "Are you sure you do not
| want to not unsubscribe?"), sticking to the same navigation
| patterns users see in most other apps.
|
| Now, I don't subscribe to it in full. There needs to be room for
| innovation. To my taste, it was quite boring when all software
| looked literally the same. Nevertheless, I agree there needs to
| be some reason too. Some short time ago every new app looked like
| a new game where you needed go through a tutorial to learn the
| basics. That was probably too much.
|
| But, I don't know, as of late it feels like this iteration comes
| to and end, the apps start being intuitive again and reuse some
| patterns. The sidebars, user menus, etc. all in the same place.
| Mostly.
|
| So, yay discoverability and intuitive use. But that doesn't mean
| we can't innovate in UX, while keeping it intuitive. Just not the
| "Maybe later" abusive way, please.
| jeroenhd wrote:
| There's nothing wrong with innovation, of course. A lot of
| controls needed to change to work well on touch interfaces,
| like the sliding toggles iOS use(d), and the large, connected
| touch areas that have replaced the small labels and click
| targets that computers used to have.
|
| There's no reason to abandon the toggle button/checkbox
| distinction, though. They're still used distinctively, there
| are common practices to indicate those distinctions that go
| back decades, and I don't see any need to unify these controls.
| musha68k wrote:
| Since ~2013 Apple designers have been throwing over board lots of
| conventions the company had been itself establishing for
| _decades_.
|
| I remember user interface design class at my university ca. 2005
| where 20 out of the 30 best practice interaction design patterns
| originated at Apple!
|
| Steve Jobs for the most part really _cared_ and you could feel
| those priorities clearly: "it's how it works, not how it looks!"
|
| Aside from some natural missteps, the "form over function"
| critique at the time was predominantly false. Apple is slowly
| getting there though, joining "ignorant web" as correctly called
| out here by Nikita.
|
| The thing is that none of this is a joke or could be taken
| however lightly. It's 2024 and by now we've fundamentally
| realized the "Software is Eating the World" prophecy; living in a
| digitally permeated world.
|
| Bad design is a moral issue, in worst case scenarios it has been
| _killing people_ before and will increasingly kill or harm even
| more going forward. It always starts with the little things,
| especially so in design / engineering.
|
| I desperately hope that Zoomers at least will start to realize
| that Millenials really fucked it up in that regard. I know, I
| know it also were the bosses pushing for this but we clearly
| should have said "no" _much_ more often as the professionals (?)
| implementing this stuff.
|
| There is much satisfaction waiting in learning; a full-grown
| craft with deep history.
|
| Zoomers: Alan Cooper's "About Face" is a great start, probably
| super cheap these days as seemingly no one cares anymore.
| anon373839 wrote:
| For a few years in the last decade, it seemed that UX design
| was getting recognized as a serious discipline rooted in user
| research. Then, somehow, it devolved into fashion. When/why did
| that happen?
| kibwen wrote:
| _> When /why did that happen?_
|
| There's no money in making a thing that works well, only in
| making things that look good. Effectively 100% of people who
| are using software are using it for things that fundamentally
| don't matter, so why should they care if the functionality is
| shit? Personal computers and phones are fashion statements,
| not useful devices. Business computers and phones exist to
| facilitate the bullshit jobs that employ the majority of the
| white-collar population. Follow the money; nobody with money
| cares.
| rezonant wrote:
| Maybe a bit cynical and hyperbolic, but the point is good.
|
| I'd boil it down further and say it's a focus on short term
| gains over long term gains. If the pan flashes, that's a
| win, full stop. When the pan stops flashing and people
| don't want to use your software because it's confusing,
| that doesn't matter because they can just flash another
| pan.
| wolletd wrote:
| > There's no money in making a thing that works well, only
| in making things that look good.
|
| I work in a company building vending machines and such and
| it's the other way around here. Most products are shipped
| with a pretty mediocre UI because it just isn't valued. The
| software has to run the machine, vend products to people
| and don't eat their money.
| tnolet wrote:
| > There's no money in making a thing that works well, only
| in making things that look good
|
| Amazon, AWS, Salesforce and anything Oracle entered the
| chat.
|
| More seriously, I think it really depends. People will use
| and pay large amounts of cash for stuff that solves there
| problem and does not have a fancy looking UI.
| qznc wrote:
| In other words: Make something people want. Ignore what
| people need.
| gherkinnn wrote:
| It started as user-centric research and when the user became
| the product the intent of this research shifted.
| endgame wrote:
| Doing research on the user, instead of for the user.
| j4yav wrote:
| I'm sure there are many exceptions but a decent amount I've
| seen is portfolio-driven design, where the goal is more to
| have something eye-catching, unique and interesting that will
| look good in a portfolio and to show other designers, more
| than building something well considered and
| reliable/predictable. There can be a sense, especially
| amongst more junior designers, that the job of design is to
| add some style, and that design should be fun and much more
| like creating abstract art than making sure door handles are
| in a reasonable place and turn in the expected direction. The
| end result is, as you say, more fashion than function.
| kossTKR wrote:
| Does anyone have a design inspiration site that isn't this
| useless portfolio garbage?
|
| It's incredibly annoying, and i say that with a an interest
| art, the abstract, cool concepts etc. but i want to see
| sites and interfaces with "actual messy real life content"
| not just one big image or whatever idiotic whitespace hell
| everyone's doing with way too much scrolling on Awwwards,
| Behance, Httpster, Gsap etc.
|
| It's relatively easy to make a big font, a big picture and
| a 3d effect look cool, much harder to present 15+ items on
| one page and create a cool visual narrative around it that
| both grabs attention and lets the user go solo if he wants
| to without scrolling two miles.
|
| I feel like a few newspapers were okay examples of this
| 5-10 years ago, but now they've also gone whitespace crazy.
|
| We need a site like "Real life UX" or "Actual usable
| design" inspiration.
| j4yav wrote:
| Not that I'm aware of but that would be really cool. Case
| studies, with visual components, of how complex, real-
| world design problems were solved.
| airstrike wrote:
| If you find out the answer, I've also been looking for
| that everywhere to no avail. Sometimes I go to websites
| like https://dribbble.com/ and search "Rich UI" but
| results are really hit or miss (mostly miss)
| pilgrim0 wrote:
| Honestly? Install classic software and use it! I needed
| exactly those sort of references to design a project and
| knowing I wouldn't find them on the web, I booted a win95
| vm and studied it. My designs improved dramatically.
| kossTKR wrote:
| This is an interesting approach. I remember classic osx
| was also pretty good at dense content.
| gsich wrote:
| Designers still want to work, so they change stuff randomly
| and sell it as "modern".
| ksec wrote:
| 1. 99.99999% of management have zero understanding of UX. So
| their view of UX is basically some designer making it
| "pretty".
|
| 2. Most UX design aren't probably taught. Especially Software
| User Interface.
|
| 3. A lot of Design in that era came from Web. And if we read
| this article we already know or could guess what web design
| were like.
|
| 4. It is my observation that Tech, or Silicon Valley
| historically speaking learns very little about history of
| their industry. Unlike many other discipline, things comes
| and goes like fashion industry. Combine with Hype machine and
| VC money. Apart from Politics or Finance there is no other
| industry that contains as much noise as Tech.
|
| 5. Conservatism ( Not politics ) is generally not well
| accepted. Finished Software is not appreciated. And if you
| cant improve, or remake something, there is no way you can
| move up the ladder. The fundamental of not doing anything
| hype or large changes is against Resume Driven Development
| model.
| pilgrim0 wrote:
| I'll give my perspective as a designer turned developer.
| People have always conflated design with "desenho" (drawing).
| But design is supposed to be more about information
| architecture. It just so happens that what's usually trusted
| to be architected by designers is materialized graphically.
| But when the whole ecosystem of training and employment robs
| designers of their impact by not integrating them in both
| higher and lower level industrial processes, they're
| hopelessly left at their corner, with a lot of energy to
| spend on what they actually have a stake on: visuals.
| mopsi wrote:
| Electron-based applications seem like a hugo factor. When
| native applications were abandoned in favor of Electron,
| designers stopped trying to match their designs to
| established operating system standards and began designing
| from scratch, with much poorer results, because they didn't
| have the resources and experience of teams that had worked on
| major OSes.
|
| Prior to that, deviations from established standards
| (layouts, colors, logic) were seen as unprofessional and
| tasteless. Things like buttons with unusual colors made
| software look like a shareware hobby project downloaded from
| Tucows, and nobody wanted their product to trigger these
| associations. Premium software made for Windows wanted to
| have the look and feel of Word and Excel.
| Sohcahtoa82 wrote:
| > Then, somehow, it devolved into fashion. When/why did that
| happen?
|
| I'll tell you what happened.
|
| Apple.
|
| I've been saying _for years_ now that Apple is not a tech
| company, they 're a fashion company. Alternatively, they make
| tech fashionable, which means abandoning function in favor of
| form.
|
| Actual UX is unimportant. It just has to look nice.
|
| What infuriates me is when other companies then start to copy
| them. I'm looking at you, Microsoft. With Windows 11, it
| seems you have forgotten that many of your users stick with
| you _because you 're not MacOS_. So why would you want to
| start imitating MacOS?
| jstummbillig wrote:
| I am quite positive, that (despite this and countless others
| fun examples to the contrary) the average the UX floor has
| risen by a lot.
|
| Sure, things regress and move in waves, but on the whole user
| design has been established as the primary of software
| development and that _really_ was a not the case back when.
|
| Take something like error handling in a form. In a lot of
| average software, it was not at all uncommon for a form to just
| say "Error" when something went wrong (or just not submit). Or
| lose all form input after unsuccessful submission. Programmers
| were unironically confused about why people would not just
| enter correct information. People then wrote books about how to
| design form errors. Now, basically every web framework includes
| at least some form of validation and error handling by
| default(-ish), and most people would be seriously confused if
| they saw something like the above.
|
| If you find it easy to poke holes into this one, please
| consider the average across all the little things that go into
| not fucking up a form, which is still hard to get _really good_
| , but again I am describing something of an average expectation
| here.
|
| I would pin this to two major developments:
|
| 1. Designers are increasingly everywhere. If you think "duh?",
| this is entirely not how software was made. Programmers,
| commanded by business people, made software.
|
| 2. Most programmers today _are also_ designers, and I don 't
| mean in the sense that they always were (designing the
| software), but as in "thinking about people using the product".
|
| Again, this might feel like a comical thing to even say but in
| most places programmers were just not expected to do _anything_
| to make the users life simple, unless explicitly told so. That
| was the designers job. In fact, a lot of programmers considered
| it a holy duty to fight any feature that was merely a
| convenience, and were quite adamant that, surely, the user
| could simply be expected to suffer a little and work a bit
| harder to get things done, if that meant keeping the code base
| pristine.
| couchand wrote:
| I think your point 2 is absolutely on the nose here. It fits
| in with broader industry trends in testing and operations.
|
| And perhaps that's where the OP's question originated from?
|
| As we've watched the despecialization of our field in testing
| and ops, we've seen that things improve, as ideas are
| introduced more widely, while also seeing them get mimicked
| and cargo-culted when the ideas are diffused.
|
| Maybe the coders who were fighting against testing mandates
| or devops or design thinking were just insecurely admitting
| to their own ignorance on these topics and asking for
| assistance in being able to perform their new duties
| effectively?
|
| One value in specialists is the freedom that comes with
| specialization enables them to do their job more completely.
| Fred Brooks's surgical team could not be more relevant.
| esafak wrote:
| Which era's programmers favored code simplicity over the UX?
| I find this hard to believe.
| jstummbillig wrote:
| Mind you, I know this has probably never been the case
| looking for example at Apple, Google or other shops that
| worked in similar spirit, but as a mainstream phenomena you
| have to not look further than the late 90s or early 2000s
| to find that average programmers in mid tier companies
| harboured a mix of non-empathy, non-sympathy and user
| frustration over a complicated interface and a designers
| call to do something about it, was regularly met with
| arrogance, a sigh or a frown.
|
| Of course, this can also be credited to the fact that ui
| design for software was at a much different place in
| general.
| robviren wrote:
| I blame the human spirit. User interfaces could have been the
| one thing we collectively agreed to "stop innovating" on and
| delivered better experiences for everyone. People are unable to
| stop innovating. People paid to look at design can't just say,
| it's done, we did it. And now I fully expect for the rest of my
| life I will need to explore an increasingly complex labyrinth
| user interfaces for which I will one day be unable to figure
| out.
| mst wrote:
| > Alan Cooper's "About Face" is a great start
|
| I'm not sure if I read all the way through it when I first got
| my copy but it -is- very good and I have it stashed for the
| next time I end up doing UI design.
|
| Well worth a look.
| ksec wrote:
| >Since ~2013 Apple designers have been throwing over board lots
| of conventions the company had been itself establishing for
| decades.
|
| 2013 was when we first witness it in effect. It started a
| little earlier inside Apple. When Scot Forstall was forced out,
| the whole _Software_ User Interface falls to Jony Ive and he
| basically ripped everything out and redesigned it with iOS 7.
| There is a huge different, or dare I say 95% completely
| unrelated field in Software UX and Hardware UX. Apple then
| spend the next 3-4 years walking back on all the design changes
| made in iOS 7.
|
| Unfortunately a lot of UX learning was lost during that period.
| Including the Seniors of Human User Interface _retiring_ during
| 2015 - 2020. The group has also grown rapidly in terms of
| numbers under Tim Cook. A lot of the Steve Jobs design
| requirement and " _why_ " were diluted with more new members.
|
| The design from Apple today may still look beautiful, but they
| are no longer as functional as they once were.
| crazygringo wrote:
| > _Since ~2013 Apple designers have been throwing over board
| lots of conventions the company had been itself establishing
| for decades._
|
| For decades, all the conventions had developed on desktop. By
| ~2013 it was clear that mobile required different conventions,
| and that it was important to also unify conventions to some
| degree across mobile and desktop.
|
| Also, traditional desktop apps had largely limited themselves
| to the UX vocabulary provided by the OS's graphical widgets.
| But with the rise of high quality CSS and JS, websites and apps
| became more free to develop their own conventions, separate
| from anything coming out of Apple or Microsoft. Hamburger menus
| and pills and what have you.
|
| So it makes perfect sense that Apple started to evolve more
| rapidly around that time. And good for them -- none of these
| rules can or should be set in stone.
|
| (And please don't make this about generations, that's just
| silly. Trying to assign blame to entire generations is utterly
| meaningless. Generations are made of individuals who disagree
| with each other.)
| yreg wrote:
| I believe these rules should be changed rarely, consciously
| and very carefully. Perhaps it would be worth it for them to
| explain their thought process behind revising them in some
| developer session.
|
| Meanwhile, every person working on design systems should
| think about decisions like these deeply. Designers,
| engineers, accessibility specialists should all talk together
| and come to some common ground before doing something like
| this.
| AlienRobot wrote:
| Is everybody insane?
|
| I go to Windows, terrible GUI choices.
|
| I go to Linux, GNOME makes terrible GUI choices. (Thank God for
| KDE)
|
| I hear about Mac, terrible GUI choices.
|
| Did all the people with experience in graphical user interfaces
| die off or retire?
| zilti wrote:
| Pretty much so, yes. It is cheaper to just get some random dude
| on Fiverr who has no clue about GUI design, but can whip up
| something pretty that impresses the manager who has no idea
| about UX and GUI design either.
| yreg wrote:
| I don't think Apple outsources visionOS design through
| Fiverr.
| Findecanor wrote:
| BTW. Motif (on X11) used small bevelled squares for check boxes
| and a bevelled _diamond_ shape for radio buttons. There was no
| checkmark, cross or coloured circle. Bevelled _in_ was active.
| Bevelled out was not.
|
| Example:
| https://www.oreilly.com/openbook/motif/vol6a/Vol6a_html/V6a....
| josephg wrote:
| For some reason I've always found this design incredibly ugly.
| My eyes just hate it for some reason.
| Findecanor wrote:
| When GTK 1.x and WindowMaker copied Motif's diamond, I
| hacked/themed both for personal use to make it a circle.
|
| SGI had their own version of Motif with a look that was more
| like Mac and Windows of the time.
| Nevermark wrote:
| Nearly all gray, with flat black, no gradients to smooth
| anything. Gives the impression of harsh lighting.
|
| Very sharp-edged 3D boxy window design creates heavy
| cumbersome feel.
|
| Inconsistent pixelly fonts.
|
| Oddly aligned text in button.
|
| Diamonds happen to be a shape that maximizes pixelation.
|
| Indent in vs. out is cognitive heavy to process, relative to
| something less pure-dual.
|
| Black selection border doesn't have consistent widths.
|
| Separation line between big button and little buttons,
| despite obvious size and shape differences that already make
| that distinction.
|
| Extra little borders defining window box corners from
| horizontal and vertical borders - a distinction that surely
| didn't need highlighting.
|
| No rounding. (Granted, rounding would look pixelated.)
|
| TLDR; It looks like an industrial lead brick you really don't
| want to drop onto your foot.
| FrontierProject wrote:
| > Extra little borders defining window box corners from
| horizontal and vertical borders - a distinction that surely
| didn't need highlighting.
|
| This actually designates an area where you can click and
| drag to resize the window. I'd argue that this behavior has
| become a ubiquitous expectation because of this design.
| deathanatos wrote:
| What kills me about macOS is that the window border is
| now pixel thin, but macOS simultaneously lacks the
| keyboard shortcuts that exist in Linux for easily
| resizing.
|
| Like, a 1px border isn't too back when I have a keyboard
| shortcut that makes a full 1/9th or so of the window's
| area the effective border. But when it's _exactly a
| pixel_ -- and combined with macOS 's cursor's hotspot not
| being on the cursor tip ... it just takes what should be
| simple to way harder than it need be.
| kevin_thibedeau wrote:
| The Motif colors were all configurable and the system
| defaults varied by vendor. You got a mix of beiges on the
| DEC windows version.
| dfox wrote:
| > Inconsistent pixelly fonts. Black selection border
| doesn't have consistent widths.
|
| This is because the screenshot is apparently rasterized
| from data for print version (".eps.png") at a resolution
| that does not match the resolution of the two bitmap images
| in it.
| mwcampbell wrote:
| To clarify, are you referring only to Motif, or the Windows
| 9x classic look as well?
| DonHopkins wrote:
| "X will not run in these 4 bit overlay planes. This is
| because I'm using Motif, which is so sophisticated it forces
| you to put a 1" thick border around each window in case your
| mouse is so worthless you can't hit anything you aim at, so
| you need widgets designed from the same style manual as the
| runway at Moscow International Airport. My program has a
| browser that actually uses different colors to distinguish
| different kinds of nodes. Unlike a PC Jr, however, this
| workstation with $150,000 worth of 28 bits-per-pixel
| supercharged display hardware cannot display more than 16
| colors at a time. If you're using the Motif self-abuse kit,
| asking for the 17th color causes your program to crash
| horribly." -Steve Strassman, Unix-Haters Handbook
|
| https://news.ycombinator.com/item?id=25734498
|
| https://medium.com/@donhopkins/the-x-windows-
| disaster-128d39...
| Kwpolska wrote:
| Early builds of Windows 95 had diamonds too:
| http://toastytech.com/guis/chic58test.png
| punkspider wrote:
| I chuckled when switching to dark mode on this website. The
| result is hilarious. When clicking it the page becomes dark and
| your cursor becomes like a flashlight. Definitely doesn't help
| with reading. Feels like it's a statement against dark mode. I
| love opinionated blogs like this.
| Eikcalb wrote:
| This site somehow made me dislike dark mode in a good way. That
| was wayyyy too dark
| almostnormal wrote:
| If I remember correctly Borland claimed compliance with some
| standard for the TUI toolkit provided as part of Turbo Pascal. I
| cannot remeber which ISO it may have been, or if details like
| checkboxes were covered by it.
|
| Does the current ISO 9241 cover that topic?
|
| The three recent main losses of clarity/usability seem to be: 1)
| links no longer visually identifiable, 2) changes applying
| instantly instead of only when pressing apply/ok and no cancel
| button to revert, 3) now the loss of visually identifiable
| checkboxes.
|
| Shouldn't things become easier and more clearly identifiable to
| use with todays user base of 100% of mankind compared to limited
| few persons 30 years ago? Why is the opposite happening?
| davidverhasselt wrote:
| I'm missing a good reason why the distinction needs to be made
| visually clear. More about this at the end.
|
| I think a lot of this design thinking is stuck in the past, and
| we should be able to challenge and throw off some of the shackles
| or crutches that made sense back then, but might not anymore
| today, in order to advance and give priority to different goals.
|
| In this specific case, it should be clear that you can select
| multiple options from context or by text, or it should be
| encouraged to try it out (i.e. easy to undo). If you need to rely
| on the visual difference of the icon, then you've already lost
| more than 50% of the people who don't realise this.
|
| My thesis is that this visual difference is only useful to a
| select, minority group of people who have an above average level
| of interest in software, who would even be aware of it. Yes, they
| were probably the target market decades ago, but nowadays
| software caters to a wider group than that, and I wonder if you
| would survey a group of "normies" how many would actually rely on
| the visual distinction in any way (even just supportive).
|
| I'm late 30s and I remember being confused about the difference
| between "radio buttons" and "checkboxes" when trying to learn
| HTML4 when I was young - even the name "radio button" was back
| then already only something older folks would be able to
| understand, why it's called that way. The distinction, even
| conceptually, was more confusing than helpful. It's really just a
| property of a list of checkboxes, how many you can select, not an
| entirely different class of UI component.
|
| To continue on from my first sentence, and conclude my argument,
| this whole article does not contain a single good reason why that
| visual distinction is important in 2024. The closest I could
| find, is this line which implies confusion: "There was a brief
| confusion up until 1986 when Apple used rounded rectangles
| instead of circles". Just the fact that the article has to
| describe the difference and show visual examples, tells me that
| this is just no longer a concept that's important, as it may have
| been 30 years ago, from when it originated.
|
| Instead, it only makes references to "tradition", "convention",
| "internal training", or arguments from authority such as "art
| director says so".
|
| I think that kind of supports my point - in the context of UI of
| 2024, the only reason that one would keep the distinction
| visually is for tradition, not for any actual practical reason
| anymore, or the practical benefits that may still be there have
| diminished in value so that they don't outweigh the downsides or
| extra constraint anymore.
| simion314 wrote:
| >It's really just a property of a list of checkboxes, how many
| you can select, not an entirely different class of UI
| component.
|
| Not really at all. Radio buttons are part of a group so 3 radio
| buttons are related and exclusive, there 3 check-boxes
| represent 3 different unrelated things. The typical example is
| selecting your gender/sex , you use a radio btn group and put 2
| radio buttons or if you are less competent dev you recreate
| this with checkboxes, scripting and extra validation.
| mixmastamyk wrote:
| If you have to "try it out" to understand the interface for
| each program you're wasting everyone's time. No loss in giving
| clues to those who understand either.
|
| There's a real productivity benefit to learning and using
| standardized interfaces. The rest of your post reads like an
| appeal to "closed mindset" theory.
| davidverhasselt wrote:
| You've missed the point of my comment entirely and pulled two
| items out of context.
| wruza wrote:
| You seem to ignore the fact that people ignore ux advices.
| You can ask them politely, but they'll still slap something
| together and call it a day. And there's no way a complex
| control that you described can get into popular ui libs. Or
| to be approved by all "designers". These default looks of
| type="radio" and type="checkbox" are the last stand. If you
| break it, you'll complain even more but nobody would listen
| still. Cause defaults and easy ways rule the world.
| Accessibility is a rough battle already even without ideas
| that _definitely won 't_ work.
| mixmastamyk wrote:
| I disagree with every paragraph. Too long to address every
| line.
|
| If you had better points than, it doesn't matter, idea is
| "old", and/or people can't learn, well you made them
| poorly.
| sfink wrote:
| > In this specific case, it should be clear that you can select
| multiple options from context or by text, or it should be
| encouraged to try it out (i.e. easy to undo).
|
| It seems like you're saying that because there isn't anything
| inherent in the visual difference, it is better to remove the
| difference entirely and force everyone through a less efficient
| mechanism with higher cognitive overhead.
|
| > If you need to rely on the visual difference of the icon,
| then you've already lost more than 50% of the people who don't
| realise this.
|
| Agreed, but how does having a visual difference mean forcing
| people to rely on it? The visual difference is purely an
| augmentation, and one that kicks in early enough that it
| prevents people from forming an incorrect mental model. At
| least for some percentage of people--you're saying 50% here, I
| would hazard at least 95% (of people at least a little familiar
| with using graphical interfaces). And the remaining 5% aren't
| being left out in the cold, they can always experiment.
|
| > It's really just a property of a list of checkboxes, how many
| you can select, not an entirely different class of UI
| component.
|
| I completely disagree, and in fact I think this is probably the
| fundamental error. You are talking from an implementation point
| of view. From the point of view of a user, they are being asked
| to input very different things. They are picking from a set of
| options, or they are accepting/rejecting each item in a list of
| things. It includes a distinction between one and multiple, and
| I hope you don't think _those_ are handled the same way in our
| brains. ( "Sorry, dear, I thought she was one of my wives....
| oh, right! You're the only one I have! I guess I forgot
| again.") The fact that they can both have a superficial
| manifestation as a list of options makes it _more_ important,
| not less, to visually distinguish them. Radio buttons have more
| in common with a single-selection dropdown than they do with a
| list of checkboxes.
| neilv wrote:
| > _I'm not sure when the distinction between square /round was
| introduced, but it seems to already exist in the 90-s:_
|
| I always thought everyone was mimicking the 1984 Macintosh on
| this.
| hermitcrab wrote:
| Damn you Apple!
| endofreach wrote:
| > How should we even call these? Radio checks? Check buttons?
|
| Duh, obviously it's a quantum-radio button!
| matricaria wrote:
| Apples Reminders app has been using round checkboxes for a long
| time. Not to defend that choice, but visionOS is not the first
| occurrence.
| wigster wrote:
| the horizontal switch has doomed us all. terrible design. i
| absolutely loathe them.
|
| is it on or is it off?
|
| erm, hard to tell
|
| so let's put a little mark inside it to show its on. a little
| mark. a check mark. you know, like a check box.
|
| ffs
| atoav wrote:
| There are two explainationa for apple deciding to make checkboxes
| round:
|
| - they _don 't know_ the difference between radio buttons and
| checkboxes
|
| - they know the difference between radio and checkboxes, but
| don't _care_
|
| I don't know which of those is worse.
| Nevermark wrote:
| Forgive me for reflexively jumping to one of my favorite
| critiques of the universe:
|
| Flat design weeds out a myriad of _built in affordances of our
| visual system_ :
|
| - Color to help us more quickly distinguish between things, what
| the things are, and their roles.
|
| - Borders, to demark edges of active usable elements, communicate
| roles, encapsulate closely related things.
|
| - Translucence as a way to combine subtle elements into a single
| form in a way our visual system can quickly interpret.
|
| - Texture as another means of quickly communicating topic
| separation and indicating roles. Especially useful for areas
| containing other elements.
|
| - Shading that our native visual system naturally interprets as
| rich 3D information. For processing separation, function,
| including the state of dynamic function.
|
| - Smooth motions to draw attention to, and indicate changes of
| state.
|
| I am NOT suggesting graphical interfaces should:
|
| - Resemble a rainbow Christmas tree of "look-at-me!" ornaments.
|
| - Organize hierarchical information in n-level nested Mondrian
| boxes.
|
| - Be performatively stylish: overly glassy, shiny, lickable.
|
| - Have unsubtle textures, or painstakingly recreate leather,
| felt, marble, or (dear baby Zeus) grass.
|
| - Spray shading and shadows onto everything in an attempt to
| recreate VR on a flat screen.
|
| - Sparkle, blink, bob and weave, and otherwise snow and distract
| us with motion.
|
| I am suggesting that it is madness not to sparingly use large
| dimensions of our _visual processing system_ , to communicate
| _visual information_.
|
| These extra dimensions not only provide richer information for
| our visual fovea, but to our peripheral vision. Our brain is
| constantly processing peripheral vision to create context.
|
| A classic case of form over function.
|
| A classic case of "simple" as in "less design work, trivial brand
| language consistency", not "simple" as in "easy to discover,
| understand and use".
|
| (As with the check/radio/button/selector, I cannot process that
| Apple fell for flat design. Such corporate amnesia. From design
| leader to lowest common denominator follower.)
| xuhu wrote:
| At some point material design will advance far enough that we
| can create material design apps in the terminal. I'm looking
| forward to it.
| red_admiral wrote:
| Good points, but just to be picky - there are a few good "flat
| + color" combinations out there, flat and colorless don't
| necessarily come as a package. After all, who doesn't want the
| default button to be in their brand's accent color?
| jigg4joe wrote:
| Sorry, I can't help it. It should be: "Flat design weeds out
| myriad built in affordances of our visual system"
| qwertygnu wrote:
| https://www.merriam-webster.com/dictionary/myriad
|
| There's actually a whole paragraph dedicated to explaining
| why "a myriad of" is just as correct (if not more).
| Sohcahtoa82 wrote:
| Being pedantic _and wrong_ is peak HN.
| usrbinbash wrote:
| > I therefore officially announce 2024 to be the year when the
| square checkbox has finally died.
|
| Or, alternatively, I could just not put up with Apples crap and
| use something else ;-)
| herbcso wrote:
| Fuuuuuuuuuuuuuuu...
|
| I am DEEPLY offended by this travesty! Why can't we have nice
| things!? The enshittification is real...
| cloudking wrote:
| Took me a while to find CSS property "accent-color" to style the
| color of selected checkboxes.
| keb_ wrote:
| This blog's neon yellow color scheme makes it unreadable.
| Luckily, it has a dark mode... which is unusable on mobile.
| Ironic this post about design is on a blog that's poorly
| designed.
| HackerThemAll wrote:
| "people on the Web think conventions are boring. That regular
| controls need to be reinvented and redesigned. They don't believe
| there are any norms."
|
| That's why we have the accept button in dialogs (e.g. OK) on the
| left, or on the right, or in the window's title bar, depending on
| the intensity of mental disorder of the one designing the website
| theme.
| jesterson wrote:
| It's not necessarily mental disorder. In some companies, when
| management runs out of ideas what to do, they start changing UI
| and pull revenue fluctuations as consequences of those
| "improvements".
| javajosh wrote:
| It would be a real tragedy if they discovered you could write
| a webapp such that all such "pushing around the plate"
| activity could be done via CSS. But of course that is
| insufficient "drag" to dissipate managements excess energy,
| so this activity requires backend work as well.
|
| Note that this only applies to management at cash cow
| businesses - startups have plenty of real work to do. This
| sets up an interesting dimension in the tension between the
| needs of Enterprise ("make small changes labor intensive")
| and startups ("make large changes quickly"): too much
| developer productivity would eliminate 80% of a huge set of
| bullshit jobs.
| jesterson wrote:
| They know about it, but they need to generate some
| activity. Just changing CSS is way too simple and you can't
| claim much credit for that
| sfink wrote:
| You can if you do it with an A/B test where you can argue
| about the percentage of treatment, the duration of the
| test (is the difference persistent?), and do precise time
| tracking to log how long the user takes to take an
| action. That'll bury the actual change in a mountain of
| configuration, documentation, rollout plans, etc.
| jesterson wrote:
| That'll require quite some knowledge and mental energy.
| Not many people are capable of that
| gedy wrote:
| You guys seem to be pinning this on developers, but 90% of
| this comes from ux designers and sometimes product. Devs
| are usually "just tell me what to do"
| jesterson wrote:
| It does indeed, but from my experience it comes far often
| from marketing and management.
| Kwpolska wrote:
| You don't need the Web for that. Windows puts the positive
| button on the left, macOS has it on the right, and Windows CE
| (for embedded stuff and palmtops with small screens) had OK
| buttons in the title bar.
| Kwpolska wrote:
| You don't need the Web for that. Windows puts the positive
| button on the left, macOS has it on the right, and Windows CE
| (for embedded stuff and palmtops with small screens) had OK
| buttons in the title bar.
| wruza wrote:
| These are three different languages which are (ought to be)
| internally consistent though. Humans are pretty good at
| switching contexts when there's a clear difference between
| these, like using their PC, their Mac or holding their phone.
| What they suck at is learning something that isn't consistent
| at all.
| coliveira wrote:
| But at the least the decision is the same across the OS. If
| you spend several hours using the system you will know the
| "right" way. But in the web you're on nowhere's land.
| hyperpape wrote:
| When you put it that way, it kind of undermines the snark
| towards web developers. Of course things are inconsistent,
| no one is in charge to say "this is the way the platform
| does it."
|
| There are lots of other design sins this doesn't excuse
| (low contrast, for instance), but expecting conventions to
| be as consistent as on a desktop OS feels naive.
| kps wrote:
| Doesn't a plain old <input> do it the way the platform
| does it?
| hyperpape wrote:
| I'm a little confused by your question. The discussion is
| about which button should be ok, and which should be
| cancel. The browser will not lay that out for you, you
| have to pick a layout.
|
| There are some things where the browser will apply
| platform conventions, but nothing resembling the
| consistency you'd expect from (well-designed) native
| apps.
| kps wrote:
| OK, I interpreted this thread more generally about
| controls, like the checkboxes and radio buttons of the
| OP.
| mr_toad wrote:
| The HTML input element without any styling applied is
| usually rendered by the browser using the UI conventions
| of the operating system. But nobody uses bare input
| elements these days.
| jraph wrote:
| <input> has never affected the button order. It also has
| no concept of primary / secondary button and for the
| better or the worst, has by default the styling the
| browser wants it to have, which _might_ look like the
| native buttons of the current OS, or the native styling
| of one of toolkits anyway. System colors are not
| supported consistently too (although I 'm discovering
| CSS4 a has interesting features [1], neat, but Chrome is
| lagging behind)
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/CSS/system-colo...
| Kwpolska wrote:
| Is it? What if you run a foreign app, a half-assed port, or
| an Electron thing whose developers didn't check for the OS?
|
| Nothing stops Web developers from flipping the buttons if
| they detect a Mac, but that would make things more
| confusing if someone is using the same Web app on multiple
| platforms, or if the docs have screenshots from different
| platforms (to each other or to the user).
| red_admiral wrote:
| At least in windows you can pretty consistently hit ENTER in
| a dialog box to close it with the default action, though.
| That's something that has always annoyed me on Mac.
| herbst wrote:
| Didn't windows also switch button positions regularly for all
| their nagware around upgrading to windows 10?
| VoodooJuJu wrote:
| Isn't another reason they constantly change up UIs is for the
| sake of novelty? Doesn't novel design signal "newness" to a
| prospect, which gives a desirable air of greater relevancy and
| trendiness? And does not this "newness" convert into more
| sales?
| robertoandred wrote:
| macOS had this right: dialog buttons read in ascending order of
| intent, with allowances for changing the default button to the
| one that's least destructive without changing the button order.
| Simply by reading, you were shown all available options and
| ended with the one you likely want to click.
|
| Then they threw it away to match iOS.
| masswerk wrote:
| Arguably, iOS compensated much (and even added) in the
| original skeuomorphic / Forstall-era designs. (Famously,
| toddlers were able to operate these interfaces.) The crucial
| failure was not reconsidering this from the basics for flat
| UI. At this point, it became unavoidably a mix of what had
| been learned by users, but was not indicated anymore, because
| you don't want to break traditions, and what was actually in
| the UI language. As a result, instead of a clear language,
| there is now a diffuse aura of how things may work.
|
| (Also, reportedly - I have no way to corroborate this -, in
| the Ive-era, designs were evaluated in print-outs, which is
| simply how not to do interaction design.)
| alkonaut wrote:
| That argument can easily be switched around. I likely want to
| do what I'm asked (It's likely I initiated it). So having "Ok
| whatever whatever whatever" is good.
|
| I'm assuming now of course that I'm optimizing not for least
| risk but for least reading.
| sfink wrote:
| Oh, come on. It's easy enough to figure out! It's always the
| _other_ button, as in not the one labeled Cancel. Or No.
| Rarely, Reject /Fail/Abort. Except when there's only one
| button, then you use the X in the corner. If it's there.
|
| What could be simpler?
| karaterobot wrote:
| Though I have seen a few instances of it happening, I don't see a
| widespread lack of square checkboxes. I think he's cherry-
| picking. But then I spend more time on the web than in mobile.
|
| In general, I'm not worried about this. To the extent that it is
| confusing to users, and to the extent that confusion causes
| problems, it will be corrected in time. Nobody is incentivized to
| have bad UI if it costs them money. People on HN seem to think
| designers run everything, and that they spend most of the day
| trying to make things harder for users (out of native malice, or
| because it makes them feel smart). The reality is that in most
| places, designers actually want things to be better, and product
| choices are driven exclusively by money made by users
| successfully using your app. "We can't fix our bad UI because it
| will make our designers angry" is not something I have ever heard
| said at any company I've worked for.
| rc_kas wrote:
| This makes me more angry than I expected to be or should be.
| Fuckin Apple, fix your checkboxes.
| palisade wrote:
| I think maybe the concept of () vs [] for radio buttons and
| checkboxes respectively is in part due to the mathematical
| concept of a bounded number range where the numbers at the end of
| the range are included inclusively or exclusively. I'm not saying
| they're the same concept, but that it might have inspired their
| usage. Just a theory.
| eduction wrote:
| Actually!, having two subtly different click-on selectors was
| never a good idea.
|
| There should be no "radio buttons" only checkboxes and then use
| select menus for exclusive selection.
|
| Physical push-in radio buttons have not been in new cars since
| the 1970s. Even digital radio preset buttons are gone now.
|
| Select menus, the kind that popup when you click on them, are
| unambiguously exclusive-choice menus. Just use those.
| secondcoming wrote:
| First they came for our scrollbars and I said nothing, Then they
| came for visible control edges and I said nothing...
|
| UI design has had some really questionable 'improvements' over
| the years.
| mtillman wrote:
| Good grief Sonoma looks like garbage. Hadn't looked at side by
| side comps before. Going to adopt a "don't hire designers from
| Apple" policy like the old "don't hire product people from yahoo"
| policy.
| scelerat wrote:
| Small nit: I'm pretty certain the Mac System software from
| pre-1.0 up until System 7 had identical UI widgets for things
| like check boxes, radio buttons, buttons, etc. The screen shot in
| the article is from the Control Panel desktop accessory (DA)
| which is showing radio buttons in a compressed or stylized way
| because of the compact nature of the DA
| krick wrote:
| The only place I've noticed this is Telegram UI, and this really
| throws me off every time. There's absolutely no way to tell if
| it's a multiple-choice and since you usually cannot just un-vote
| in Telegram, it is very confusing.
| crest wrote:
| What the fuck is wrong with accepting well established intuitive
| conventions? How does such an braindead anti-feature ever get
| past a second person in reviews?
| stainablesteel wrote:
| i'm honestly annoyed that you don't have example checkboxes that
| i can toggle
| a1o wrote:
| Microsoft Teams has square checkbox in their Planner app that
| behaves like radio button. Super not confusing.
| domador wrote:
| Is there any realistic way to keep big, influential corporations
| from imposing their bad UI choices on the rest of us? Can we at
| least get the word out to everyone else that this is not a fad
| worth copying and making into the new standard? (I'm looking at
| you, toggle switches, skinny scrollbars on desktop UIs, and the
| white wasteland UI designs that don't put any kind of borders
| between different sections of the screen.)
|
| I thought this article was going to be about the replacement of
| checkboxes by toggle switches, and was displeased to see that it
| was about something even worse.
| esafak wrote:
| If you want to get a word out, start a web site with dos and
| don'ts, or write a book. So if anybody wants to share
| recommendations, comment below!
| racosa wrote:
| Spotify on Android too: when saving a song, you have to select
| one or more playlists using round checkboxes. Why?
| squigglydonut wrote:
| Nah apple just cut costs and hired some year of efficiency
| designers. Usability will fail and they will need a visual
| distinction.
| j45 wrote:
| Some parts of UI/UX design are cyclical.
|
| Maybe a circular checkbox was more approachable in user testing
| than squares.
| elzbardico wrote:
| There was a definite shift in User Interfaces that we can
| associate with the huge influx of people from the advertising and
| media space in the ad-supported web. Early web sites were mostly
| programmer affairs, with the ocasional designer to build a few
| assets here and there. UX people were mostly psychologists or
| even computer scientists that were more interested in arcane
| issues like accessibility and semantics, they didn't even call
| themselves UX, they were usability specialists.
|
| Now UX is mostly a territory of designers forged intellectually
| in the media and advertising space. And this has spread even
| outside the web.
|
| Yeah, UIs now look gorgeous, but a lot of times, the beauty comes
| at the expense of functionality and usability.
|
| In any culture that is dominated by advertisers, form dominates
| function. Appearance trumps content.
| moi2388 wrote:
| This makes me experience more negative emotions than a human
| ought to have about a checkbox.
| uxjw wrote:
| Years ago, when Apple made all the icons in the Finder sidebar
| grey and then thin outlines, it became obvious the focus is about
| just changing things to set trends and ignoring the basic rules
| of usability. I still can't find what I'm looking for as quickly
| without the colors and strong shapes instead of monochrome
| outlines.
| lowkeyokay wrote:
| Have you never mistaken a checkbox for a radio? I have not. At
| least not to the point I've noticed. Consistency within an app is
| important, but done well, I think it's okay to break with
| conventions.
| hooby wrote:
| May I draw your attention to the light-mode/dark-mode toggle-
| switch-button-thingy of this very blog? ;)
| esskay wrote:
| I'm mostly surprised Windows defaults to rounded. I know their UI
| is a complete shambles but they seemed to be leaning towards non-
| rounded user interfaces over the last few years.
| walteweiss wrote:
| What a dark mode on a mobile, woah! Just try it yourself.
| garfolino wrote:
| It didn't die. It's just trans.
| neycoda wrote:
| Checkboxes looking like radio buttons is a clear sign of things
| getting stupid. People defending this aesthetic is a sign of
| stupidity being trivialized. People being ignorant to the
| problems the stupidity causes is a sign of a subconscious desire
| to self-destruct.
| rcarmo wrote:
| Oh goodness. I hope Bruce Tognazzini hasn't seen this.
| thomastjeffery wrote:
| What we never talk about is how we could have avoided this entire
| mess in the first place.
|
| We should have _never_ put configuration in the same place as
| presentation.
|
| Presentation is what you are telling the user. Configuration is
| what the user is telling you.
|
| By mixing the two together, we have muddled the context of both.
| What is your configuration presentation meant to say?
|
| 1. The user has rewritten (present/past tense) your set of
| declarations. This shall be read as a positive:
| [x] volume muted [x] unsubscribed
|
| 2. The user declaring a set of _future changes_ to your set of
| declarations. This shall be read as a negative:
| [x] volume mute [_] unsubscribe
|
| Neither of these is guaranteed to be unambiguous. Neither of
| these is even expected to tell you which one it is!
|
| This is why configuration files are so well-regarded. The context
| they exist in defines the tense of their contents. Somehow, we
| never invented the GUI-equivalent of a filesystem, and we are all
| the more confused for it.
| jtotheh wrote:
| Abort/Retry/Fail
___________________________________________________________________
(page generated 2024-01-29 23:01 UTC)