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
16. Consider the psychology of panic. Panic kills scuba divers, panic kills pilots. panic kills soldiers. panic loses tennis matches. Panic leads to stupid mistakes on a computer.
more at: https://www.asktog.com/columns/066Panic!.html
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.
@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”.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!