Principles of UI, A Thread:
1. natural mapping
2. visibility of system state
4. constraints and affordances
5. habits and spatial memory
6. locus of attention
7. no modes
8. fast feedback
9. do not cause harm to a user's data or through inaction allow user data to come to harm
10. prefer undo to confirmation boxes. For actions that can't be undone, force a "cooling off" period of at least 30 seconds.
11. measure using Fitt's, Hick's, GOMS, etc. but always test with real users.
12. don't assume that your skills or knowledge of computers as a designer or programmer in any way resemble the skills or knowledge of your users.
13. Consider the natural order of tasks in a flow of thought. Verb-Noun vs. Noun verb. Dependency->Dependants vs. Dependants->Dependencies.
14. Instead of having noob mode and advanced mode, use visual and logical hierarchies to organise functions by importance.
15. Everything is an interface, the world, learning new things, even perception itself
17. Consider the 3 important limits of your user's patience:
0.1 second, 1 second, 10 seconds
18. An interface whose human factors are well considered, but looks like butt, still trumps an interface that looks slick but is terrible to use. An interface that is well considered AND looks good trumps both, and is perceived by users to work better than the same exact interface with an ugly design.
19. Don't force the user to remember things if you can help it. Humans are really bad at remembering things. This includes passwords, sms codes, sums, function names, and so on. My own personal philosophy is to consider humans a part of your system, and design around our shortcomings instead of thinking of users as adversaries. Software should serve humans, humans shouldn't serve software.
The first 8 items of this thread are extremely terse, to the point of being meaningless on their own. Please use them as search terms, or ask me to expand on them when my dog isn't barking at me to go to bed.
21. Gall’s Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
22. show, don’t tell. lengthy tutorials and “protips” forced on the user at app start usually do nothing other than get in the way of the user’s task. if you want to teach the user about a feature, include easy to find examples.
23. don’t interrupt flow of thought. if a user is opening an application, they usually have some specific task to complete. nagging them at this point in time about software updates or handy tips is very user hostile.
24.many jokes are made about the “save” icon looking like a floppy disk. it’s very appropriate, since the command as a concept is built around the technological limits of floppy disks, limits that are comically irrelevant in the 21st century.drag your app out of the 1980s and implement autosave and version control already.
25. consistency consistently consistent. there’s few things more fun than designing your own custom ui widget toolkit, css framework, or interaction paradigm. however, please strongly consider *not* doing this. custom UI is like ugly baby photos. instead, stick as much to the HIG guidelines and conventions of the platform you are on, so users can use what they’ve already learned about where things usually are, and what the fuck the weird molecule icon does.
26. try to imagine ways to use your shiny new software to abuse, harass, stalk, or spy on people, especially vulnerable people. ask a diverse range of people to do the same.
then fix it so you can’t. if you cannot figure out how to do your special software thing without opening vulnerable people to abuse, consider not making it available to anyone.
27. UX is ergonomics of the mind (and also body). Where traditional ergonomics considers the physical abilities and limits of a human body, UX considers the limits of the human mind: attention, memory, response time, coordination, emotions, patience, stamina, knowledge, subconscious, and so on. If you ever find a UX practitioner sacrificing accessibility on the altar of so called “good experiences”, you are dealing with incompetence.
expanding on 1. Natural Mapping:
user interfaces typically “map” to the system they control, each button and dial corresponding to some element of the system. Natural mapping is when the interface forms an obvious spatial relationship to the system, such as 4 stovetop dials that are in the same arrangement as the stovetops. the anti-pattern is arranging controls in an arbitrary order with no spatial correspondence to the system.
2. Visibility of System State:
Software typically has state (to state the obvious), such as “where” you are in the software’s menu system, what “mode” you are currently in. whether your work is safely stored on disk or has “unsaved changes”, what stage of a process you are up to and how many steps are left. Failure to effectively communicate system state to the user is inviting them to get lost and make mistakes. counterexamples: setting the time on a digital wrist watch, programming a VCR
this is about making the possible actions in a system visible- or if not immediately visible, the mechanism of their discovery should be visible and consistent. For instance, the menu items in a GUI system are discoverable. the available commands in a unix system are not. the opposite of this principle is “hidden interface”, examples of hidden interface are rife in iOS: tapping the top of the screen for “scroll to top”, shake to undo, swipe from edge for browser back- etc.
4. Constraints and Affordances.
A constraint is something that is not possible in a system. an affordance is something that is possible to do. which is which should be communicated clearly- the nature of this communication breaks down into three subcategories:
visually obvious from the shape of objects in a system- two lego bricks can only snap together in a limited number of ways.
b. logical: what’s possible or not makes sense logically: e.g. color coding,
constraints and affordances is at the heart of the “flat design” vs. “skeumorphism” debate. the benefit of skeumorphic interfaces is that replicating the look of real world objects like buttons, provides a natural way to communicate interactions. where skeumorphism went wrong is communicating false affordances: a detail in the ios6 calendar app hinting that pages could be torn out- when no interaction supported it.
flat design throws the baby out with the bathwater. we still need real buttons.
@zensaiyuki This is an excellent thread, thank you!
@nindokag thanks. it’s basically my cliff’s noted from doing a lot of reading. hmm, I try my best to give credit where credit is due. hmm, #17. is an expansion of #8. oops. I should expand on the other first 7.
@zensaiyuki I feel like there could be a lot of benefit in more seamlessly integrating the terminal and GUI interfaces to the OS. What's lacking is a one-to-one correspondence with terminal and GUI behavior. Another thing is that the terminal itself could be designed with menus to perform actions, which it then automatically populates as a text command. Eg. You go to terminal and choose copy, it pops up a box asking for source and destination, autopopulates the terminal with eg (cont)
@zensaiyuki 'cp someFile someNewFile', then shows the user the copied file in the destination. Or something like that. It could be integrated into the file manager or something.
Or, you could use a journaling file system.
@zensaiyuki Just seeing this again, and it is annexcellent and illuminating summary.
@zensaiyuki You know who I'd complain about here?
Thankfully the W3C are trying to improve... But I'm significantly more willing to break backwards compatibility for the sake of privacy & security.
@zensaiyuki Also I did have to defend this UX principle. Sure there's tradeoffs to consider and we might miss things, but fundamentally too many (mainstream?) developers don't even consider it. We tend to be too optimistic!
@alcinnz there’s an episode of Star Trek: The Next Generation where they unfreeze a bunch of cryogenically frozen people from the 20th century. One of them goes straight to treating the ship’s intercom as something like room service or flight attendant request. Captain gets irritiated, and 20th century guy asks “if you didn’t want me to abuse the system, why didn’t you put access controls in place?”
captain says “because in the 23rd century, everyone knows not to abuse the system.”
@alcinnz i think about this a lot with relation to things like CAPTCHA. it’s gonna be an eternal cat and mouse game with bots until the day that there’s no economic incentive to defeat CAPTCHA, and the only way to get there is a radical overhaul of the global culture.
@alcinnz on the other hand, this approach is comically naive for a ship navigating unexplored and potentially hostile territories. the ship’s computer being hijacked because the captain’s admin password was “passw0rd” seems to be a regular plot device.
@alcinnz like the stories i’ve heard about former soviet states: after the fall of communism, lots of people just floundered, literally having no idea how to do cuthroat dog eat dog capitalism.
@zensaiyuki there is a cool dutch word for this which we repeatedly used in my design ethics class: "hufterproof" which means something like asshole/jerk/vandal-proof.
Every session we would think of ways to abuse our design and then think of changes to prevent them.
@zensaiyuki I do try to adhear to this for Odysseus (in bridging between an elementary OS & Web experiences), but for my other browser(s) I'm guilty of all three.
But really that's in the name of giving webdevs something even cooler to play with: Building webpages that works great on absolutely any device and/or OS!
@alcinnz i wouldn’t begrudge anyone their fun or their experiments trying to push the state of UI forward. brace for failure though. hopefully the “ugly baby photos” metaphors makes sense. years ago I took a photography class that forbade pet photos. Your pets always look beautiful to you, but that’s not enough to make it a good photo interesting for everyone else to look at.
@zensaiyuki Well, success to me looks like webdevs building more accessible pages. For it to be feasable for others to build their own, simpler, browser engines to display those pages. And for The Web to better protect users' privacy!
What I really care about are the deeper architectural issues, which I may still fail at.
@alcinnz that’s fine, my comment wasn’t personal. you’re talking to someone who designs widget toolkits for fun and has a list of UI guidelines pinned to their social media. I’d be a hypocrite to dump on you for designing widgets for fun.
@alcinnz and well, more broadly, you’d have to be fairy resiliant and inattentive to not have been occasionally annoyed by some electron app or cross platform ui toolkit completely breaking the conventions of your os, perhaps even having non standard keyboard shortcuts. or the morass of the linux/unix world where you’d be hard pressed to find any standards whatsoever. the trouble with quitting vim, for instance, isn’t that it’s hard to learn, it’s that it’s not just control+c or control+d
@alcinnz ah! i just rememebered the ui principle i was gonna post the other day and forgot. #32.
@zensaiyuki Yes, in discussing apps you will quickly find me saying that I highly prefer installing them from the elementary AppCenter. They do a great job enforcing standards (though there's a "uncurated" section)!
And how much I love & hate The Web is a huge motivation for me to write software!
Talking of which, someone please design elementary OS a nice instant messenger to tempt them off of Slack!
Oh, and you've tempted me to ask about your widget toolkits?
@alcinnz well, if they were in a stage I could talk about, I would. at this point it’s nothing more than a couple vague ideas and piles and piles of brain dumps in assorted notes applications.
@zensaiyuki I wonder if the argument changes if you imagine the word "save" being replaced with the word "commit" (as in version control, or committing a transaction).
Seems to me that "saving" isn't as much a technological limitation as it is separation between transient and persistent states. It makes sense in many a context, for the same reason you don't want your project to be rebuilt on every keypress, or your friend's IM displaying your message letter by letter as you type it.
@temporal the “argument” is just a reiteration of “visibility of system state” and “don’t cause a user’s data to come to harm”. the problem with “save” is the mistakes the basic design cause which lead to data loss. while what you’re saying has some sense to it, it’s not the word “save” that is the problem. it’s believing you’ve pressed it and that the save operation completed when it hasn’t.
@temporal and well, i myself have made that mistake plenty of times with git. or times i’ve committed but didn”t “push”.
@zensaiyuki This has been one reason I've looked at moving away from Atom. I often perform `git commit` from the command line and use my editor for filling in the message.
The 1s or 2s load time is enough to disrupt my thoughts. I switched to vim for a bit, and that is quite snappy. As I'm choosing to learn emacs, I've changed to use that for my messages
@takeonrules i tried atom once and immediately dumped it when it threw up a sequence of “save or discard” dialogue boxes on attempting to exit. once you’ve tried a text editor that just simply saves your workspace and then exits, upon telling it to exit, it’s hard to go back to software that doesn’t just do what you ask it to.
@zensaiyuki Relatedly don't ask any questions, if you can at all help it, at this time. Users won't know what to answer, and will struggle to change their answers later!
I've had to defend my adhearance to this principle in the past, but really breaking it is lazy!
@alcinnz also related #10,#23, #29, #30. so important i list it iver and over in different ways.
@zensaiyuki To expand on this point: Linus only wrote his code to run on his x86. Stallman did similar for his early GNU tools.
Early computers could really only handle English text, now they can easily handle practically any language. But it takes a lot more code to do so.
Now these projects are totally rewritten, and much larger.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!