In loving memory of square checkbox

Or when you try to unsubscribe from a mailing list and are prompted:

  Unsubscribe from the following:
  [X] List A
  [X] List B
  [X] List C

  [ ] Unsubscribe All Lists

I would say a solid 80% of unsubscribe prompts have some sort of similarly confusing layout or verbiage.

I would not be able to tell if these slider toggles were saying "yes" or "no" without them going from gray to green. How do colorblind people deal with them?

That the whole world adopted these abominations, when there was absolutely nothing wrong with checkboxes, is immensely frustrating.

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.

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.

My "favorite" is when they use green color to indicate "Off". Like in this page

https://www.istockphoto.com/plans-and-pricing

The dark patterns here are something to behold (A bit like Adobe's stuff)

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.

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.

I don't like these. They can be mistaken to users as an indicator of what moving the "lever" to the other side of the toggle button will actuate - effectively reversing the user's intent of the button as compared to what the buttons do.

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

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?

Canon does this everywhere in their camera UIs, e.g a button with "(eye-tracking icon) ENABLE". Gotta open up the full settings UI to remember which way it works. IIRC, they actually show the current state (ENABLE = ENABLED), not the action that will be taken when you tap the button, but I might be misremembering... again.

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.

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.

That was true in the 90’s when you’d post a whole page but these days the individual checkboxes are more likely to have event handlers that transmit state to the server immediately.

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.

> 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.

> I think it's pretty objective at this point that an icon based toggle should show the current state, not the state that tapping on the icon will produce.

What about a play button? On YouTube, or any music app, the button will show the Play symbol when the media is paused, and the Pause symbol when the media is playing.

> 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

“The sudden realization that the throne was empty.”

It isn’t clear which is which if they all are unchecked

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.

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?)

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.

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.

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.

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.

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.

Didn't windows also switch button positions regularly for all their nagware around upgrading to windows 10?

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.

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.)

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.

You can with a terminal AI chat bot tuned for app development

https://www.merriam-webster.com/dictionary/myriad

There's actually a whole paragraph dedicated to explaining why "a myriad of" is just as correct (if not more).

Being pedantic and wrong is peak HN.

The MacBook Wheel!

https://youtu.be/9BnLbv6QYcA?feature=shared

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.

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/

That's called a poker machine.

I think they're smart enough to stop at: "press this and we'll take your money and tell your friends you're cool."

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.

Can you share a picture of this?

Upvote just for sheer passion (using word count as a proxy for this)

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.

What does the 2035+ version of this look like? Seniors pushed to VR UIs?

And the UI completely changes every year or three, because progress or something.

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.

"X will not run in these 4 bit overlay planes. This is because I’m using Motif, which is so sophisticated it forces you to put a 1" thick border around each window in case your mouse is so worthless you can’t hit anything you aim at, so you need widgets designed from the same style manual as the runway at Moscow International Airport. My program has a browser that actually uses different colors to distinguish different kinds of nodes. Unlike a PC Jr, however, this workstation with $150,000 worth of 28 bits-per-pixel supercharged display hardware cannot display more than 16 colors at a time. If you’re using the Motif self-abuse kit, asking for the 17th color causes your program to crash horribly." -Steve Strassman, Unix-Haters Handbook

https://news.ycombinator.com/item?id=25734498

https://medium.com/@donhopkins/the-x-windows-disaster-128d39...

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.

To clarify, are you referring only to Motif, or the Windows 9x classic look as well?

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.

> 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.

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.

Electron-based applications seem like a hugo factor. When native applications were abandoned in favor of Electron, designers stopped trying to match their designs to established operating system standards and began designing from scratch, with much poorer results, because they didn't have the resources and experience of teams that had worked on major OSes.

Prior to that, deviations from established standards (layouts, colors, logic) were seen as unprofessional and tasteless. Things like buttons with unusual colors made software look like a shareware hobby project downloaded from Tucows, and nobody wanted their product to trigger these associations. Premium software made for Windows wanted to have the look and feel of Word and Excel.

It started as user-centric research and when the user became the product the intent of this research shifted.

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.

Designers still want to work, so they change stuff randomly and sell it as "modern".

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.

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.

Which era's programmers favored code simplicity over the UX? I find this hard to believe.

Imagine the poor bastards in the future trying to comprehended the floppy-disk "save" icon.

Me too! I had assumed that 'radio button' was a bastardization of 'radial button', referring to the very shape which the author notes is conventionally used for them.

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.

I like its design - it's simple and familiar and just works. The circular checkboxes are annoying tho.