Hacker News Reader

Comment by HackerThemAll | Hacker News Reader

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

View on HN

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.

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.

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.

Doesn't a plain old <input> do it the way the platform does it?

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.

OK, I interpreted this thread more generally about controls, like the checkboxes and radio buttons of the OP.

The HTML input element without any styling applied is usually rendered by the browser using the UI conventions of the operating system. But nobody uses bare input elements these days.

<input> has never affected the button order. It also has no concept of primary / secondary button and for the better or the worst, has by default the styling the browser wants it to have, which might look like the native buttons of the current OS, or the native styling of one of toolkits anyway. System colors are not supported consistently too (although I'm discovering CSS4 a has interesting features [1], neat, but Chrome is lagging behind)

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/system-colo...

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

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

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.

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

You can if you do it with an A/B test where you can argue about the percentage of treatment, the duration of the test (is the difference persistent?), and do precise time tracking to log how long the user takes to take an action. That'll bury the actual change in a mountain of configuration, documentation, rollout plans, etc.

That'll require quite some knowledge and mental energy. Not many people are capable of that

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"

It does indeed, but from my experience it comes far often from marketing and management.

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?

Oh, come on. It's easy enough to figure out! It's always the other button, as in not the one labeled Cancel. Or No. Rarely, Reject/Fail/Abort. Except when there's only one button, then you use the X in the corner. If it's there.

What could be simpler?

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.

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.

Reply on news.ycombinator.com