
Ok-Cancel versus Cancel-Ok - zaksoup
https://www.factorio.com/blog/post/fff-246
======
jaysonelliot
This has been a debate for as long as I've been a UX designer (mid '90s), and
probably much longer.

Ultimately, the answer about this UX style is very much the same as a question
about writing style—there's no objectively right answer, but you have to be
consistent.

For example, you can pick up any number of style books from Strunk & White to
the Chicago Manual of Style and get different "right" answers about writing
style, but any editor will tell you the ultimate solution is to be internally
consistent.

The arguments for each approach have merit. "OK on the left" designers will
argue that because we read from left to right, the positive response should be
first. "OK on the right" designers will say that the positive response carries
the user forward, and because we read from left to right, forward progress
should be on the right.

My personal feeling is that there's another argument for OK on the right,
which is that the majority of users are right-handed, so the default choice
will be closer to their dominant hand if it's placed on the right.

Then again, I may be looking for evidence to support my preference, which
probably arose from the fact that I began designing on the Mac, so I was
conditioned to Apple's "OK on the right" standard at an early age, and I've
simply conflated "familiar" with "correct."

So the answer from this veteran UX designer would be: Use whichever placement
your users are going to be the most familiar with, but whichever you choose,
be 100% consistent with the choice you make.

~~~
cyberferret
Back when I used to build model aircraft dioramas, a veteran told me "When you
arrange vehicles in a diorama setting, always have them facing towards the
left side of the board for maximum impact.".

His reasoning was that most people's eyes move left to right when examining
something - which mimics their eye movement when reading text (at least in
Western societies. In R-L countries I guess the opposite would be true).

He said that by position the nose/cockpit of the aircraft on the left side,
people's eyes would always go to where the 'little humans' would sit first,
then move away towards the right. Similarly if you had scale model humans in a
diorama setting - place them on the left hand side.

Placing the vehicles going against their eye movement would also make their
attention 'catch' and stop at details of the object 'moving' in the opposite
way (something about how people who drive cars are just more instinctually
aware of something that is moving against their direction of travel). Whereas
if they had to scan in the same direction the vehicle was moving, their
attention would just slip past interesting points.

I've used those lessons in most of my UX design nowadays. Placing buttons and
important items towards the right of a page, with lesser items further right.
The only exception is if it is a destructive action call (deleting a record
etc.), then I usually place the button all the way to the right so it isn't in
visual way and too tempting.

~~~
fnord123
Toy cars in shops have the cars and trucks all facing right in the packaging.
Maybe they've done some ab-testing to get this way. Maybe not.

Maybe putting his airplanes facing left made your veteran's models pop because
they were inconsistent with other models.

Anyway, if you want to make people read the options on buttons, randomize the
order each time the popup appears but always destructive buttons like "delete"
red colours.

~~~
laythea
Please don't randomise the location of UI components. I don't want to have to
find the button I want. Your users will thank you.

~~~
tehlike
Agreed, but I would still do it on a small traffic/user to see its impact.
This kind of data is invaluable.

------
scrollaway
HN folks will appreciate the entire Factorio blog. They are super open about
the design of their game and it's full of micro-postmortems.

[https://www.factorio.com/blog/](https://www.factorio.com/blog/)

Also, if you're reading this, you are in a demographic that is likely to
absolutely love Factorio. Go buy it, it's 20 eur/usd, you won't regret it.

Some call it "Programming: The Game".

~~~
smichel17
> Some call it "Programming: The Game".

This is actually why I _haven 't_ bought it (yet). When I have the urge to
program something, I think I'd rather put that towards building something real
than playing Factorio.

~~~
fishtoaster
I love factorio because it's the most like programming _without actually being
programming_. Opus Magnum is a game in a similar vein that came highly
recommended, but I never got _that_ into because it _is_ actually programming:
there's an instruction set that you program visually. Factorio, on the other
hand, is closer to an RTS. Except whenever you find yourself doing something
tedious, you can just put in a little more work to automate it and never have
to do it again. It's the automation aspect of programming, but no actual
programming.

~~~
XorNot
This. My mind was blown when I realised that the initially hard to make
grabber arm could be just put in a factory and suddenly I'd have an endless
supply of grabber arms forever.

------
psychometry
Technically, they're both wrong. Button labels should be verbs. The Cancel -
Open example from OS X is the right way to do a dialog box.

~~~
tridentlead
Not really, Ok can be a verb. You can “Ok” a change.

~~~
JonathonW
"Ok" for a change (that's described in the body of the dialog's text) is...
okay, I suppose.

But it's _better_ to mirror the action verb for your confirmation button,
because users don't necessarily _read_ the text you present them with. So,
instead of this:

    
    
        Delete xyz.jpg?
        --------------------------
        The file 'xyz.jpg' will be
        permanently deleted.
        --------------------------
                 [ OK ] [ Cancel ]
    

You have:

    
    
        Delete xyz.jpg?
        --------------------------
        The file 'xyz.jpg' will be
        permanently deleted.
        --------------------------
             [ Delete ] [ Cancel ]
    

And you get one more chance for the user to see what action they're about to
perform.

There's very good, detailed guidance on this in the Windows design guidelines
(the design-specific aspects are a bit dated since everything there refers to
Vista/7-era UI elements, but their guidance on text and dialog styles is still
applicable):

Text: [https://msdn.microsoft.com/en-
us/library/windows/desktop/dn7...](https://msdn.microsoft.com/en-
us/library/windows/desktop/dn742476\(v=vs.85\).aspx)

Dialog Boxes: [https://msdn.microsoft.com/en-
us/library/windows/desktop/dn7...](https://msdn.microsoft.com/en-
us/library/windows/desktop/dn742499\(v=vs.85\).aspx)

~~~
userbinator
Actually "mirror the action verb" surprises/confuses me even more than "OK"
"Cancel", since the latter are standard and almost expected, whereas anything
other than a positive/negative response feels unexpected. It's like the real-
life equivalent of asking someone a yes/no question --- you're expecting a
yes/no answer. In fact, I'd say this is even clearer, putting the question at
the end and immediately following it with the two choices:

    
    
        The file 'xyz.jpg' will be
        permanently deleted.
        --------------------------
        Delete xyz.jpg?
        --------------------------
                    [ Yes ] [ No ]
    

...and this also coincidentally gives a reason for the order of OK/Cancel ---
affirmation on the left, denial on the right.

~~~
jacobolus
Please force the reader to directly click an action verb. It is much easier to
skip over text (even text that comes immediately before) misinterpret the
dialog, and click the wrong button when using generic button labels "yes" and
"no".

And more generally, before disregarding industry best practices and findings
from research literature and implementing something based on ad-hoc personal
hunches, make sure you run some experiments on real people.

~~~
userbinator
_industry best practices and findings from research literature_

That's the cop-out answer I get whenever I ask about unnecessary and
infuriating UI changes. It has only given rise to increasingly dumbed-down,
stupifying interfaces.

~~~
jacobolus
Huh? It is a “cop out answer” to suggest reading the research literature as a
general practice? It is an “unnecessary and infuriating UI change” to roughly
follow UI guidelines written down by experts with decades of experience?

I am recommending that instead of just making something up based on the
developer’s speculation and personal preference (which in your particular
example happens to be terrible, as you would discover if you actually tested
it in a real-world setting), it is a better idea as a general rule to go read
actual user studies about what works and why, or if you are too lazy to do
that go find some interface guidelines written by someone who did large-scale
user studies and spent decades honing their interfaces in response to user
feedback and copy it.

If you insist on rejecting those findings and past experience with a novel
implementation, then I am recommending running your own mini studies (ideally
something semi-formal, but at least test the two versions on a couple buddies
at a coffee shop), to make sure you don’t shoot your foot off. To do anything
less is in my opinion lazy and irresponsible.

Why do you think that will lead to “stupefying interfaces”?

You think that doing at least a tiny bit of user research before blindly
rushing ahead based on personal preferences renders people unable to think or
feel?

Or maybe you have a non-standard definition of “stupefy”? To be honest I don’t
understand what you are trying to say.

~~~
userbinator
_which in your particular example happens to be terrible, as you would
discover if you actually tested it in a real-world setting_

My points all come from real-world experience, both as a user and developer.
These unwanted UI changes irritate me enough to complain about them, but
apparently my opinion doesn't count at all, because these so-called "experts"
will only parrot their vague "studies show that X, therefore you are wrong"?
These "user studies" naturally bias towards the worst of the worst. In fact,
you are displaying exactly the sort of dismissive holier-than-thou attitude
that I've been on the receiving end of, multiple times, and I can personally
tell you that it _really fucking pisses me off_.

Think about it: if I'm the user of your software, and you change it so that it
breaks my workflow, I am not going to be happy regardless of whatever
justification you provide.

Having been on the receiving end of that, I've learned not to do it to my
users, because I know how it feels.

~~~
jacobolus
I honestly have no idea what you are going on about. Nobody else is talking
about “changes”, workflow-breaking or otherwise.

You said “In fact, I'd say this is even clearer, putting the question at the
end and immediately following it with the two choices:”

Did you ever test this explicitly vs. the recommended alternative of using
verbs for labels? (Ideally by doing a user study, but heck, I’ll take
anything...)

I claim that this has been empirically tested and found to be inferior (i.e.
result in higher error rate) in a variety of studies, both in published
research and internal to various large companies which then got baked into
their design guidelines. This was a subject of active research in the
1970s–1990s (and perhaps before).

You can find reasonably good advice about the subject in any number of
introductory interface design textbooks, etc.

In this particular case, where user data is being irrevocably deleted, errors
are especially harmful.

Edit: Maybe the word “terrible” in my previous comment was unfair. Sorry to be
inflammatory.

------
makecheck
It’s not just the _order_ but the _placement_ , the _titling_ , and ultimately
the whole message being presented.

Windows managed to do this as backwardly as possible (no pun intended).
Switching their button order vs. the Mac might not have mattered if Windows
put the first button in the bottom _left_ corner for predictability. Instead,
they right-justified an entire group of left-ordered buttons so you have no
way of knowing if the corner button will be the main action. Then they tended
to use nondescript button titles, made worse by APIs that make it easier to
pop up yes/no questions than Action1/Action2 (i.e. custom titles) so apps
lazily trend toward nondescript. And _then_ the OS had relatively tiny fonts
without formatting that made it hard to understand at a glance what a message
is even asking, requiring careful reading to proceed.

A _good_ UI is not a very simple thing, there are lots of details to be
considered.

------
latexr
On macOS I have turned on the setting that lets one tab through all controls
(System Preferences → Keyboard → Shortcuts → All controls).

When a “Cancel OK” dialog appears, “OK” is the default choice (in blue) but
Cancel is the highlighted one[1], presumably because it’s the first option.
This is incredibly convenient because ↵ will activate “OK”, while pressing the
space bar will activate “Cancel”. One gets used fast to pressing a single key
to act on a dialog, instead of having to tab through controls.

[1]: [https://i.imgur.com/zsX66tX.png](https://i.imgur.com/zsX66tX.png)

~~~
Too
Wow, you have to manually activate such an option? On windows it's default.

One of the things i love about windows is that it's always been designed for
keyboard only use, not just bolted on as an afterthought. Every dialog,
widget, application and feature can be used with only the keyboard and it's
fast, easy and predictable how to. Unfortunately since windows 8 there's been
some regressions in this area with the new metro interface. Defaulting the
underlined hotkey to off (since windows xp), was also a big mistake imo.

~~~
oneeyedpigeon
Keyboard support on the Mac is _terrible_. It's probably the biggest flaw of
the OS, imo. You wouldn't believe some of the ridiculousness - for example,
the page up/down, home/end keys are application-specific in their behaviour.
Moreover, they sometimes move the view, _but not the cursor_ \- an insane
behaviour. I regularly find myself moving to the top of a document using the
keyboard, then remembering I'm wasting my time and reaching over for the
mouse, one click, and back to the keyboard...

~~~
danaris
> Moreover, they sometimes move the view, but not the cursor - an insane
> behaviour.

It's an incredibly useful behaviour.

I can't tell you how many times I've had my cursor ready to type a method
name, realized I didn't recall the precise wording of the method or the order
or type of its arguments, and paged my way up to where the method was defined
in the same file...then _not_ had to labouriously search my way back to where
I was and click in the right spot to type, but just start typing as soon as I
had the information. Bam, it types it in the right spot and jumps the view
back to it for me.

------
Ensorceled
I briefly managed a team where the two senior developers were in the middle of
a style war. Half the team was K&R the other OTBS. And half the UI was Ok-
Cancel and the other half Cancel-Ok.

Years ago, we had a critical for a “company saving trade show demo” setup on
an early version of Windows NT. There was a server fault and when we brought
it back up there was a glitch. No matter what we did the system kept
presenting us with a modal warning that proceeding would probably destroy the
data on the hard drive. The choices where Ok and Continue. After several calls
to MS we finally called our partners and GE was able to back channel us to the
developer who wrote the modal who told us “Continue” was the safe option. At
least he admitted it wasn’t the best way of presenting “do it” or “skip this
step” options.

Personally, I’m firmly in the Cancel —- “verb the thing” camp these days.

------
hoosieree
All of these are wrong, because they're answering the wrong question. Stop
second-guessing the user!

Get rid of all these buttons, but provide a mechanism to UNDO the change.
Linear undo plus the option to reinstate "factory default" settings is
probably optimal for most applications.

Would you tolerate a text editor that asked you to confirm each letter you
typed?

~~~
ggg9990
Undo support can 5x the cost of a feature and in some cases is impossible
(instructing some other entity to perform an action). It’s not feasible in all
scenarios.

~~~
lewisinc
It depends how you architect. Generally yes. Check out the Elm architecture
(and Redux by extension) to see situations where undo is essentially free.

~~~
jeremiep
Anything where your app state is modelled as a series of actions over
immutable data, undo and replay will be essentially free to implement :)

~~~
blackenough
destructive updates to your universe, or actions with side effects (anything
regarding io) might not be recovered by a simple state management. delete my
account, charge my credit card, add a friend, delete a friend...

~~~
jeremiep
But that is precisely how undo is currently implemented most of the time. Its
a series of actions where you know how to undo the side-effects, or you know
it was a destructive update and you just skip the undo of that step.

Where I have issues with that is it usually feels like an afterthought rather
than a first-class feature.

If you instead model your application after an event log then your current
state is just a fold over these events. You have the same list of actions you
previously had to manage undo, but now its positioned at the very center of
the architecture.

And then you start seeing emergent features of that design:

\- you can time travel the UI's state, which is probably the best debugging
tool you can have for UIs.

\- you can replay the event log over fixed application code, which greatly
decrease iteration times.

\- it moves logic outside of the UI components, making the app easier to unit
test.

\- you're storing a sequence of intents rather than results; its effectively
free to audit such a design, its convenient to report the last X actions
performed with a bug report and more precise than asking the user what they
were doing.

The list goes on and on. I believe most of the complexity in applications is
generated from the fact there is very little synergy between the different
features of these applications. If everything requires a different abstraction
and set of indirections, then you're just accreting complexity over time.

If you have a design where features can emerge from it, its usually a safe-bet
to say you're on to something :)

------
Someone
Interestingly, Apple’s Human Interface Guidelines from the 80’s do not say the
order must be Cancel—OK.

They say:

 _”In general, dialog boxes should be laid out with the most important
information and controls at the top left, working down to the less important
information, ending with the default button—the button most likely to be
clicked—at the lower right”_

So, there’s “in general”, and “most likely to be clicked”.

The first leaves wiggle room, and the latter opens the door for changing the
order. They even almost give an example: an alert “Are you sure you want to
erase all changes to your document?” with buttons “Erase” and “Don’t Erase”,
in that order, with “Don’t Erase” being the default button.

I don’t remember ever seeing a dialog on a Mac in those years that had
OK—Cancel, though (there were a few in the 90’s from bad ports)

------
tzs
There was a widely used program on Windows back in the 95 days that on the nag
dialog asking free users to get the paid version would random switch between
the two orders. The idea was to keep people from unconsciously clicking
through that dialog.

I think this was WinZip, but am not certain.

~~~
code_duck
It's an effective dark pattern. Many websites practice similar trickery.

~~~
dchest
I wouldn't call it a dark pattern: there's no trickery or deception; nothing
bad happens if you pressed the wrong button. It's called a "nag screen", and
in many cases it's the only difference between a trial version and a paid one.

Here's an example from Total Commander:
[https://www.dedoimedo.com/images/computers_new_2/windows-
coo...](https://www.dedoimedo.com/images/computers_new_2/windows-cool-apps-tc-
nag.jpg)

(the number to press changes randomly between launches)

~~~
code_duck
It's an attempt to trick the user into clicking the wrong button. Maybe not
dark, since all that happens is it annoyingly opens an website, but
nonetheless, it is not pleasant or user friendly to intentionally deceive
others into doing something they wish to avoid. I believe that practices that
are labeled the dark patterns on websites often have no more impact than that.

I'd call it 'user hostile'.

~~~
dchest
No, it's a attempt to intentionally slow down user. I don't remember nag
screens that open websites: it either tells you that you press the wrong
button and re-randomizes the button order or quits the program. There are also
versions that just have a timer that enable "Continue" button after a few
seconds (e.g. [https://kinzuakid.files.wordpress.com/2009/05/gsak-nag-
scree...](https://kinzuakid.files.wordpress.com/2009/05/gsak-nag-screen.jpg)).
It's very different from websites that trick you into clicking a button that
leads you somewhere. It's a _nag_ screen in a demo version that you can get
rid of by purchasing the program. It intentionally nags/annoys users, but very
far from dark or gray patterns. In fact, many of them only appear if you
violate the license by using the program after the allowed period; being
slightly less user friendly but still allowing users to use the program.

~~~
code_duck
I do recall nag screens that open websites, so that's what I am referring to.
I believe Winzip did this, as did other 2000 era software. It seems to me that
this happens in many mobile applications in modern times, though I don't know
as I don't use many. Since many screens in mobile applications are drawn from
the Internet and serve the same purpose as a website, the distinction is not
significant.

Opening parts of the application that I don't intend to open in an attempt to
force me to look at them is disorienting, distracting from work, and gives
rise to emotions that I do not wish to experience.

As far as your conclusions about this not being user hostile, or a gray or
dark pattern, I disagree. We must be operating from different definitions of
user hostility. I don't wish to participate in psychological warfare and
regarding my use of a program. If they wish to cut off or restrict usage of
it, they should simply do so.

As far as things like timers or other shareware style restrictions, they seems
legitimate to me, though obsolete. It strikes me as a different topic.

------
doubleunplussed
One thing bugs me about the GNOME way of doing things. OK is on the right,
cancel is on the left, great. Consistent and easy to get used to.

But...with client-side-decorations, these dialog buttons are often present
_instead_ of the window buttons (i.e. close/minimise/maximise). But the window
buttons are on the _right_!

So you want to close a normal window with window buttons? Top right. You want
to cancel a dialog box that uses CSD? Top _left_.

This confuses my muscle memory to no end, as I have to check if a window is a
dialog box or not before I can move my mouse to close it. And it's not like
they'll eventually make every window a dialog box - accidentally opening
gnome-terminal will always be a normal window to be closed with the close
button and not a dialog button.

I think the best solution is to switch the Window buttons to the left like
Ubuntu used to do.

------
boterock
Countless times i've been victim of the "do you want to save?" dialog where
the replies were |Yes|No|Cancel|. In some cases the brain knows it made a
mistake, and whatever dialog comes, the reply should be the negative one. And
with those options, the subconscious clicked No (the most destructive
operation) before I knew what was happening. To me, the buttons should read
|Save|Discard|Go back| in whatever order the creator wants. I think that even
the dialog could just skip the text, with those button labels it isn't needed
at all.

~~~
YokoZar
Factorio's Save implementation is one of the worst I've ever seen.

If you start a completely new game, the default name for a save game is the
previous game you were playing. This means that you can very easily overwrite
hundreds of hours of gametime by dabbling in multiplayer or a test map.

I reported this but it got closed by some jerk moderator as "working as
intended" \- looks like it got forgotten:
[https://forums.factorio.com/viewtopic.php?f=23&t=46646](https://forums.factorio.com/viewtopic.php?f=23&t=46646)

It's still the behavior in the game.

------
doh
Years ago I read an article [0] that was championing Cancel-Ok based on the
fact that most of the world reads from left to right and thus the eyes move
from left to right. If you use Ok-Cancel, user's eyes have to essentially go
back to the positive action, which is the one that they do more often.

[0] [http://uxmovement.com/buttons/why-ok-buttons-in-dialog-
boxes...](http://uxmovement.com/buttons/why-ok-buttons-in-dialog-boxes-work-
best-on-the-right/)

~~~
Stratoscope
I wonder if they are really sure about that.

What do you think, no or yes?

~~~
doh
Well, it convinced me at that time, so now I force all our designers to
structure it also as Cancel-Ok. On the surface it makes sense to me, but that
doesn't mean it's correct.

So I go with Cancel-Ok, but holding this conviction very loosely.

~~~
Stratoscope
This is one of those things where there is no wrong or right answer. We are
just trying against all odds to find _something_ that will help users feel
comfortable and make the right choice.

My philosophy used to be to follow the native platform convention, so on Mac
it's Cancel-OK, on Windows or Linux it's OK-Cancel. Seems simple, do what
people are used to.

But what about a web app that someone uses on Mac at work and Windows at home,
or vice versa? Do they expect the app to work the same wherever they use it,
or do they expect it to follow the different native platform conventions?

My mind is spinning.

~~~
abrowne
> Linux it's OK-Cancel.

KDE yes, but GNOME and most GTK+ desktops and apps are definitely Cancel/OK.

Google used to be pretty mixed, but Android and the Material re-designed
stuffs seems to be pretty much Cancel/OK too.

~~~
badsectoracula
As i show in another reply below, it is only GNOME/GTK that does Cancel/OK,
while every other environment and toolkit does OK/Cancel - this includes KDE,
Tk, Motif, FLTK and even some classic X11 apps like `bitmap` use OK/Cancel.
This is also the case with console-based UIs, like dialog, picotui and free
vision which all use OK/Cancel. So GNOME/GTK is really the odd one out going
against what everyone else is doing. It is also interesting to note that this
was changed in GTK2 days since GTK1 does also use OK/Cancel:
[http://pike.lysator.liu.se/generated/manual/images/predef.GT...](http://pike.lysator.liu.se/generated/manual/images/predef.GTK1.FontSelectionDialog.1.png)

~~~
abrowne
I'm not disagreeing, but on the Ubuntu MATE computer I'm using now, for
graphical apps at least, I have only have apps using GTK+ — including partial
users like Firefox —, Qt and wxWidgets (plus mpv, which doesn't seem to have
any dialogs anyway). Qt and wxWidgets adapt to GTK+ conventions when used with
GTK, or use parts of GTK+, like open/save dialogs, so everything, or nearly
so, that I use is Cancel/OK.

I think GNOME started intentionally copying MacOS starting with the GTK+ 2
days.

Out of curiosity, I just installed Blender, which uses its own custom toolkit.
The only dialogs I could find were open and save, and it has the open/save
actions on _top_ and cancel _below_. (That's actually what unstyled(?) Qt
apps' open/save dialogs do too, as I've just seen in KeepassXC installed as a
Snap.) That's one way to not take sides here ;-)

~~~
badsectoracula
AFAIK in Qt you can "tag" the OK/Cancel buttons and the theme can provide a
hint to swap them around, however the default seems to be OK/Cancel and KDE
uses that going back to KDE1. I've also heard (but not confirmed since i do
not have it) that if you use GNOME and run a Qt app, Qt will automatically
swap the buttons - if that is the case then it might also do it with other
common GTK+-based DEs.

About the vertical orientation, actually i've noticed that not only in Blender
but in other programs and toolkits too. In the latter toolkits, it most likely
comes from Win9x/2K/XP which used this vertical layout (i think Vista
rearranged the buttons to be horizontal).

------
foobar1962
> But little I knew, that this is actually specific to windows, and on Linux
> or macOS, the order is reversed...

Did anybody else pick this up? The person has only ever seen Windows. That’s
extremely limiting.

A later comment talks about how Microsoft designed things... one of the big
differences between Mac and (DOS and early Windows) was that Mac developers
tended to use the Apple tool kit and design guidelines, but the other platform
devs tended to inventvtheir own and go their own way — being deliberately
different.

I taught computing in the early 1990s around the transition from DOS to
Windows 3.1 and on a Mac if you learned to print in one app you had it right
for all others. With DOS each app was a completely different set of key
presses (looking at WordPerfect and Lotus 123). Windows standardised this but
it took a while for devs to catch on that consistency with other apps is good
practice

~~~
rkuykendall-com
> Did anybody else pick this up? The person has only ever seen Windows. That’s
> extremely limiting.

The original Factorio team ( once they grew to 3 ) developed 100% on Windows,
Mac, and Linux respectively. So Twinsen may have very little experience
outside of windows, that probably helps him develop an authentic Windows
experience, while the Mac and Linux developers do the same, and the result is
a great cross platform game.

Disclaimer: My in-game hours for Factorio probably qualify me for Stockholm
syndrome, so lots of bias here.

------
zaksoup
> Make it so much different and Factorio specific, that the way it is done in
> your specific system will not interfere with your muscle memory

I think this is a really thoughtful way to deal with the problem of x-platform
UI that isn't using system chrome/dialogues. Don't get in the user's way, and
let them develop muscle memory specific for the game.

~~~
mmphosis
Can you imagine a first person shooter game with dialog boxes popping up all
the time? Shoot now? Shoot-Don't Shoot. Light switches with a dialog box?
Light switch: on-off slider. Cancel-Reset-Apply Web sites that throw up
overlays over the content to ask some inane question? oh, wait.

------
kurtisc
This explains why they're swapped for the print dialog in Chrome between Linux
and Windows.

Often I select a word intending to search it, hit print instead and then hit
the wrong button trying to cancel it. This is why I have pieces of paper with
one word printed on them.

------
pests
I love this sentence buried at the end I don't think anyone has commented on
yet:

"We plan that almost every widget in this GUI (and the of the game) will have
tooltips briefly explaining what everything does, since for example not even
us developers know what Enemy base Richness actually does any more."

Such an honest statement with absolutely no followup. Love it.

------
thanatos_dem
I ran into this during in my old days of UI development using Java Swing. I
eventually came across MiG Layout
([http://www.migcalendar.com/miglayout/cheatsheet.html](http://www.migcalendar.com/miglayout/cheatsheet.html))
which had a steep learning curve, but was extremely powerful.

In particular, you could give components a tag attribute, and it'd do
platform-specific component reordering based on the tags. It was pretty sweet!

------
xg15
> _The solution we are now experimenting it sounds like a bad idea: "Make it
> so much different and Factorio specific, that the way it is done in your
> specific system will not interfere with your muscle memory"._

I actually kind of like the solution they found, but I'd still argue that this
way of reasoning really _is_ a bad idea.

If you remember your Kant - always act so that everyone could do what you do -
this would be horrible.

UI is all about consistecy and while it's nice they don't want to interfere
with the consistency of the rest of the UI, if every designer would use that
excuse, we wouldn't have any consistency at all.

------
robbrown451
I vote for Ok on the left (even though I have used macs for years) because Ok
is the "normal," typical action. "Cancel" is only done when you've basically
made a mistake by opening the dialog box. Since we read from left to right,
someone working quickly will only have to read the first one to do the action
without breaking their flow. If you are hitting cancel, your flow was already
broken when you opened the dialog box.

~~~
qwerty456127
I vote for Ok on the left because Cancel should be easiest to find without
looking and thinking. When I decide I don't want to change anything this
window is for I just click the lower-rightmost button unconsciously, faster
than I can read it, e.g. the way you slap yourself when you feel like a
mosquito might be there biting you. So, when the button there is not Cancel
this can be destructive.

------
michaelcampbell
I always preferred, "Do <the thing>" or "Don't do <the thing>". Be explicit in
what the buttons mean.

~~~
dylan-m
Yep. That's one of the reasons I have always really appreciated GNOME: they're
steadfast about buttons that do what they say, and it makes everything so much
nicer to deal with for me. Part of this is GTK does a good job avoiding
situations where stock OK / Cancel buttons are an easy way out. I think a
reason for the vast number of them in other places is developers are lazy gits
and lots of UI frameworks make it effortless (like, a single function that
blocks your thread effortless) to create really lame question dialogs with
ready-made generic labels.

~~~
simion314
GTK gets bad points for me because it forces me to use their file choosers, no
choice to avoid that then attempt some runtime patching the applications.11

------
lamontcg
You want to know bad design of a cancel button?

The lyft app when you want to cancel a ride has a "cancel" button that cancels
the ride instead of cancelling the cancel.

Accidentally cancelled a ride one time in the middle of it when I fat fingered
the first button and then stabbed at "cancel" thinking it meant "abort" and
not "ok, continue"...

~~~
zaksoup
Genuinely curious, what's a better way of doing this particular flow:

user taps "cancel" dialogue asks "Are you sure" and presents options: "cancel"
and... "cancel"??

What should the options/dialogue be?

~~~
Too
One of the options should be "Continue your ride" or "Return to your ride".
The second one should be "Cancel ride".

Or you use the default back button of your OS (top left in ios/windows or
hardkey on android) and only provide the "cancel ride" button to move forward.

------
sbr464
What if it wasn’t a per org choice, but defined by a governing body? Similar
to how countries implement which side of the road to drive on etc. Then each
new startup/product team won’t have to have the existential crisis invoking,
bikeshedding conversations about this very topic.

------
dmoy
Well damn. Read an article about factorio at 5:30pm on Friday, there goes my
whole weekend.

------
SeanLuke
In the very first example screenshot on that page, it would appear that the
user is presented with _three_ different ways to cancel the action: clicking
NO, clicking CANCEL, or clicking the close box. I would presume they
effectively do the same thing? As far as I know this is typical of a Windows
dialog box. I'm a Mac user: can someone tell me how this could possibly be
considered good UI?

BTW, Cancel-OK dates from _both_ of OS X's parents: MacOS and NeXTSTEP.

------
danschumann
Going to the right seems natural to progress, but is that because English is
left to right? If a language goes up to down, do their dialog boxes proceed
downward?

~~~
klodolph
Apple Human Interface Guidelines do indeed recommend the "OK" type buttons on
the left for right-to-left texts (and put the menus on your mobile apps on the
right instead of the left, etc). Computers do not generally use vertical text
for localization, for example, Chinese and Japanese are left-to-right as far
as the computer is concerned. (This doesn't apply _in all cases_ just to the
way UIs are localized. You can still make text vertical, for example, see
[https://www.w3.org/TR/css-writing-modes-3/](https://www.w3.org/TR/css-
writing-modes-3/))

------
circlingthesun
If you assume that people tend to consider all options before making a choice,
putting the primary action on the right makes sense. If you put the primary
action on the left, a user will see it first, but then read on to look at the
other options. Once all options have been considered, the user has to go back
to click the first option. If the primary action is last, the user can
immediately click it once all options have been seen.

------
maxxxxx
We have a review software that has buttons "Wait"-"Approve" and then
"Sign"-"decline". So on one screen the positive button is on the right but on
the other it's on the left. I have declined tons of reviews just by clicking
on the right button reflexively.

~~~
jessaustin
Is this intentional? Do they want you to be really sure?

~~~
maxxxxx
I doubt it. There is no "are you sure?" on the decline button. So typically I
decline something and wonder why two days later someone complains why have
declined his review.

------
gsich
As long as it is consistent with the OS.

Linux programs are especially bad in this. You never know what you'll get.

------
jasonjei
The way I see this debate is very simple: some people in parts of the world
drive on the left side of the road, and some people in other parts of the
world drive on the right. I might argue there is only one “right” way to
drive, but both are valid approaches.

------
Edmond
If it is matter of vote, I'd vote for Ok --> Cancel most of the time.

My justification for this is to avoid accidentally going for Ok when what you
want is Cancel...but this happens to be biased against left-handed people!

~~~
nailer
OK then cancel makes sense because 'OK" is the first, and therefore default
option

Cancel then OK makes sense as 'OK' is then in the bottom right corner, same
place as the 'next' in a wizard GUI. But call it 'Continue' or something,
whatever you're saying OK to.

~~~
Phrodo_00
I think that a lot of the thinking behind putting the action to the right is
to have Cancel be sort of the default option (the keyboard'd still default to
the action) as a way of avoiding user automatically doing actions they regret
(and with the presumption that cancelling won't make them lose any work).

Of course, once they get used to that, it still becomes automatic

------
keyle
As a UX designer, I think consistency is key. And if your user base is mostly
on Windows, go the windows way. If they're mostly on OSX, go the Apple way...

------
tjoff
The most important aspect of this is keeping it consistent.

Speaking of which... Android messed this up royally where they just changed
their minds and changed all dialogs to the other way with (if I remember
correctly, which I probably am not) Android 4.0 Ice Cream Sandwich. Drove me
insane trying to relearn muscle memory to ok/cancel.

Maybe they have documented their reasons for it? (couldn't find it)

------
scarejunba
I only know one thing. When I use Venmo to charge my friends I often end up
paying them instead. Right side primary. Right hand dominant.

------
jaxondu
I'm not a UX person but I notice bank ATMs places OK (Action) button on the
right, and Cancel on the left. Recently I encounter an ATM by a new bank which
places the button the other way, and feel weird. So my guess is there is no
right way or wrong way. Just the way we're used to.

------
RoadieRoller
One of the masterpieces I've read on developer created UI.
[https://blog.codinghorror.com/this-is-what-happens-when-
you-...](https://blog.codinghorror.com/this-is-what-happens-when-you-let-
developers-create-ui/)

------
fnordprefect
There was a lot of good work done by Apple in the days of classic Mac OS - see
eg pages 103, 196-7, 201 and 206-7 from the Macintosh Human Interface
Guidelines, available eg at
[http://interface.free.fr/Archives/Apple_HIGuidelines.pdf](http://interface.free.fr/Archives/Apple_HIGuidelines.pdf)

Some of the reasons behind the suggestions (which are clearer when you view
the associated pictures in the pdf):

"The Western reader’s eye tends to move from the upper-left corner of the
dialog box to the lower right. Put the initial impression that you want to
convey in the upper-left area (like the alert icon), and place the buttons
that a user clicks in the lower right. Following this guideline makes it
easier for users to identify what’s important in a dialog box."

"The button names in the save changes alert box correlate to the action users
perform by pressing the button. The buttons read Save, Don’t Save, and Cancel.
Using these verbs reinforces the identity of each possible action to the user.
In other words, the Don’t Save label provides much more context for the user
than the word No does."

"In order to prevent accidental clicks of the wrong button, you should always
keep safe buttons apart from buttons that could cause data loss. Standardizing
the location of buttons in a safe configuration provides an additional
safeguard for the user. Place the Save button in the lower-right corner with
the Cancel button to its left. Place the Don’t Save button left-aligned with
the message text. Make the Save button the default button, which means that it
should be linked to the Return or Enter key. This way, the user is less likely
to accidentally click the Don’t Save button or activate it with a keystroke
and cause irretrievable loss of data."

"Whenever possible, name a button with a verb that describes the action that
it performs. Button names should be limited to one word whenever possible. You
should never use more than three words for a button name."

One good justification for the Cancel->OK order is that it means the default
button (usually the OK button, but also Save, Print etc) is always in the same
position in the dialog -- far bottom right -- regardless of how many other
buttons there are, and how wide they are. This gives consistency / familiarity
/ muscle memory.

It also lets you place "data loss" buttons well away, in the far bottom left,
as "an additional safeguard for the user". On classic Mac OS, you always knew
pressing a button towards the lower left corner, and set away from the other
buttons, could spell trouble.

The problem with the Windows way of doing things is that the default button
moves depending on the width and number of other buttons, and there is no
"safe button place" and "unsafe button place".

------
Too
How about top to bottom? Like the windows copy file dialog where there is no
obvious correct way forward or back:
[http://i.stack.imgur.com/GeQG7.png](http://i.stack.imgur.com/GeQG7.png)

~~~
megablast
Cancel is pretty obvious to go back. I don't find this good at all, you really
have to read what is going on. A simple replace/duplicate/skip would be better
for me.

------
emodendroket
Like everything else, whatever benefits one or the other has is far outweighed
by consistency with the host environment, if you can do it. But of course a
game on multiple platforms has constraints that make this difficult.

------
ernesth
So why do Samsung android phones put the "back button" on the right contrary
to the other android devices?

In latin and germanic languages, left means back, cancel, undo, bad whereas
right means continue, progress, right!

~~~
cesarb
Because early Android devices had the back button on the right. See for
instance the first Android device
([https://en.wikipedia.org/wiki/HTC_Dream](https://en.wikipedia.org/wiki/HTC_Dream)):
the button order was according to Wikipedia "Call", "Home", "Menu", "Back",
"End Call".

The standard Android button placement later changed to have the back button on
the left, but Samsung kept the old order, probably so that users who upgrade
their phone within the Samsung Galaxy series don't have to relearn their
muscle memory.

------
cylim
I think, for mobile design, it is relatively more straightforward to press the
button on the right (because most people are right-handed), that's why
`Cancel-Ok` design is getting more popular.

------
badsectoracula
> But little I knew, that this is actually specific to windows, and on Linux
> or macOS, the order is reversed

Actually on Linux it depends on the toolkit and/or environment you are using
and in this case it seems that GNOME/GTK is the odd one out. After doing some
search, it looks like that every other toolkit and environment uses OK ->
Cancel:

[http://ocsmag.com/wp-content/uploads/2015/02/plasma-
krunner-...](http://ocsmag.com/wp-content/uploads/2015/02/plasma-krunner-
modules.png) (KDE)

[https://docs.kde.org/trunk5/en/kdeaccessibility/kmouth/kmout...](https://docs.kde.org/trunk5/en/kdeaccessibility/kmouth/kmouthctts.png)
(KDE)

[https://api.kde.org/4.x-api/kdelibs-
apidocs/kdeui/html/kdial...](https://api.kde.org/4.x-api/kdelibs-
apidocs/kdeui/html/kdialog.png) (KDE)

[https://www.sao.ru/hq/sts/linux/book/xbook_marshall/prompt.g...](https://www.sao.ru/hq/sts/linux/book/xbook_marshall/prompt.gif)
(Motif)

[https://www.sao.ru/hq/sts/linux/book/xbook_marshall/dialog1....](https://www.sao.ru/hq/sts/linux/book/xbook_marshall/dialog1.gif)
(Motif)

[http://northstar-
www.dartmouth.edu/doc/idl/html_6.2/images/m...](http://northstar-
www.dartmouth.edu/doc/idl/html_6.2/images/macro02.gif) (Motif)

[http://www.antillia.com/oz++/images/IconBar.png](http://www.antillia.com/oz++/images/IconBar.png)
(Motif)

[https://tkdocs.com/images/idleprefs_l.png](https://tkdocs.com/images/idleprefs_l.png)
(Tk)

[http://zetcode.com/img/gui/tkinter/colorchooser.png](http://zetcode.com/img/gui/tkinter/colorchooser.png)
(Tk)

[http://www.fltk.org/doc-2.0/html/filechooser.gif](http://www.fltk.org/doc-2.0/html/filechooser.gif)
(Fltk)

Even on TUIs/Console the order tends to be OK -> Cancel:

[http://linuxcommand.org/images/adventure_dialog-
radiolist.pn...](http://linuxcommand.org/images/adventure_dialog-
radiolist.png) (dialog)

[https://i.imgur.com/ruW7AQE.png](https://i.imgur.com/ruW7AQE.png) (Free
Vision)

[https://raw.githubusercontent.com/pfalcon/picotui/master/pic...](https://raw.githubusercontent.com/pfalcon/picotui/master/picotui.png)
(picotui)

Also FWIW in my own programs i am always going OK -> Cancel since it feels
more natural.

~~~
eliaspro
IIRC KDE (or was it Gnome) changes the order depending on whether it's a RTL
or LTR locale.

~~~
badsectoracula
Apparenly Windows does that too [1] (or did at some point, i can't find any
recent shot that showed a dialog box). It actually looks like it flips the
entire window horizontally in RTL :-P.

[1]
[http://www.geocities.ws/mowasel/tech_zone/images/dialog5.jpg](http://www.geocities.ws/mowasel/tech_zone/images/dialog5.jpg)

------
kerng
Simple for me. OK on right, because it's like go forward. Left is like go
backward. Everything else is just confusing to me. Your mileage might vary.

------
Pxtl
I like OK Cancel because it implies that tab-enter on the last entry field is
submit without breaking expected left-right right flow of tab index.

------
dogweather
I'd downvote this for the title if I could.

Better:

> Ok-Cancel versus Cancel-Ok: [added value of article]

E.g.: "A/B tested", or "a historical review", etc.

~~~
zaksoup
I thought the HM guidelines required titles be as true to the article as
possible. I’ll keep your feedback in mind next time I submit a link! Thanks.

~~~
DoreenMichele
You are supposed to use the original title. You aren't supposed to
editorialize.

There are some exceptions to the rule of using the original title. They are
listed in the guidelines:

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
zaksoup
That's that I thought! Thanks for the comment.

------
edpichler
Just to remind us, millions of people live in societies that reading is right
to left [https://en.wikipedia.org/wiki/Right-to-
left](https://en.wikipedia.org/wiki/Right-to-left)

I think both ways are correct, and independent of what we chose, the most
important is the application keep coherence and cohesion with itself and (when
it is possible) with it's enviroment.

------
towndrunk
Does it bother anyone else when the "k" is not capitalized in "Ok" on a
button?

~~~
mmphosis
The cache size is currently 0k. Increase the cache size?

Ok-0k

~~~
mmphosis
Do you wish to Cancel?

Cancel-Cancel

------
seaghost
You could think of it as previous and next. They cannot be swapped.

~~~
dymk
For Mac/Linux, sure. But that's not what Windows users are used to, and
therefore don't model as "previous/next".

