Principles of UI, A Thread:
1. natural mapping
2. visibility of system state
3. discoverability
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: asktog.com/columns/066Panic!.h

17. Consider the 3 important limits of your user's patience:
0.1 second, 1 second, 10 seconds

nngroup.com/articles/response-

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.

20. Some Sources:
Donald Norman
Jef Raskin
Jacob Nielsen
Bruce "Tog" Tognazzini

I recommend all the talks by Alan Kay and Bret Victor, here's two:

Doing with Images Makes Symbols
youtube.com/watch?v=p2LZLYcu_J
The Future Of Programming
youtube.com/watch?v=8pTEmbeENF

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.

@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.

@alcinnz @zensaiyuki I don't think that could be correct, since GNU was originally a replacement for the built in tools on various UNIX distributions before anyone ever dreamed we could make our own kernels
Follow

@penny @alcinnz i’m having trouble connecting this to what he wrote. I read it as a list of 4 seperate but thematically related statements. “Stallman did similar [wrote for a single specific architecture] with GNU” doesn’t mention a kernel.

@zensaiyuki @alcinnz GNU, the utilities, they were fist written for other UNIX distributions, which weren't on x86. Eventually including Minix which would then be the first x86 version. It was made to be portable from the beginning.
Sign in to participate in the conversation
Mastodon

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!