Slashdot Mirror
GUI Design Book Recommendations?
jetpack writes "I've always hated writing user interfaces, and graphical user interfaces in particular. However, I suspect that is largely because I have no clue how to write a good one. I don't mean the technical aspects, like using the APIs and so on. I mean what are the issues in designing an interface that is clean, easy to understand, and easy to use? What are things to be considered? What are things to be avoided? What are good over-all philosophies of UI design? To this end, I'd like to pick up a book or two (or three) and get my learn on. I'd appreciate some book suggestions from the UI experts in the Slashdot crowd."
Here's a list my former professor compiled:
1. Alan Dix, Janet Finlay, Gregory D. Abowd, and Russell Beale: Human-Computer Interaction
2. Ben Shneiderman and Catherine Plaisant: Designing The User Interface
3. Donald A. Norman, The Design Of Everyday Things
4. Jenny Preece, Yvonne Rogers, and Helen Sharp: Interaction Design
5. Jef Raskin, The Humane Interface
6. Terry Winograd (ed.): Bringing Design to Software
7. Brenda Laurel (ed.): The Art of Human-Computer Interaction
8. Apple Computer: The Apple Software Design Guidelines
http://media.informatik.rwth-aachen.de/HCIBooks
Keep in mind that testing your UI on real users is very important. Just because you think it's a good UI doesn't make it a good UI.
Start with the original Macintosh Human Interface Guidelines. Apple Computer put forth an extremely strong effort in researching basic human interaction with graphical user interfaces during the development of their products in the 1980's, and this book is still the gold standard, even if Apple themselves disregard much of its advice nowadays (mainly because Apple was taken over by the team from NeXT). Remember that when Apple was developing the Lisa and Macintosh interfaces, the general populace had never yet been exposed to this type of interaction with technology, and quite a lot of emphasis was placed on making available powerful features to expert users that were easily accessible, yet unobtrusive to novices.
Along the same lines, I would recommend the original interface guidelines manuals for many of the early graphical operating systems, especially those for early PDA's, like GO's PenPoint, Apple's Newton OS, and the manual for General Magic's Magic Cap.
All of the aforementioned books are out of print, but any serious student of interfaced design should own all of these.
That's a good book and it has plenty of common sense principles.
Most of the people on here will say something along the lines of one of the two variants:
1) Human-computer interaction is a discipline and you should read this HCI book or that HCI book. (Alan Cooper's About Face comes to mind).
2) Some vague advice about making look like the OS you're targetting.
It's all crap. Good interfaces are built by following a few principles:
1) KISS principle -- Keept It Simple, Stupid. You don't need to make every friggin' thing customizable and you don't want to overwhelm your users with a multitude of options.
2) Make it 'just work'. Automate as much as you can. Try to have configuration options that either will work in the vast majority of cases with the defaults, or have the application automatically try to determine the best settings for the user's environment. The best configuration dialog is one the user never has to see.
3) Softer software -- make things customizable, but in a way that they don't HAVE to be customized for a good user experience. Most users won't customize their environment very much. Always keep this in mind.
4) Present as little of the interface as necessary to accomplish the task at hand. Better to have more dialogs or dialog tabs with a few options than one big gargantuan dialog that has everything.
5) On layouts -- put the most commonly-used controls in a very prominent place and make them big and easy to click on. Things that are less likely to be used should be smaller and out of the way. Buttons are better than menus, but don't end up with so many buttons that the user gets lost -- again, fewer controls on more windows is better than more controls on fewer windows.
6) Don't use gaudy, distracting color schemes or fonts. Make it fit-in with the user's environment. If possible, on GNOME, you want to follow the GNOME HIG. Ditto for Mac. On Windows, follow the 'User Experience Guidelines.' But this shouldn't be your overriding priority. Don't scrimp on the other principles I've outlined just because you're trying to shoehorn your application into the OS vendor's model of what an application should look like.
My blog
It should combine form and functionality
Wrong. "Form follows function" is one of the main tenants of good design. Make your toaster as pretty as you like, but don't forget that its function is to make toast, with the least amount of effort for the toaster user as possible.
If you make your toaster so that it looks like a pig, fine, but if you use the pig's snout as a lever to make the bread go down, you have a shitty design. It should be obvious to the user HOW to make the bread go down.
If your user needs to RTFM, you have failed in your attempt to design well.
-mcgrew
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest