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.
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. :)
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.
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
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...
rm () {
(sleep 30 && \rm "$@") &
}
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?
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.
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.
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.
I'd follow the reading-direction paradigm for something like a UI or arranging books on a shelf, but not for art.
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?
I think one of these may have been meant to say left!
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.
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
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.
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
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.
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.
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?
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 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.
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.
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.
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.
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.
That just makes my own things consistent with each other. I thought the problem was to decide what _everyone_ should use.
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.