Hacker News Reader

Comment by andirk | Hacker News Reader

Does the confirm or cancel go on the left or the right? How is that not even accidentally standard at this point?

OS X had OK to the right, Windows had OK to the left. Now Apple has removed OK buttons in favour of writing the action on the button, which makes much more sense. Inspired by BeOS maybe?

So instead of "Do you want to save before you quit?" "OK / Cancel" it is now "Do you want to save changes?" "Cancel / Save"

The original Mac’s layout was

    (Yes)
    (No)       (Cancel)

They switched from that to

    (Don't Save) ----- (Cancel) (Save)

with System 7.0 in 1991.

From the outset, Apple’s HIG recommended using more descriptive words rather than 'OK'.

Confirm goes on the right, cancel goes on the left. Similar to next and previous.

Anyone doing it the other way, I'm curious what the reasoning is for that.

KDE puts confirm on the left, iirc their reasoning is that people read left-to-right and want to see the most likely option first.

(Screenshots: https://freeaptitude.altervista.org/articles/show-a-dialog-w...)

As sibling says, ultimately it's best to follow the platform convention so your app doesn't confuse anyone or cause them to misclick.

Different operating systems have different conventions.

Windows centre- or end-aligns all these buttons (depending on the context), with Cancel last (generally mapping to having the primary action first). That has been its convention since at least the start of Win32 era. If you’re targeting Windows, this is probably what you should do.

Another platform end-aligns all these buttons, with the primary action last.

Still another platform stretches buttons, with the primary action last.

Others have cause to split things, start-aligning any cancel/negative button, and end-aligning others.

If you’re targeting a particular platform, you should generally aim to match its conventions unless you have very good reason not to.

One piece of related reading (and you can easily find others): https://www.nngroup.com/articles/ok-cancel-or-cancel-ok/

And so because a Windows person was carless 40 years ago, we still have poor pattern today.

With the way Windows has always laid things out and designed its buttons, its ordering is, I think, objectively at least mildly superior, following reading order and with no major stylistic difference between the buttons. Platforms that have switched to doing things other ways have normally (and more recently I think it’s consistently) been laying things out differently and/or designing their buttons differently. On mobile devices especially with their right-hander bias, limited maximum width and screen-based navigation, primary action to the right is objectively superior, for tactile and UI flow reasons.

Not sure. When I wrote it the other way I was thinking windows did it the way I said (I only use windows at work). Turns out they do it how I think is backwards, but looking at it I don't think it's a big deal.

Because it is specific to a given platform and culture.

For example: https://ux.stackexchange.com/a/1077

There isn’t one standard set of guidelines. Platforms evolve, new ones come, guidelines will always be contradicting each others in weird ways (like this button positioning).

I've seen Windows "wizards" that manage to swap them between steps.

I have a HP wide format printer where after loading in a roll of paper, it presents a "Paper loaded successfully" dialog, with an "Ok" button to dismiss the message. The fun part is that the dialog also dismisses automatically in a couple of seconds and the UI underneath has the "Unroll paper" button in the exact same position where "Ok" used to be. I must have accidentally unrolled the paper immediately after loading it in dozens of times by now.

That is just plain evil.

The only justification in my mind that makes sense for having it one way and then the next screen is the opposite is in the case of destructive actions (e.g. formatting a drive). It can help prevent users on autopilot from nuking things.

The only example of this that comes to mind is factory resetting a Nintendo Switch, but I'm sure there are much more.

If you're worried about autopilot, The button should move around so that auto pilot clicks have no effect, not change meaning. Or, require text input to confirm an action.

Thinking back to a link posted here a few months back [1], the call to action goes on the outside edge because it's visually the heaviest element.

So if the buttons are on the right of the dialog, "OK" / "Save" would go on the right; and opposite if they're on the left side of the dialog.

I'm far from a designer but I read through this a few times and think it's pretty good.

[1]: <https://anthonyhobday.com/sideprojects/saferules/> "Visual design rules you can safely follow every time"

Reply on news.ycombinator.com