
Designed with programmers in mind, this readable book examines User Interface Design and concentrates on the common mistakes that too many programs exhibit. It also includes numerous examples of how to improve common programs. Includes a foreword by one of the most influential programmers today, Dave Winer, founder of UserLand Software.
It covers some foundational ideas of what makes a good interface.
Here are three steps you can take:
1. Read Don't Make Me Think by Steve Krug, User Interface Design for Programmers by Joel Spolsky, Refactoring UI, and (optionally) The Design of Everyday Things (this will get you paying attention to UX and UI in the real world). The core principal of good UX is Spolsky's maxim: "A user interface is well-designed when the program behaves exactly how the user thought it would."
2. After reading, go do 10 hallway usability tests on an interface you know well.
3. Then redesign the interface using the principles from #1 and run usability tests on that. Later, rinse, repeat.
The main idea here is:
1. Get some decent grounding
2. Learn from where users stumble over an interface
3. Try and improve the interface
4. Get feedback on your improvements (did they help? what other problems did they cause?)
> The see-and-point principle states that users interact with the computer by pointing at the objects they can see on the screen. It's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible (all files more than one week old), objects that don't exist yet (future messages from my boss), or unknown objects (any guides to restaurants in Boston).
Does this mean a commandline is always better, because it's more expressive? No, it's a trade-off between this and ease of learning:
> The GUIs of contemporary applications are generally well designed for ease of learning, but there often is a trade-off between ease of learning on one hand, and ease of use, power, and flexibility on the other hand. Although you could imagine a society where language was easy to learn because people communicated by pointing to words and icons on large menus they carried about, humans have instead chosen to invest many years in mastering a rich and complex language.
There's a neat coincidence that illustrates this tradeoff. While this article says:
> If we want to order food in a country where we don't know the language at all, we're forced to go into the kitchen and use a see-and-point interface. With a little understanding of the language, we can point at menus to select our dinner from the dining room. But language allows us to discuss exactly what we would like to eat with the waiter or chef.
Joel Spolsky's User Interface Design for Programmers (an excellent book, looks like it's available online in full on his blog: https://www.joelonsoftware.com/2001/10/24/user-interface-des...) says:
> Using a command-line interface is like having to learn the complete Korean language just to order food in the Seoul branch of McDonalds. Using a menu-based interface is like being able to point to the food you want and grunt and nod your head: it conveys the same information with no learning curve.
I'm pretty sure it's a coincidence that the same example of a restaurant in a foreign country is used, but despite apparent contradiction, they make the same point: The text interface requires more time to learn, in return for being more expressive and powerful. Whether that's worth it to you depends on how long you intend to live in that environment, and how rich an experience you'd like to have.
FWIW Joel's coverage of user design is a great read for things like this: http://www.joelonsoftware.com/uibook/fog0000000249.html
> Most flame wars you read about user interface issues focus on the wrong thing. Windows is better because it gives you more ways to resize the window. So what? That's missing the point. The point is, does the UI respond to the user in the way in which the user expected it to respond?
Most open source tools tend to be written by developers for developers and very rarely take into account the usage patterns of users in the domain which the tool fits. Want to know why Slack is tearing into all these areas that IRC could never get a foothold? You have the answer right there.
http://www.joelonsoftware.com/uibook/fog0000000249.html
Also highly recommend Steve Krug's "Don't Make Me Think" (as others have already commented): http://www.sensible.com/dmmt.html