> 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.
The "Factorio specific" way looks the same as the Mac OS way (aka the correct way, since the Mac was built on UX research ;-) ). Was the author just hesitant to admit that his/Windows idea was wrong?
The other advice on the linked NN post is sensible too:
"If you're designing a desktop application for one of these two personal computer platforms, your choice is easy: Do what the platform owner tells you to do."
Not conforming to your environment's native design language is trouble. A miniscule part of the audience are playing the game on both kinds of platforms; the vat majority toggle between Factorio and their home OS.
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.
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.
b : to subject to a condition, treatment, or operation * the metal was submitted to analysis
2 : to present or propose to another for review, consideration, or decision; also : to deliver formally * submitted my resignation
3 : to put forward as an opinion or contention * we submit that the charge is not proved
It (the "Submit" button) is "present[ing]" (or "deliver[ing]") the form data field contents to the server. And in fact, myself, until I read your comment, never even considered the word in the context of the "yield" definition due to how it operates.
"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):
> In a move guaranteed to annoy many people, Microsoft has "jumped the shark" on encouraging users to upgrade to Windows 10. Microsoft has faced criticism for changing the pop-up box encouraging Windows users to upgrade to Windows 10. Clicking the red cross on the right hand corner of the pop-up box now activates the upgrade instead of closing the box.
This is the edgiest of edge cases. Intuitively I would assume that such a dialogue box may be a UX smell and there could be better ways to perform a two stage confirmation.
Or you can just bend the UX rules for this one instance.
Or you can consider whether cancel is the best verb anyway; what about “end” or “stop” or “abort”?
The problem is in the verbiage of the question. A person writing a dialog should consider "Cancel" something like a reserved word in a programming language.
I'm currently in the process of writing together some basic UI guidelines at work, and one of the special cases was exactly this: If the dialog asks for confirmation to cancel a process, it must ask, "cancel this process", and the buttons must be labeled "yes" and "no", never "cancel".
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.
> Actually "mirror the action verb" surprises/confuses me
To a certain extent, I would think this is the point of using this approach (at least for a "delete" action). I'd prefer the user to stop and think, "wait, what is this?" instead of just blindly clicking through.
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.
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.
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.
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.
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.
I agree. When I initiate an action like "delete" and a dialog pops up, my mind is already assuming it's asking the question "Are you sure?" regardless of what the text says, and my eyes are just scanning for a "Yes" or "No". I would give preference to it being on the left (probably because "yes or no" is so ingrained... when's the last time you heard someone say "Answer me, it's a simple no or yes answer!"), but, realistically, if the buttons are close together I'm reading them both at the same time while my eyes are still moving toward them. As in many reading contexts, my brain knows the shape and length of the words I'm expecting so I'm mostly on autopilot until the very last moment.
If the action is to move forward with something or not, I think I prefer the "next"-type button to be on the right, and "cancel" or "back" on the left, probably far left.
But, my thinking does violate the "pick one and be consistent" suggestion. So... I dunno :)
When you initiate action like delete, you might be thinking “yes/no” in the moment, but you couldn’t possibly argue that “cancel/delete” is less intuitive or breaks flow.
And we don’t always react to confirmations instantly. What if you’re distracted away, or you suddenly second guess your decision and perform some auxiliary research? Or what if you have more than one dialogue box on the screen at a time? From a UX standpoint, it is far safer to repeat the verb rather than use a generic.
To be frank, the only reason why I could imagine using generics is laziness.
A problem with Yes/No (and OK/Cancel, etc.) is that one program will ask
Unsaved changes will be lost. Save your changes first?
and another program will ask
Unsaved changes will be lost. Are you sure?
Or within a single program, "Yes" will be the safe option everywhere except one place where it's the dangerous option because nobody thought about that.
If the user is exposed to one convention 90% of the time, the other one will always cause some confusion and feel sloppy.
Delete xyz.jpg?
--------------------------
The file 'xyz.jpg' will be
permanently deleted.
--------------------------
[ Delete xyz.jpg ]
[ Keep xyz.jpg ]
Action buttons sometimes need to be single verbs for the sake of brevity. A verb-noun pair is much more legible than a standalone verb. Self-explanatory buttons are usually preferable to buttons that depend on explanatory text.
One can verb nouns in lots of languages, English just happens to have "0-derivation" verbing of nouns ("photoshopped the picture", "googled Dan"). As well as "0-derivation" nouning of verbs ('did the user submit an "ok" or a "cancel"?').
Proceed seems to be the wrong verb here, as that dialog looks like it appeared after clicking a cancel button, and if I don't want to cancel I "return" to the previous screen where my data still is and don't "proceed" to somewhere.
Those verbs need nouns. Cancel what? Proceed with what? Most of the time, it's possible to make buttons self-explanatory if you give some thought to the choice architecture.
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) 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!
But it's funny because it's true! Factorio is INCREDIBLY addictive, because it stimulates that excellent feeling you get from successfully writing and refactoring beautiful code.
yes, regret it you will. I've had it for a while and from time to time I see someone play it online and go "oh, I should go play that again".... just recently....
7pm: I think to myself, let's do some work on my side project... but first, lets play a little factorio
It's a joke, but like all the best jokes it's one with a large grain of truth and exactly why I've held off buying Factorio for now (Frostpunk as well).
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.
I usually agree, but while it certainly feels like programming it does so in an entirely theoretical environment where both concurrency and parallelism is nearly infinite. I think that makes it feel different enough.
Sometime I think a game is too much like work, and it reflects poorly on the game. Too much grind, tedious...
Factorio for me is too much like work, except I think it's a fine game, I just already often spend my day making systems to put things on queues and take them off queues, trying to keep the queues from getting full or empty...
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.
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.
It's different enough from actual programming that your subconscious can keep working on your real programming while you play. Be warned however, that your subconscious can keep working on your factory while you work...
I was surprised at the minimum requirements. I don't know if I'm not up to date with current games, but from the style of it I thought it would be much lighter.
I haven't looked at them, but anything slightly modern should do. My laptop (5 years old), the desktops in school (2-3 years old), my girlfriend's laptop (3-4 years old), my cousin's laptop (another girl with a not-so-beefy laptop), and my brother's laptop all run it fine... Most of those don't even have dedicated GPU.
Sure, once you go megabase scale, after a few hundred hours of playing, most hardware will lag a little. But at that point there are millions of objects the game has to track every loop, there isn't terribly much that can be done about it. The game doesn't aggregate like OpenTTD, where the number of passengers at a train stop is just a number. Because of the way it works, every piece of iron ore in a train station in Factorio is a separate object existing somewhere. (Though they do some tricks to abstract that a bit as well, see their belt compression blog posts.)
Just to echo one of the points in here: the blog is full of really great details on all this, and how they've changed things, and why. One of the best dev blogs I've ever run across.
The facilities that you create in the game can be quite large and complex. These facilities can be processing and tracking maybe tens of thousands of different individual items. There’s a lot of stimulation workload when you reach large scale.
Unlike in a lot of games where the computational complexity is all graphics-oriented and done in the GPU, these computations are largely all CPU.
A typical game will simulate tens of thousands of entities at once, and it all needs to be updated. You can't cull by LOS because the simulation is running everywhere. There's a lot of what amounts to collision checking, where robot arms are looking for items to pick up or space to drop them off.
It's still quite performant. Some of the larger factories people have built are truly stunning in scale, yet can run at 30+ updates a second. People can host games with hundreds of players with relative ease.
At the beginning of the game, even quite modest computers will have no trouble with it, but that's not a reflection of what the game is about. Big factories are much of the point.
It is actually 30 USD now, but I still think it is well worth it. (I've definitely derived 30 USD of entertainment from it!) I've bought it for myself, and gifted it to three other people. Very addicting game for programmers.
The blog is quite good too, and the interactions I've seen with the developers have been excellent. There's a reddit community too: https://www.reddit.com/r/factorio
There's an active modding community as well, and several of the mods are fairly extensive; I'd recommend beating the vanilla game first, though.
For anyone on the fence about buying the game, there is a free demo[1].
Factorio was heavily inspired by some of the "industrial" Minecraft mods (IndustrialCraft, BuildCraft, etc). IIRC, one of the first public prototypes of the game was posted on a Minecraft forum.
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!
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.
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
I would only color destructive actions red (and "positive" actions green). People tend to interpret red buttons as if they'll delete something, but "cancel" should usually be the option that doesn't change anything.
For example, if you have a dialog that lets you delete something or cancel, the "delete" button should be the red one (although delete/undo is a much better flow than delete/cancel: https://alistapart.com/article/neveruseawarning)
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.
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.
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.
> 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.
I think this is the right answer. Personally and anecdotally, I doubt it makes a noticeable difference which way they are, as long as they are that way everywhere. I will soon learn that "confirm/apply/proceed" is one way, and "back/cancel/revert" is the other way, whichever way those tend to be. Just make sure you don't flip on me.
Yes, definitely agree. I feel the latest UI for iPhone alarms and the timer are a good example of how inconsistency in button placement can be confusing.
When a timer finishes, you get a large button at the top for Stop, and a smaller one at the bottom for Repeat. When an alarm goes off, the Stop button is the small one at the bottom, and the larger top button says Snooze. Very often I find myself repeating a timer instead of stopping it.
That happens to me too, and I find it equally annoying, but I think it is a deliberate design choice. As I understand it they are trying to make it hard to accidentally turn off the alarm and go back to sleep, which would be a critical failure if you missed an interview or were late for work. Presumably irritation at the difficulty of switching it off is seen as the lesser of two evils
I find myself hitting stop instead of snooze, which may turn into a disaster some day. Simply touching your phone without care may stop the alarm.
iPhone alarm control became so wrong that I stopped using the screen and snooze only via top physical button. I’m not sure, but feels like it wasn’t like that before some idiot decided to change the way alarm works for sleepy subconsciously-trained users. Curious how many $M net cost was put into this “design”.
(Googled it: there was no stop button in ios 5, only slide-to-stop, which you cannot do accidentally)
Agreed, however I think there's something crucial missing in there: Also try to be consistent with the platform you're developing for.
Like GP said:
> [...] 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 [...]
Your users most likely will have been conditioned, too. So, don't force them to adopt a different button layout just because "you decided otherwise". If you're developing for multiple platform, it might well be worth your time to ajust those options depending on the platform the application is running on (just like it's almost always better to use a native save/load dialog for files).
And, if you're arriving at that point, you might even consider including a configuration option for those poor souls who have to use the application on another platform at work than they do privately.
> 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.
Not only that, but make the "OK" choice standout with a different color. If the "default" option is brighter than the rest, your eyes will most likely gravitate towards it first, regardless of the order of the buttons.
Additionally, if the OK option is something major and irreversible or destructive, make that different color be red, and change the OK to be what the operation is (Delete, Erase, etc.)
Those Human Interface Guidelines are incredible. There is also an Apple Style Guide that’s very awesome as well. For example, “don’t use ‘please’ as in “Please click yes to continue.” Instead, simply “click yes to continue.” I forget the rationale but it was pretty sound reasoning if I remember correctly.
Speaking of banks with terrible websites, my credit union's login page features a checkbox for "Forgot my password", which is not only confusing in and of itself (" I need to enter my password to reset it?") but also is exactly where you'd expect the "Remember me?" checkbox to appear, meaning that any instinctual attempt for me to tell the site to remember who I am will instead result in me resetting my password.
I'm entirely convinced that banking website design guidelines are driven entirely by a seething hatred for the end-user.
They paid someone a lot of money to design their UI, so they better do something different from the rest of the world, else they would have wasted money.
> I'm entirely convinced that banking website design guidelines are driven entirely by a seething hatred for the end-user.
I've thought about this and (in all seriousness) I think the reason is that the tech banking sector must be plagued with ancient programmers that don't give a damn about UI and design.
But why? Mouse pointer tends to be at a random position relative to a dialog window. According to GOMS, there should be no difference, unless one of the buttons touches screen border or is significantly closer.
Even in film the convention is that if you're character is going back, standing in the way of another character moving the plot forward, or just feeling weak or uncertain, they should face the left. When was the last platformer you saw where you moved left to progress? The right hand side conventionally portrays certainty, strength, and progress in all manner of western arts.
Your post plus the context of Factorio brings about an interesting observation that in all of my Factorio maps, expansion/exploration happens rightwards and upwards unless constrained by geography.
Now that you mention it I have a similar observation. Though I tend to build downward rather than upwards when laying out columns of factories coming over a central bus.
Also when constrained by geography I subconsciously have been seeking out new areas with enough space to resume building left to right like a printer executing a carriage return rather than zig zagging backwards (which perhaps could be more efficient).
Since I’ve noticed that factorio mimics a lot of patterns from the real world I wonder if this prevalent in some other areas eg integrated circuit or circuit board layouts.
> Even in film the convention is that if you're character is going back, standing in the way of another character moving the plot forward, or just feeling weak or uncertain, they should face the left.
Related to your comment, even if unrelated to the theme as a whole: “Snowpiercer - Left or Right”[1]. A video essay by Tony Zhou and Taylor Ramos. Unfortunately they’ve stopped that series[2]; it was easily one of my favourite things on the internet. Off the top of my head I’ll recommend “Jackie Chan - How to Do Action Comedy”[3], “Edgar Wright - How to Do Visual Comedy”[4], and “Memories of Murder (2003) - Ensemble Staging”[5].
Since you asked... About half of the first Castlevania is right-to-left. There are plenty of cues as to where to go, so you never really notice it.
On the other hand -- it's set in an evil castle, with dark muddy colors and a minor-key soundtrack. So maybe the right-to-left motion is intended to make the player feel uncomfortable.
Most of the 2D Castlevania series, really. Later releases like SoTN had the player go back and forth multiple times through certain levels to fully progress, and even had a version of the castle flipped upside down which made the player think on their feet (no pun intended).
Geometry Dash, still probably my favorite game on the iPad, switches between left-to-right and right-to-left suddenly in the middle of levels and it's messing with my brain.
> 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.
What are your thoughts on how smartphones might impact this left vs. right debate? The button on the right is accessible without using just one hand (tapping with thumb while holding in palm), but I need two hands to tap the button on the left.
But I'm left-handed. Do right-handed people hold their smartphone in their left hand? It just occurred to me that my minority handedness might be why I've always found large smartphones hard to use.
I don't know if handedness does has much influence to such clumsy devices like smartphones. It's not comparable to writing text by hand, where much greater precision is required.
In mobile design, I generally stay with the same convention of placing positive actions on the right. The "dominant hand" argument isn't relevant, since your thumb usually rests on the left side of the screen if you're right-handed, but the "forward motion" rationale still makes sense.
It will be interesting to see what conventions from Windows-Icons-Menus-Pointer (WIMP) interfaces still exist on mobile in ten years, when desktop UIs are mostly history.
We still type on QWERTY keyboards, even though the original rationale is long gone; musicians still make albums about an hour long even though they don't have to fit on two sides of a vinyl record anymore; we still have 60 minutes in an hour even though the ancient Babylonians' base 60 counting system has been gone for millennia.
I wonder how many more generations will continue to debate whether "cancel" should go on the left or the right?
I'm right-handed, but for decades have used the phone in my left hand -- I found this to be useful at an early job that often required taking notes whilst on the phone, so I optimised behaviour for that and the habit stuck.
When early cellphones came along I had no trouble using my left hand only when most "right-ies" I know used them with the right hand. Since smartphones became popular I still phone with my left hand primarily, though I have become more ambidextrous with it, and I've noticed that others seem to switch hands more too.
> "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.
I look at it using a more logically safe approach where the first option should be cancel/back/safe_option to force people to think before clicking through.
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.
The same left-bias 'advice' is given to amateur photographers, which results in a wall full of what a friend calls 'camera club copycat' photos. Until your eye alights on one that doesn't follow the guidelines and stands out as a result.
I'd follow the reading-direction paradigm for something like a UI or arranging books on a shelf, but not for art.
> 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).
Back in 2010, a Youtuber named Derek Lieu created a supercut called "Every Anime Opening Ever Made" [0]. One of the notes:
> Interesting thing I learned, if a character is running it's overwhelmingly to the left of the screen.
(Watching the video, "running" may as well also include "standing" and "flying")
Characters moving is a bit different than a diorama, but there may be something to it. I think I remember something similar someone else had found about western animation, that it's biased towards having characters move to the right rather than the left.
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.
Back in the 80's or 90's, I used a popular editor (can't remember the name, but it might have been by Borland), that randomised the 'Yes/No/Cancel' buttons if you tried to quit without saving.
Whilst I initially thought it was cool, it quickly wore me out. Often times, if I was in the 'flow' of editing, that tiny fraction of time that it took me to stop and have to actually read the screen (instead of habitually clicking on a position without even reading) was enough to interrupt my thought processes and impact my productivity.
I think it would be like randomly rearranging the clutch/brake/throttle pedals on a manual car every day. Sometimes you just want your tools to stay out of the way and not interrupt you when you are busy. It is far better to have your feet (oh, ok - mouse cursor) fall to the right places without having to think too much, especially if your mind is busy on more important stuff happening.
Is that packaging style the same for all English-speaking countries? Standing on the side of the road and facing traffic, you'd expect all of the near vehicles to be facing right in North America, so perhaps that carried, consciously or otherwise, into packaging decisions.
I was in a toy shop recently and it's actually about 70-75% right facing, so not all. I don't think there's a pattern based in some underlying reasons - though it is fun to fantasize about those possible reasons.
Just a quick note on Right-to-Left countries, IIRC Nintendo said that they tested both R-L and L-R for Mario games and found and found R-L more natural in Japan
feels like this is something that is resolvable with a simple A/B test? collect enough data and get some answers. I will be shocked if more people end up clicking on OK when it's on the right than when it's on the left.
Another thing to note in the Factorio mockups is the use of a guideline that I originally picked up from the macOS HIG[1]: use descriptive verbs rather than a generic confirmation.
When it comes to OK/Cancel for a non-recoverable event (like delete), it's ALWAYS been the case that the dialogue should NOT appear in the first place.
Instead, the UI should be seen to do the operation, but then delay its execution while showing an "undo" for a few seconds.
The reason for this is that 99.9% of people know what they're doing. So don't bother them for the sake of the 0.1% who make a mistake.
But more importantly - for each dialogue (of whatever kind) you have in an application, the chances of the user reading it declines by the square of the number of dialogues they encounter in a given session to the point where they will never be read, ever.
Not if the alias is in .bashrc / .zshrc and they execute the shell script in the normal way. If they source the script, sure. But no one runs scripts that way, for this exact reason.
I think this depends on the actual semantics of the delete. If the operation is truly non-recoverable, and you simply lie about doing it and do it after a delay, there is a chance you will be caught in that lie when your process is cancelled or failed for whatever reason.
That is a worse user experience by far - you should never tell someone something has been done unless you are sure it has been done permanently.
Maybe for power users. Time based UI actions are not accessible, though. Novice users, elderly, those with lowered motor functions, etc will struggle with time-based interactions.
In your example, you could use a dialog during the first delete with a toggle option in the delete confirmation dialogue of "don't show this next time."
The issue is that novice, elderly, power or otherwise, if you have dialogues popping up all the time asking you if you're sure, and 99% of the time you ARE sure, then pretty soon you will habituate to just hitting OK whatever until the one time you DON'T mean OK, at which point you have an undo.
This isn't controversial, or just my opinion, it's observed, researched HCI stuff (mainly in the context of aircraft cockpit design but also on desktop software and the web).
Interesting. I dropped Android a year or so back but can't remember bumping into an app doing it like that. Definitely encountered a few "are you sure?" style dialogues though.
The only one that comes to mind is the GMail app. When you swipe to archive an email, it gives you an undo button. I have to say I don't particularly like that UI though. If I accidentally swipe, then I only have a few seconds to undo it. I'd prefer a screen that showed me actions I've performed in the past, and let me undo them. That way I wouldn't have to worry about the undo popup disappearing too quickly.
The UI element typically used for this is the "Snackbar", so if you search for "Android Snackbar", you should find some examples.
But yeah, I definitely also see a lot more confirm-dialogs still.
Seems to be a classic case of such a UI pattern being great and hyper modern and marketable in 99% of cases. But if in 1% of cases, the user accidentally deletes a file that they didn't want to delete, then you lose that user in that exact moment.
That is, if you are not a preinstalled app.
If instead you are Google, then users are generally not aware of alternatives and cannot switch away from your app, if this happens to them. They just live with your UI eating their files.
Not to mention that it was quite clearly their fault for not finding the Undo-button quick enough. Which is also generally an opinion that users manage to hold, who have not yet progressed to looking at alternatives of programs and comparing different UIs for their merits.
Perfect example of a UX pattern that's simply asking for trouble, or being clever rather than helpful. :)
You can undo if you notice quickly enough, if your dog, child, doorbell or 1,001 other things didn't distract you at the wrong moment and if you didn't get an incoming call in the temporary undo window. No, we won't tell you how long you can undo for, even though times can vary. Don't be old (or even middle-aged needing reading glasses), or slow.
Seems very much against long known recommendations from Nielsen et al for consistency of expectation etc.
A quick skim through search seems to indicate it came with Material Design. I suspect had it generally caught on it my switch to iOS would have come even sooner. :D
That's something entirely different, and very well known. I can't find any reference to providing a delay before you truly perform an action, but allowing undo for that time.
Relevant to delete / undo they talk of the preference for an undo (eg ^Z at any time) to "Are you sure?". No mention of delaying action or availability of undo. Then preference for consistency of action - within app and generally, not deviating from common expectations (eg that a trash can allows restore), and recommendations for visual feedback when latency and delay is involved. None of which fits the original temporary delay/undo.
On the web, it is extremely difficult to have an undo stack, so I'm talking about "undo" as implemented by appearing to do the action (eg delete), but delaying its actual action while giving the user the ability to undo it. If they take no action (or navigate away, etc.) the action is done.
In both of those links I posted, it clearly states well-designed systems have undo.
Indeed. Factorio's use of the arrows to indicate a sense of direction ("back" points backwards on the timeline and "OK/Confirm/Play etc. point forwards, towards progress) makes it instantly clear what will happen after each button press.
I've always looked at interface choices like this: As a non-Chinese reader, if I see a dialog in Chinese and the "Yes/Confirm" and No/Back" buttons are the same size, shape, and color, I will have no clue which does what. However, if the "Yes" option is a darker shade, or has bolder text, or the button shape makes it scream "click me!", I'll feel relatively confident that this is the button I need to press to proceed with whatever I'm trying to do.
> 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.
And then there is the new UI paradigm, seen on many web apps, where "positive response" is replaced with "whatever response would be the best outcome for the company".
I think there is one factor missing: While it might be true that many of us are reading from left to right, our usage of UI is not necessarily defined by the same patterns as reading.
When we start using a UI we certainly read every button before clicking on one, but after a while we just want to find the correct button. And in that case it might be helpful to place the button for the primary action right next to the bottom right corner, as that corner is one of the places we start looking for the button. With the OK-Cancel order, the OK-button would be hidden behind the Cancel-button.
Nevertheless, this factor doesn't change anything about your conclusion. I think your argument is very balanced and I agree with your conclusion about consistency being the most important factor.
The button group at the lower right corner is where we start looking for our button. Inside that button group, which is quickly located, buttons are parsed left to right.
To add to this, if we're doing a task, it's probably safe to assume we're more interested in going on with it, so there's a reason for the affirmative button being at the left of the group (first to be parsed). Also, you typically ask "Yes or no?", not "No or yes?". Just a maybe different perspective from a Windows user.
There is a simpler reason. Apple introduced the GUI (licensed from Xerox) with the Okay button to the right. Microsoft Windows decided to go the other way for legal reasons and in order to look different.
Companies make these 'slightly different' approaches often and probably usually to avoid design patent issues.
Microsoft also put the toolbar with the menu for getting to your programs a the bottom with the 'Start' menu, this really should have been at the top. Apple had their menu at the top so Microsoft did it differently. In those days I found it absurd how you had menus flowing out from the bottom left of the screen. Moving the menu to the top was drag and drop but nobody bothered, therefore having it wasn't that big a deal.
Microsoft had to work with IBM on the original Windows so they got a lot of things right including the universal shortcut keys for menu actions. You were never left requiring a mouse except for in MS Paint.
Surely the file dialog boxes and whatnot were designed to 'not look different' but tied in to this universal hotkey thing they had going, i.e. some sensible rule so you could tab or arrow key away from the 'OK' button?
Not just internally consistent, but externally consistent, at which point making this a matter of compliance.
External consistence isn't subjective. It's as objective to that system as any other fact, and is a matter of understanding, not feeling or choosing or designing.
If you're building an extension to MS Office, make your app comply with MS Office. Same with Adobe Photoshop plugins. And ultimately same with apps/programs for an OS.
If the OS does OK-left, do OK-left.
The UI that does not exist is the UI that is performing the best.
No one "uses" a UI. They just pass it. If you're thinking too hard about it, chances are you'll make your users think about it also. And trying to get noticed will always be at the expense of usability.
And finally, metrics such as consistency, obviousness/coherence, and simplicity are also objectively measurable, as are error rates, A/B tests, and step counts. What is subjective is user feedback and even developer feedback. By tallying what people think of an interface, you've already abandoned the goal of remaining unnoticed, and this is how Frankenstein UIs are built.
I feel there is another aspect to consider. The more committal action should require the more conscious movement to invoke. A great example being exiting an app being at the bottom of the file menu. Or on MacOS classic where they placed the trash can in the lower right of the desktop far from everything else.
OK and cancel don't consider this aspect as much, but IMO OK should require more conscious movement to accomplish. I'd rather accidentally cancel sending an email than accidentally prematurely send one for example.
This implies, as I agree with, that a single-action pop-up or form (which does not progress) should have OK-Cancel, and that a progressive form should be Cancel-OK, as clicking OK progresses things to the "right" (or next "page"), whereas Cancel stops that progression.
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?
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/)
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.
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
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".
> 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:
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.
> 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
I have always used a Mac, and just occasionally Windows: I have never noticed this detail until I read this article. Sure, something always seemed “off” with dialogs in Windows, but I couldn’t pinpoint it. So I don’t think the author never used a Mac, it’s more likely that they never connected the dots either.
I think it’s this very consistency that make using the JetBrains family of IDEs so painless. The power-user keybindings are equivalent across all of their products. The standardization make picking up a new language the hardest part about a new IDE instead of having to learn a new tool AND having to learn a new language.
> 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.
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.
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
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)
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.
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.
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.
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?
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...
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 ;-)
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).
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...
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.
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.
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...
> 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.
> Wow, you have to manually activate such an option? On windows it's default.
I don’t think that’s deserving of “wow”. I don’t think it’s that big of a deal. It’s a clear option that is quite visible and present in the exact preference pane you’d expect. And you don’t need to activate it manually. You can do it via CLI:
I haven’t used Windows in years so I can’t compare, but keyboard support on macOS doesn’t feel like an afterthought to me. Without leaving the same screen where one activates keyboard support for all controls, one can also change and set keyboard shortcuts for every other action including every menu option of every app. And if doing it manually isn’t your thing, you can also define those keyboard shortcuts via CLI. It even works for setting single key (no modifier) shortcuts.
Once a friend of mine with a mac suddenly had a mouse malfunction, can't remember if it was broken or just out of battery but doesn't matter. He was literally stranded, and this is developer who knows how to use a terminal and a keyboard. Everything we were working had to be put on hold, i can't remember the exact scenario but we couldn't even save the document, unlock the machine, get to a terminal or something like. Having keyboard accessibility enabled as default would have saved our ass that day.
There are definitely hotkeys that allow you to do anything via keyboard; your friend just didn't know them. If they had searched, they would have found the help page https://support.apple.com/en-us/HT204434 "Mac accessibility shortcuts". For example, the global hotkey Control-F7 toggles the above-described "All controls" navigation setting, and Control-F2 switches focus to the menu.
I don’t need to optimise the speed. I like that I can.
When you make a mistake that prompts a dialog box, having to move your cursor to undo can feel slightly punishing. Doing it with a single key press makes it feel like part of the process.
285 comments
[ 2.7 ms ] story [ 129 ms ] threadI 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.
The other advice on the linked NN post is sensible too: "If you're designing a desktop application for one of these two personal computer platforms, your choice is easy: Do what the platform owner tells you to do."
Not conforming to your environment's native design language is trouble. A miniscule part of the audience are playing the game on both kinds of platforms; the vat majority toggle between Factorio and their home OS.
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.
https://www.merriam-webster.com/dictionary/submit
1 a : to yield to governance or authority
b : to subject to a condition, treatment, or operation * the metal was submitted to analysis
2 : to present or propose to another for review, consideration, or decision; also : to deliver formally * submitted my resignation
3 : to put forward as an opinion or contention * we submit that the charge is not proved
It (the "Submit" button) is "present[ing]" (or "deliver[ing]") the form data field contents to the server. And in fact, myself, until I read your comment, never even considered the word in the context of the "yield" definition due to how it operates.
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:
You have: 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...
Dialog Boxes: https://msdn.microsoft.com/en-us/library/windows/desktop/dn7...
"Cancel this action?" "Yes" "Cancel"
Seriously?!
https://tech.slashdot.org/story/16/05/24/171215/windows-10-u...
> In a move guaranteed to annoy many people, Microsoft has "jumped the shark" on encouraging users to upgrade to Windows 10. Microsoft has faced criticism for changing the pop-up box encouraging Windows users to upgrade to Windows 10. Clicking the red cross on the right hand corner of the pop-up box now activates the upgrade instead of closing the box.
On reconnecting the power cable we find all files deleted anyway.
On the other hand, I think Yes or No are clearly an answer to "Cancel this action?"
Or you can just bend the UX rules for this one instance.
Or you can consider whether cancel is the best verb anyway; what about “end” or “stop” or “abort”?
To a certain extent, I would think this is the point of using this approach (at least for a "delete" action). I'd prefer the user to stop and think, "wait, what is this?" instead of just blindly clicking through.
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.
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.
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.
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.
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.
If the action is to move forward with something or not, I think I prefer the "next"-type button to be on the right, and "cancel" or "back" on the left, probably far left.
But, my thinking does violate the "pick one and be consistent" suggestion. So... I dunno :)
And we don’t always react to confirmations instantly. What if you’re distracted away, or you suddenly second guess your decision and perform some auxiliary research? Or what if you have more than one dialogue box on the screen at a time? From a UX standpoint, it is far safer to repeat the verb rather than use a generic.
To be frank, the only reason why I could imagine using generics is laziness.
If the user is exposed to one convention 90% of the time, the other one will always cause some confusion and feel sloppy.
My gut feeling is that when written as a verb, it should always be the longer form, ex: "I will okay it, like I okayed the last one."
I believe it's from the same writing-sense that intuits "I have three main points" as superior to "I have 3 main points."
According to who? Why? I've never heard this before and it doesn't sound like a remotely necessary rule.
e.g. Cancel cancelling / proceed to cancel. To me, that always seemed like a place where a simple "Yes/No" would be more appropriate.
Clear as mud, right?
I bought a couple of bags of just two keys. Red panic buttons "Panic", and, "Any" keys.
We replaced the escape key cap with those when we sold new systems.
The "Any" key was a big hit and quite popular with the n00bs back in those AT (286) days.
I think I may still have a few of those around lolz.
Or if you are half way through paying for your cart, the merchant should check you really meant to press cancel.
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!
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".
(Edit: I’m joking. It’s a great game.)
7pm: I think to myself, let's do some work on my side project... but first, lets play a little factorio
3am: FU#! :/
It's a joke, but like all the best jokes it's one with a large grain of truth and exactly why I've held off buying Factorio for now (Frostpunk as well).
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.
Factorio for me is too much like work, except I think it's a fine game, I just already often spend my day making systems to put things on queues and take them off queues, trying to keep the queues from getting full or empty...
Since I get paid hourly for my normal work .... I started wondering, "Wait, why am I not just working right now? Same thing except I get paid......"
It should be called something like "Jenkins: The Game".
I actually had a similar experience with Space Chem. It was fun until I realized I was playing "Procedural Spaghetti Code: The Game."
I wish there was a "Functional Programming: The Game"
Sure, once you go megabase scale, after a few hundred hours of playing, most hardware will lag a little. But at that point there are millions of objects the game has to track every loop, there isn't terribly much that can be done about it. The game doesn't aggregate like OpenTTD, where the number of passengers at a train stop is just a number. Because of the way it works, every piece of iron ore in a train station in Factorio is a separate object existing somewhere. (Though they do some tricks to abstract that a bit as well, see their belt compression blog posts.)
Unlike in a lot of games where the computational complexity is all graphics-oriented and done in the GPU, these computations are largely all CPU.
Modern laptops should generally be fine though.
It's still quite performant. Some of the larger factories people have built are truly stunning in scale, yet can run at 30+ updates a second. People can host games with hundreds of players with relative ease.
At the beginning of the game, even quite modest computers will have no trouble with it, but that's not a reflection of what the game is about. Big factories are much of the point.
I've heard it called Cracktorio.
But yes, I have seen a lot of concepts of programming in the game.
The blog is quite good too, and the interactions I've seen with the developers have been excellent. There's a reddit community too: https://www.reddit.com/r/factorio
There's an active modding community as well, and several of the mods are fairly extensive; I'd recommend beating the vanilla game first, though.
For anyone on the fence about buying the game, there is a free demo[1].
[1]: https://www.factorio.com/download-demo
Worth it though. Probably the best game I've ever played.
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!
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.
Of course, once they get used to that, it still becomes automatic
and never color an “ok” or “go” or any action other than cancel red. not even if your app’s color scheme is red.
and don’t use both red and green.
then just be consistent.
For example, if you have a dialog that lets you delete something or cancel, the "delete" button should be the red one (although delete/undo is a much better flow than delete/cancel: https://alistapart.com/article/neveruseawarning)
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.
I think this is the right answer. Personally and anecdotally, I doubt it makes a noticeable difference which way they are, as long as they are that way everywhere. I will soon learn that "confirm/apply/proceed" is one way, and "back/cancel/revert" is the other way, whichever way those tend to be. Just make sure you don't flip on me.
When a timer finishes, you get a large button at the top for Stop, and a smaller one at the bottom for Repeat. When an alarm goes off, the Stop button is the small one at the bottom, and the larger top button says Snooze. Very often I find myself repeating a timer instead of stopping it.
iPhone alarm control became so wrong that I stopped using the screen and snooze only via top physical button. I’m not sure, but feels like it wasn’t like that before some idiot decided to change the way alarm works for sleepy subconsciously-trained users. Curious how many $M net cost was put into this “design”.
(Googled it: there was no stop button in ios 5, only slide-to-stop, which you cannot do accidentally)
Like GP said:
> [...] 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 [...]
Your users most likely will have been conditioned, too. So, don't force them to adopt a different button layout just because "you decided otherwise". If you're developing for multiple platform, it might well be worth your time to ajust those options depending on the platform the application is running on (just like it's almost always better to use a native save/load dialog for files).
And, if you're arriving at that point, you might even consider including a configuration option for those poor souls who have to use the application on another platform at work than they do privately.
Not only that, but make the "OK" choice standout with a different color. If the "default" option is brighter than the rest, your eyes will most likely gravitate towards it first, regardless of the order of the buttons.
It's a terrible web app.
I'm entirely convinced that banking website design guidelines are driven entirely by a seething hatred for the end-user.
I've thought about this and (in all seriousness) I think the reason is that the tech banking sector must be plagued with ancient programmers that don't give a damn about UI and design.
Also when constrained by geography I subconsciously have been seeking out new areas with enough space to resume building left to right like a printer executing a carriage return rather than zig zagging backwards (which perhaps could be more efficient).
Since I’ve noticed that factorio mimics a lot of patterns from the real world I wonder if this prevalent in some other areas eg integrated circuit or circuit board layouts.
Edit: context
Related to your comment, even if unrelated to the theme as a whole: “Snowpiercer - Left or Right”[1]. A video essay by Tony Zhou and Taylor Ramos. Unfortunately they’ve stopped that series[2]; it was easily one of my favourite things on the internet. Off the top of my head I’ll recommend “Jackie Chan - How to Do Action Comedy”[3], “Edgar Wright - How to Do Visual Comedy”[4], and “Memories of Murder (2003) - Ensemble Staging”[5].
[1]: https://vimeo.com/110329961
[2]: https://vimeo.com/tonyzhou
[3]: https://vimeo.com/113439313
[4]: https://vimeo.com/96558506
[5]: https://vimeo.com/149936243
On the other hand -- it's set in an evil castle, with dark muddy colors and a minor-key soundtrack. So maybe the right-to-left motion is intended to make the player feel uncomfortable.
What are your thoughts on how smartphones might impact this left vs. right debate? The button on the right is accessible without using just one hand (tapping with thumb while holding in palm), but I need two hands to tap the button on the left.
But I'm left-handed. Do right-handed people hold their smartphone in their left hand? It just occurred to me that my minority handedness might be why I've always found large smartphones hard to use.
It will be interesting to see what conventions from Windows-Icons-Menus-Pointer (WIMP) interfaces still exist on mobile in ten years, when desktop UIs are mostly history.
We still type on QWERTY keyboards, even though the original rationale is long gone; musicians still make albums about an hour long even though they don't have to fit on two sides of a vinyl record anymore; we still have 60 minutes in an hour even though the ancient Babylonians' base 60 counting system has been gone for millennia.
I wonder how many more generations will continue to debate whether "cancel" should go on the left or the right?
When early cellphones came along I had no trouble using my left hand only when most "right-ies" I know used them with the right hand. Since smartphones became popular I still phone with my left hand primarily, though I have become more ambidextrous with it, and I've noticed that others seem to switch hands more too.
I look at it using a more logically safe approach where the first option should be cancel/back/safe_option to force people to think before clicking through.
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.
I'd follow the reading-direction paradigm for something like a UI or arranging books on a shelf, but not for art.
Back in 2010, a Youtuber named Derek Lieu created a supercut called "Every Anime Opening Ever Made" [0]. One of the notes:
> Interesting thing I learned, if a character is running it's overwhelmingly to the left of the screen.
(Watching the video, "running" may as well also include "standing" and "flying")
Characters moving is a bit different than a diorama, but there may be something to it. I think I remember something similar someone else had found about western animation, that it's biased towards having characters move to the right rather than the left.
[0] https://www.youtube.com/watch?v=ibPCLMH1NM4
So how would this work in Ancient Greece where they wrote boustrophedon (alternately left to right and right to left)?
And how does it work for illiterate people or peoples without a written language?
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.
Whilst I initially thought it was cool, it quickly wore me out. Often times, if I was in the 'flow' of editing, that tiny fraction of time that it took me to stop and have to actually read the screen (instead of habitually clicking on a position without even reading) was enough to interrupt my thought processes and impact my productivity.
I think it would be like randomly rearranging the clutch/brake/throttle pedals on a manual car every day. Sometimes you just want your tools to stay out of the way and not interrupt you when you are busy. It is far better to have your feet (oh, ok - mouse cursor) fall to the right places without having to think too much, especially if your mind is busy on more important stuff happening.
I think one of these may have been meant to say left!
Another thing to note in the Factorio mockups is the use of a guideline that I originally picked up from the macOS HIG[1]: use descriptive verbs rather than a generic confirmation.
"Apply settings" vs "OK"
"Load game" vs "OK"
"Delete file" vs "OK"
"Send email" vs "OK"
"Print" vs "OK"
and so on.
[1]: https://developer.apple.com/design/human-interface-guideline...
People don't read the message in the popup. But when presented with a Delete button users start to think about what they are doing.
Also: 'Delete - Cancel' sets 'Cancel' in a much better context. You are going to cancel a delete action not an 'Ok' action.
Instead, the UI should be seen to do the operation, but then delay its execution while showing an "undo" for a few seconds.
The reason for this is that 99.9% of people know what they're doing. So don't bother them for the sake of the 0.1% who make a mistake.
But more importantly - for each dialogue (of whatever kind) you have in an application, the chances of the user reading it declines by the square of the number of dialogues they encounter in a given session to the point where they will never be read, ever.
Pretty sure there are a plethora of options for each OS but here’s a couple:
For OSX, homebrew has a handy “trash” command line tool [1].
For Ubuntu, trash-cli seems popular [2].
1. `brew install trash`
2. http://manpages.ubuntu.com/manpages/precise/man1/trash-put.1...
Is it still going to be out of scope if he e.g. runs the shell script from the shell?
That is a worse user experience by far - you should never tell someone something has been done unless you are sure it has been done permanently.
https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse...
https://www.nngroup.com/articles/ten-usability-heuristics/
https://asktog.com/atc/principles-of-interaction-design/
In your example, you could use a dialog during the first delete with a toggle option in the delete confirmation dialogue of "don't show this next time."
https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse...
The issue is that novice, elderly, power or otherwise, if you have dialogues popping up all the time asking you if you're sure, and 99% of the time you ARE sure, then pretty soon you will habituate to just hitting OK whatever until the one time you DON'T mean OK, at which point you have an undo.
This isn't controversial, or just my opinion, it's observed, researched HCI stuff (mainly in the context of aircraft cockpit design but also on desktop software and the web).
> 99.9% of people know what they're doing
You have very different users than those of anything I've ever written then. :)
Well, and it is also much easier to quickly locate and hit an Undo-button on a small touch screen than it is with a mouse on a giant screen.
But yeah, I definitely also see a lot more confirm-dialogs still.
Seems to be a classic case of such a UI pattern being great and hyper modern and marketable in 99% of cases. But if in 1% of cases, the user accidentally deletes a file that they didn't want to delete, then you lose that user in that exact moment.
That is, if you are not a preinstalled app. If instead you are Google, then users are generally not aware of alternatives and cannot switch away from your app, if this happens to them. They just live with your UI eating their files.
Not to mention that it was quite clearly their fault for not finding the Undo-button quick enough. Which is also generally an opinion that users manage to hold, who have not yet progressed to looking at alternatives of programs and comparing different UIs for their merits.
Perfect example of a UX pattern that's simply asking for trouble, or being clever rather than helpful. :)
You can undo if you notice quickly enough, if your dog, child, doorbell or 1,001 other things didn't distract you at the wrong moment and if you didn't get an incoming call in the temporary undo window. No, we won't tell you how long you can undo for, even though times can vary. Don't be old (or even middle-aged needing reading glasses), or slow.
Seems very much against long known recommendations from Nielsen et al for consistency of expectation etc.
A quick skim through search seems to indicate it came with Material Design. I suspect had it generally caught on it my switch to iOS would have come even sooner. :D
https://asktog.com/atc/principles-of-interaction-design/
Relevant to delete / undo they talk of the preference for an undo (eg ^Z at any time) to "Are you sure?". No mention of delaying action or availability of undo. Then preference for consistency of action - within app and generally, not deviating from common expectations (eg that a trash can allows restore), and recommendations for visual feedback when latency and delay is involved. None of which fits the original temporary delay/undo.
In both of those links I posted, it clearly states well-designed systems have undo.
People could override them but after decades of use most make sense.
I'm sure MS flipped the MacOS ones simply for liability reasons (initially).
I've always looked at interface choices like this: As a non-Chinese reader, if I see a dialog in Chinese and the "Yes/Confirm" and No/Back" buttons are the same size, shape, and color, I will have no clue which does what. However, if the "Yes" option is a darker shade, or has bolder text, or the button shape makes it scream "click me!", I'll feel relatively confident that this is the button I need to press to proceed with whatever I'm trying to do.
And then there is the new UI paradigm, seen on many web apps, where "positive response" is replaced with "whatever response would be the best outcome for the company".
When we start using a UI we certainly read every button before clicking on one, but after a while we just want to find the correct button. And in that case it might be helpful to place the button for the primary action right next to the bottom right corner, as that corner is one of the places we start looking for the button. With the OK-Cancel order, the OK-button would be hidden behind the Cancel-button.
Nevertheless, this factor doesn't change anything about your conclusion. I think your argument is very balanced and I agree with your conclusion about consistency being the most important factor.
To add to this, if we're doing a task, it's probably safe to assume we're more interested in going on with it, so there's a reason for the affirmative button being at the left of the group (first to be parsed). Also, you typically ask "Yes or no?", not "No or yes?". Just a maybe different perspective from a Windows user.
Companies make these 'slightly different' approaches often and probably usually to avoid design patent issues.
Microsoft also put the toolbar with the menu for getting to your programs a the bottom with the 'Start' menu, this really should have been at the top. Apple had their menu at the top so Microsoft did it differently. In those days I found it absurd how you had menus flowing out from the bottom left of the screen. Moving the menu to the top was drag and drop but nobody bothered, therefore having it wasn't that big a deal.
Microsoft had to work with IBM on the original Windows so they got a lot of things right including the universal shortcut keys for menu actions. You were never left requiring a mouse except for in MS Paint.
Surely the file dialog boxes and whatnot were designed to 'not look different' but tied in to this universal hotkey thing they had going, i.e. some sensible rule so you could tab or arrow key away from the 'OK' button?
That just makes my own things consistent with each other. I thought the problem was to decide what _everyone_ should use.
External consistence isn't subjective. It's as objective to that system as any other fact, and is a matter of understanding, not feeling or choosing or designing.
If you're building an extension to MS Office, make your app comply with MS Office. Same with Adobe Photoshop plugins. And ultimately same with apps/programs for an OS.
If the OS does OK-left, do OK-left.
The UI that does not exist is the UI that is performing the best.
No one "uses" a UI. They just pass it. If you're thinking too hard about it, chances are you'll make your users think about it also. And trying to get noticed will always be at the expense of usability.
And finally, metrics such as consistency, obviousness/coherence, and simplicity are also objectively measurable, as are error rates, A/B tests, and step counts. What is subjective is user feedback and even developer feedback. By tallying what people think of an interface, you've already abandoned the goal of remaining unnoticed, and this is how Frankenstein UIs are built.
OK and cancel don't consider this aspect as much, but IMO OK should require more conscious movement to accomplish. I'd rather accidentally cancel sending an email than accidentally prematurely send one for example.
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.
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".
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-... (KDE)
https://docs.kde.org/trunk5/en/kdeaccessibility/kmouth/kmout... (KDE)
https://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/kdial... (KDE)
https://www.sao.ru/hq/sts/linux/book/xbook_marshall/prompt.g... (Motif)
https://www.sao.ru/hq/sts/linux/book/xbook_marshall/dialog1.... (Motif)
http://northstar-www.dartmouth.edu/doc/idl/html_6.2/images/m... (Motif)
http://www.antillia.com/oz++/images/IconBar.png (Motif)
https://tkdocs.com/images/idleprefs_l.png (Tk)
http://zetcode.com/img/gui/tkinter/colorchooser.png (Tk)
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... (dialog)
https://i.imgur.com/ruW7AQE.png (Free Vision)
https://raw.githubusercontent.com/pfalcon/picotui/master/pic... (picotui)
Also FWIW in my own programs i am always going OK -> Cancel since it feels more natural.
[1] http://www.geocities.ws/mowasel/tech_zone/images/dialog5.jpg
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
My apps are in Qt, and the dialog boxes are idiomatic on all platforms without me having to know or check.
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.
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)
[0] http://uxmovement.com/buttons/why-ok-buttons-in-dialog-boxes...
What do you think, no or yes?
So I go with Cancel-Ok, but holding this conviction very loosely.
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.
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.
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 ;-)
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).
Linux programs are especially bad in this. You never know what you'll get.
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
It's System Preferences → Keyboard → Shortcuts → All controls on my Mac (10.13.5)
Wrong.
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.
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.
I don’t think that’s deserving of “wow”. I don’t think it’s that big of a deal. It’s a clear option that is quite visible and present in the exact preference pane you’d expect. And you don’t need to activate it manually. You can do it via CLI:
> not just bolted on as an afterthought.I haven’t used Windows in years so I can’t compare, but keyboard support on macOS doesn’t feel like an afterthought to me. Without leaving the same screen where one activates keyboard support for all controls, one can also change and set keyboard shortcuts for every other action including every menu option of every app. And if doing it manually isn’t your thing, you can also define those keyboard shortcuts via CLI. It even works for setting single key (no modifier) shortcuts.
When you make a mistake that prompts a dialog box, having to move your cursor to undo can feel slightly punishing. Doing it with a single key press makes it feel like part of the process.