[HN Gopher] In loving memory of square checkbox
___________________________________________________________________
In loving memory of square checkbox
Author : kevingadd
Score : 1280 points
Date : 2024-01-28 00:36 UTC (22 hours 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.
| 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?
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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!
| 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.
| 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:
| 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.
| 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.
| 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.
| 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.
| 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".
| 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?
| 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.
| 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_"
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| mwcampbell wrote:
| To clarify, are you referring only to Motif, or the Windows
| 9x classic look as well?
| 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.
| 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?
| 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
| 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.
| 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.
| 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.
| 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.
___________________________________________________________________
(page generated 2024-01-28 23:00 UTC)