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

Comments

User interfaces

[MartinG]

While not specifically relating to user interfaces of computer software, there is an excellent book relating to making things in general easy to use, and most of the ideas translate well to GUIs.

The book is called "The design of everyday things" by Donald Norman.

Re:User interfaces

[morgan_greywolf]

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.

Re:User interfaces

[SQLGuru]

7) Know your audience.
          -This is related to #5 in that your audience determines what features should be prominent: the person answering the phone needs the "take message" feature to be easiest to reach....the person at the cash register needs the "ring up sale" feature to be easiest.
          -This is related to #6 in that your audience determines what colors are good / bad (think "high contrast" color schemes for visually impaired, cultural implications of color, etc.)
          -This is related to #3 in that if your audience is Slashdot readers, they expect skinning and an options screen with 50,000 selections.....if your audience is the owner of the basement you live it, they expect a single button that is labeled "Do What I Mean"

I'm sure that principle applies to the others in some way, too, but you get the idea.

Layne

Re:User interfaces

[Khelder]

I agree with all your numbered items. However, you said these were "crap":

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

I'm surprised you said that, considering your advice sounds a lot like what this sort of book recommends.

If someone doesn't know anything about HCI and wants to make good UIs, I think it would be really helpful to do some reading. If I had to choose just one, it would definitely be Norman's Design of Everyday Things (which I saw others recommend, too).

One thing that HCI books do is not just recommend what to do, but give guidelines how to do it. For example, a good way to get early feedback on a UI is with prototypes. There are lots of different kinds of prototypes you might build, and each have pros and cons. A good book could help you decide which kind of prototype to use when.

Another example: you'd like to evaluate your UI somehow, to see what's good, what's bad, etc., right? But how? User studies are one that lots of people know about, and they have definite advantages, but they're really hard to do right, and they're really labor-entensive. The right HCI book will tell you about cheap evaluation methods, too, what the pros and cons are of the various methods, and help you decide which one(s) are right for your project.

2) Some vague advice about making look like the OS you're targetting.

Sounds to me a lot like your #6.

HCI

[Pisal]

Regarding the topic, there is an area of study in Computer Science called HCI (Human Computer Interaction). Take a look at this article for a starting point on that issue.

http://en.wikipedia.org/wiki/Human-computer_interaction

"I have no clue how to write a good one."

[El_Muerte_TDS]

Doesn't matter, neither does anyone else.
There is one important rule in creating a GUI: follow the same design principles as the target OS and applications with similar functionality as yours.

If you're developing for Windows...

[PhrostyMcByte]

I don't have any book recommendations, but if you're developing for Windows, be sure to read the Windows Vista User Experience Guidelines. Even if you're not on Windows it has some design advice applicable anywhere.

Re:If you're developing for Windows...

[MBGMorden]

There are a lot of things driving people from Vista, but it's interface generally isn't one of them (I did say generally, just to counter those 3 people who respond immediately with "But I did!"). Microsoft has invested a lot into user interfaces, and most people find their programs VERY nice to use. Microsoft's problems come from DRM, poor security, traditionally poor stability, and anti-competitive practices. Those are all good reasons to look at something different. I wouldn't knock their interface though.

Re:If you're developing for Windows...

[sm62704]

I mostly disagree. You should use the conventions that the user expects, of course, but don't look to Microsoft for good design. Silk purses and sow's ears and all that, you know.

Study Microsoft design for good design in the same vein as going to webpagesthatsuck.com/ for learning good design. For example, if you have the "options" uder "file" in version 1.1 of your program, don't move it to "edit" in 2.1 and "tools" in 3.1 as Microsoft is wont to do.

-mcgrew

From the linked site (and I haven't put all the checklists in, because slashdot's horrid design gives an error message about too few characters per line):

The answer sheet: If you check the box for any of the questions, your web site sucks. Period.

There is a really big problem, though. It takes a great deal of knowledge to fill out the checklist. You have to know how your site is constructed and you have to have a good understanding of web design. If you don't know what a MARQUEE tag does or that your site's content came from a Microsoft Word document and was converted to HTML, how can you fill out the checklist?

Note #1:
Apparently, nobody likes to read much, which is why I haven't put a lot of explanations or outside links in the checklists. I've been looking at sucky design for the last 11 years and I've only been wrong once. That's a topic for another day.

Note #2:
Yes, WebPagesThatSuck.com fails to pass the checklist. The site's design has always sucked.

Checklist 1: First Impression / Big Picture

• We've designed our site to meet our organization's needs (more sales/contributions) rather than meeting the needs of our visitors.
• Our site tries to tell you how wonderful we are as a company, but not how we're going to solve your problems.
• It takes longer than four seconds for the man from Mars to understand what our site is about.
• The man from Mars cannot quickly find the focal point of the home page.
• The man from Mars cannot quickly find the focal point of the current page.
• Our site doesn't make us look like credible professionals. Our site doesn't make visitors feel they can trust us.
• Our home page -- or any page -- takes more than four seconds to load.
• Quickly scanning the page doesn't tell our visitors much about its purpose.
• We don 't put design elements where our visitors expect them.
• We have not eliminated unnecessary design items.
• We don't know which design items are not necessary.
• Our site breaks when visited with the Javascript turned off.
• Our site breaks because of back-end coding errors.
• We say "Welcome to..." on our home page.
• Our site is Flash-based (and this is what our site looks like to people without Flash.)
• Our site's navigation is Flash-based.
• Our site uses a splash page (unless it's a liquor, porn, gambling, adult, tobacco, or a multi-lingual / multinational site).
• Our site makes visitors register before they can enter.
• Our site uses two or more splash pages.
• Our site's TITLE tag is something like "New Document", "Index" and not the name of your company or other search-engine friendly terms.
• Our site has a sound file automatically play in the background when a web page loads, but we're not a record label or musician
• I don't know if our site looks the same in the major browsers.
• Our site doesn't look the same in different browsers.
• The important content does not fit in the first screen.
• Our pages have too much/too little white space.
• Our site uses pop-up windows.
• Our site forces visitors to install weird plugins.
• Our site has "Download latest browser" text or buttons.
• Our site prominently displays what hardware and software was used to create the site.
• Our site's design was "borrowed" from another site.
• Our

art of interactive design

[jrexilius]

by chris crawford..

its great.

google books

I would suggest...

[scafuz]

I would suggest you two books:
1] GUI Bloopers 2.0: Common User Interface Design Dont's and Dos [Morgan Kaufmann Publishers]
2] Designing Interfaces [O'Reilly]
the first to understand what not to do and the other one to get some good ideas to start from.
I really think any book will do, except any Jacob Nielsen's books about usability... I've read them at the very beginning of my career... I think it was jus a loss of time

Re:Depends

[Amouth]

i agree but from a personal perspective for UI i always try to look at is

-who is going to be using it and their relitive understanding of what is happening
-what
          -what is it that i am having to show the user
          -what is it that they want to do
-where (as in environment) is this going to be used? (sales register - production floor - pda on the go - person at random cube desk)
-why is this application even existing what is it's true purpose

once you answer the w's you can then figure out the
-how
so that it meets what you want in the w's

also remember to include the users in the design.. their info is invaluable - as they are the ones that will decide if the app survives.. you will hate nothing more than to write something you like and think is wonderful only to see it sit idle or have people bitch all day about it

- also note that you learn from experience.. you will not get it right the first time..

Top ten list by HCI prof

[stew77]

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.

The basics:

[localroger]

1. Make the most common operations the easiest to get to, and hide things that aren't done very often behind menus and secondary forms.
2. Use it yourself, and rearrange the controls to get rid of any apparent awkwardness.
3. Give it to the actual end users, and be prepared to rearrange the controls again when you notice all the unexpected things they do to it.
4. Don't get cute. Use standard controls that people recognize.
5. Pay attention to keyboard shortcuts and tab order. Don't make the user use a pointing device.

By far the biggest thing is the willingness to refactor. You won't get it right the first time; that's almost impossible, and nothing is worse than a UI that is written to spec and then slavishly nailed to that spec even when the users complain about it. You'll probably find something that you thought would be a common operation is hardly ever done; get the annoying button out of their faces. And something else you thought would happen once a month happens every hour; bring the control out front for them.

GUI design tips

[Tsu Dho Nimh]

Tips are all over the internet. I'd start with the Alertbox by Jakob Nielson (ex-Sun employee, now a usability consultant) and anything his group has published on user interfaces. http://www.useit.com/alertbox/

My pet peeves in GUIs ... the designers ignore that people actually have to read the GUI, and treat it like it's supposed to be admired for artistic. For a GUI, bland and boring is good, functional is the goal.

• Gaudy color schemes: High-contrast is good, but that means high tonal contrast, not screaming red on puke green. Dark text on a pale background is the best for most users, and the colorblind. To test your design, print it out on a black and white printer. If you can't read it, you have the wrong colors
• Too-subtle color schemes: Pale shades of blue with gentle grey text, unreadably misty and soothing.
• Reversed tones: pale shades on dark, for optical reasons need special spacing if you don't want the verticals to blur together.
• Bizarre fonts and font sizes. I remember one supposedly great CD player software that had a jagged "lightning bolt" font for its control labels ... couldn't read them at all, so I deleted it.
• Odd names for things that have well-known common names. Don't call the mute button the "audio whiffer", even if the developers call it that.
• Multiple names for the same control, on different menus. Pick a name and use it all over the GUI.

Bruce Tognazzini

[deacent]

My favorite expert on UI is Bruce Tognazzini. His site at http://www.asktog.com/ has been quite useful to me. I don't agree with everything he says, but it's always gets me thinking, always challenging me to approach development from a human perspective.

Macintosh Human Interface Guidelines

[amper]

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.

Re:Depends

[sm62704]

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

Re:What I like to do.

[KURAAKU Deibiddo]

You mean that they consistently change where things are for no good reason, between versions of Windows? Because I have to say, that's my favorite feature when Windows-users look to me for support and I don't have a VMware image in front of me. It'd be one thing if I had to support it full-time, but even though I've used every version of Windows since 3.11, it's no longer my primary operating system, and hasn't been for years. (In fact, I seldom use it outside of VMware). Trust me, it's a pain remembering that feature x is located one place, in Windows 2000 Professional, and usually one or two menus deeper with XP. Ranting about Vista, on the other hand, would take forever.

And GUI consistency? Please. Have you tried running Microsoft Money on Windows 2000? How about Windows Media Player on any version of Windows? Microsoft is great at making applications that look nothing like the GUI when it suits them to do so. Perhaps they've made some improvements, here and there, but they still has a lot to learn when it comes to GUI consistency.

Look at this before you try to tell us of how "consistent" the Windows GUI is:

http://www.joelonsoftware.com/items/2006/11/21.html

Hall of Shame

[Ed Avis]

Don't forget to have a good look at the Interface Hall of Shame for examples of what not to do.

Pig Toaster - duh

[Dareth]

if you use the pig's snout as a lever to make the bread go down, you have a shitty design.

Well duh, any good Pig toaster obviously would use the pig's tail for a lever!

Good User inteface Design Tips...

[linebackn]

If you want to whiz off your users...

From http://toastytech.com/guis/uirant.html

General application user interface guidelines:

* Always use cute icons, buttons, and graphics. Everyone loves big red hearts, pink bunnies, and yellow smiley faces.

* Don't be afraid to experiment with colors!

* Your application should play fun sounds while operating to keep the users entertained.

* Never, ever, under any circumstance use the OS-native graphical controls or widgets. Users get bored of the same old buttons, text boxes, and stuff.

* When possible, disable window management and use unusual, oddly placed graphics for the windowing functions such as the window close option.

* When writing your own controls or widgets, make absolutely sure they look and feel nothing like the OS-native widgets or anything else the user might expect. Otherwise you might accidentally make the user think that your application is actually designed for their OS.

* Use your own creative ideas on how a "save as" dialog should look and work. Built in ones are always too limiting.

* It is important that the user should never be able to tell the difference between a checked and unchecked check box or option box.

* Always use obscure or poorly drawn graphics for your tool bar buttons, and never put text on them.

* Avoid including a preferences or options dialog. Instead, let the user use the standard OS provided text editor or an editor of their choosing to edit text configuration files. .

* Users need time to think about what they are doing and get coffee. Your application should always take at least 5 minutes to load even on the fastest available computer.

* Make sure an accidental double-click on a single-click item does something really nasty or unexpected.

* Tool tips are the perfect way to display critical information.

* To get the most screen space, force your application to always run maximized.

* Always make the default positions of floating properties windows cover something important.

* Use the most exotic fonts you can find.

* Your application's user interface should be flexible and customizable to the point where if the user accidentally sneezes on the mouse or keyboard they will have to spend the next half an hour setting things back.

* Let a 5-year old draw your graphics, including your corporate logo.

* File browsing dialogs are not needed, users can easily remember and type in long file paths.

* Design your application so it requires the user to set their tiny monitor to 10512*7430.

* Always crash at a critical step and then display a fake apology to the user.

* It is a mistake to make use of application hooks in the native desktop environment such as new file templates, file associations, or program menu icons.

* The exception to the above is placing icons in the system tray. Place as many icons as you can in the system tray and make sure that the user can not remove them.

* If your program implements keyboard shortcuts be original and make them completely different from any other applications.

* Rent extra UI space in your application out for advertising. Advertising benefits the users and y