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

Steenking book

[iMac Were]

Just copy whatever apple do. Save the trees, man!

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

[Jeppe Salvesen]

Agreed. Too many customization options indicates an immature algorithm.

Re:User interfaces

[owlstead]

7) Don't go and design your own framework. Try to rely on platform features as much as possible; people are used to those. And don't try and reinvent the wheel, use pre-build components when and if they are available. Don't forget keyboard input, and make sure that you can tab go the widgets in a non-obstructive way.

All these advises are really nice, but don't let your users learn everything from scratch. Unfortunately, even M$ and Apple sometimes forget this part. In most UI books, there is no distinction between creating platform widgets and creating an application. This seems to be a big oversight in my opinion, normally an application developer should not have to create everything from scratch.

Don't forget i18n if you are catering for a world wide audience.

Re:User interfaces

[Anonymous Coward]

Yes, the interface should look like the "The Hitchhiker's Guide To the Galaxy"
and have the words "Don't Panic" on it!

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.

Re:User interfaces

[savuporo]

Just one question. Why do you assert that a usable GUI has to have stuff like Dialogs, Buttons and Menus and the user has to Click on something ? I find all of these highly cumbersome UI elements.

Re:User interfaces

[tarrantm]

That's a good start, but one thing that I find essential is to make it customizable. Make as many elements as possible moveable and resizeable. For instance in the Firefox window I am using right now, I'd love to have my tab bar be vertical instead of horizontal. I'd love to have a search button that expands into a search box when I mouse over it. I'd love to resize the button bar and search bar. I'd love to be able to reposition the scroll bar into a two buttons on the top of the page so that one button allows smooth scrolling up and the other allows smooth scrolling down. Can I do any of this? Nope - I'm not a programmer or expert in GUI design, but I'm an extensive user of this GUI and I know what would make it easier to use. A way for the enduser to easily move, resize and re-align elements would be a huge step in user friendliness of GUIs. Even in the games I play, that's one of the nicest things to be able to do - I love that in WoW I was able to fully customize my UI. In LoTR Online, I can move and resize all the UI elements just by holding down a button. It's really sad when game interfaces end up being more customizable and user friendly than actual apps we use far more often.

Re:User interfaces

[jddj]

The Design of Everyday Things has a lot of great info, and is highly recommended, but first read:

      "Don't Make Me Think" by Steve Krug

It's a short, brilliant read, is mainly focused on web usability, but the principles can be extended to any UI design.

Really first-rate book - all content, no BS.

Re:User interfaces

[bendodge]

Please pay special attention to #2 of the parent's post. I tried using KDENLIVE to make a simple home video DVD, and everything was fairly intuitive until I tried to export it. I'm not a video formats export and all the cryptic options made me waste a lot of CPU cycles and DVDs.

If it had even a slight bit of "wizardry" it would make my life much easier.

Re:User interfaces

[poot_rootbeer]

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.

Remember that each of those projects had one or more genuine HCI experts involved in the drafting of their guidelines. Do you know HCI better than the top experts in the field?

Read the guidelines. Learn them. Understand them thoroughly. Heck, read the guidelines from platforms other than the one you're targeting, too. You'll find a lot of concepts that are common across all platforms; these you MUST not ignore.

It is sometimes necessary to deviate from published interface guidelines, but you need to have a REALLY GOOD justification for doing so, and personal intuition doesn't make the grade.

Re:User interfaces

[Anonymous Coward]

Having been heavily involved with HCI and UI design while working on my PhDs, I'd recommend Task-Centered User Interface Design: A Practical Introduction by Clayton Lewis and John Rieman ($5.00 (US) shareware from http://www.hcibib.org/tcuid/) and Tog on Interface by Bruce Tognazzini. Clayton and John's book will lead you through the process of understanding your users' needs (remember that interface designers are rarely the intended users of a product) and Bruce's book documents all of the early Macintosh UI guidelines and how and why they came about. Bruce also has a wonderful website (http://www.asktog.com/) where he's been a harsh critic of many of Apple's more recent UI decisions...

Re:User interfaces

[Anonymous Coward]

Too many customization options indicates an immature algorithm You keep saying that word. I don't think it means what you think it means.

Re:User interfaces

[yuktar]

The most important principle I can think of is to make sure that every major UI element corresponds to a user's desired end result. If I truly care how something is done, then I have no problem going to the advanced options. Otherwise, I probably want a big button that just gets me to the result, in whatever way it thinks is best, while I go make a sandwich.

Along those lines, any required interaction on my part should all be at the beginning whenever possible. I don't want to come back from making my sandwich and find that the program has been idle for several minutes because I wasn't there to click "Next".

Re:User interfaces

[digitig]

Good advice, but only enough to take you from a crap interface to a mediocre one. There's a hell of a lot more to actually making a good interface. For example, you don't seem to have considered issues of input devices, accessibility, i8n and so on. This really is a big subject, and while "just a few principles" can help get you off the ground (and yours do look like good principles to me), the person who wants to deliver a good user experience is going to have to go a lot further. "About Face" is good, as is Preece et al "Human Computer Interaction", although both are a bit dated in the application of the principles. I'd also second the recommendation for "The Design of Everyday Things" -- in fact, anything by Donald Norman, even though he's not computer specific. The value of his books is more in instilling the mindset that if you have to give instructions then you've got the affordances wrong.

Re:User interfaces

[thePowerOfGrayskull]

0) Be Consistent Users like to see the same thing in the same place, every time. And when the interface is inconsistent with itself (OK button above cancel on screen A, below cancel on screen B, in the center bottom for screen C), it makes it a lot harder for the user to become familiar and comfortable with it -- because they have to give /thought/ to what they're doing every time. This basically means that using your software is a constant irritation to your user. A prime example of what not to do is MS Office's "smart menus", which hide the most unused menu items; essentially making it possible to change the interface on a daily basis. (I understand why they made that design choice -- presenting too many options is almost as bad -- but IMO it was the wrong solution.)

An extension of this is: Don't get creative. While it may be great that you have a round traffic light showing green as your OK button, that's unfamiliar in this context. Present users with what they know -- you don't want to make them /think/ about using your application.

I'm sure someone else will or already has mentioned it, but User Interface Design for Programmers is well worth the short time it takes to read it.

Re:User interfaces

[Creepy]

Good points, and yeah "The Design of Everyday Things" has been a staple for UI and Mech-E ergonomics classes for many years and is quite a funny read.

A few things I remember from my UI classes

- Try to avoid non-movable, modal dialogs whenever possible - use them for emphasis on critical actions such as "Are you sure you want to Quit without saving?"
- Group things that go together, together. I see this all the time by untrained dialog creators (as a matter of fact, I'm reading a spec with lots of these). Say you have a user entry box, a list box and 4 buttons Add User, Remove User, Cancel and Finish. The User Entry Box, list box, Add and Remove buttons should be grouped because they go together, and the finalizing actions Cancel and Finish should be separate. Generally, this is done with a line box around the grouped items and/or extra white space between the two groups.
- Use page flow for whatever language you use. Usually this means flow your dialog from top left to bottom right. A language like Hebrew would go from top right to bottom left. There are some arguments on whether buttons such as OK and Cancel should be bottom left or bottom right, but that is nitpicking - as long as it flows from top to bottom, great. There are some exceptions to this for some cultures, so it's more a guideline than a rule.
- Use appropriate controls for the dialog. For instance, use checkboxes for multiple choice and radio buttons for "exclusive or" choices. Make sure they're grouped appropriately, so if you have two separate sets of radio buttons, you can distinguish between the sets (I used to see this a lot, but not much anymore).
- Avoid complex language and unusual phrasing whenever possible. A PRIME example of this is MS Word in the 1990s, where they had a dialog "Are you sure you want to Revert your document?" This option also happened to be close to Save and I know many people that lost documents because of it (I worked in a liberal arts computer lab).
- Leave some space between buttons. I see this mostly with Java dialogs, where 8 square buttons are crammed together without any space between them and only an outline to distinguish where one ends and the next begins.

I agree HIG are GUIDELINES not rules. They help you design an experience in a consistent way, but they can't predict every use of every feature, so there are times you will need to stray. Apple says a menu bar should always be on top, but that might not work for a game or tray widget.

Re:User interfaces

[Fred_A]

Just one question. Why do you assert that a usable GUI has to have stuff like Dialogs, Buttons and Menus and the user has to Click on something ? I find all of these highly cumbersome UI elements. So you're saying a good GUI would just have a window to type commands in ?

Re:User interfaces

[nullchar]

Agreed. "Don't Make Me Think" has some simple examples too. I feel designers (from executive Product Management all the way to the end Developer and QA teams) should read it in order to think about the GUI in a slightly different way.

Re:User interfaces

[sucati]

I've been trying to read that book for over a year -- it's so boring I don't get very far before I pickup another book.

Re:User interfaces

[savuporo]

So you're saying a good GUI would just have a window to type commands in ?

Absolutely not, although for certain subset of user interaction problems i have yet to see a better solution.
What i AM saying, however, is if you want a good user interface for a given human-machine interaction problem, you cant start out with unquestioned assertions. If you start defining the problem in more detail and begin constraining it with certain technical limitations and other restrictions, undoubtedly this will often steer your solution to some commonly used UI paradigm, like windowing and menus and buttons, but this is not universal, and sometimes you need to question whether your imposed limitations and constraints actually apply to the problem.

Re:User interfaces

[marcosdumay]

Altough usefull on some circunstances, that is bad advice to give to an unknown audience. All the above things make software good for a fraction of the population (and is very focused on it), but neglet the others.

The Inmates Are Running the Asylum, from Alan Cooper is a very nice introduction to usability that will make you think about it, not just devour gidelines. After you read it, you can search Jakob Nielsen's bibliography for specific techniques about usability, then, if you want more info, you can search it for actual gidelines.

By the way, Nielsen has a site where he archives some very nice articles for free. It is focused on web, not applications, but he goes out of his way to explain what generalizes.

Re:User interfaces

[Ardee]

Slightly dated but still extremely valuable is "Web Site Usability: A Designer's Guide" by User Interface Engineering (uie.com) -- headed by usability guru Jared Spool. The book is based on actual user tests, and there's lots of other valuable stuff on the web site. The company hosts (still?) an annual usability conference. FULL DISCLOSURE: I helped on this book while I worked for User Interface Engineering.

Re:User interfaces

[the 99th penguin]

Can I do any of this? Nope - I'm not a programmer or expert in GUI design, but I'm an extensive user of this GUI and I know what would make it easier to use. A way for the enduser to easily move, resize and re-align elements would be a huge step in user friendliness of GUIs.

Another rule pointed out by parent: don't rely on what you personally would like. Do extensive usability testing with potential users. Also, don't confuse what a small subset of users might want with how the majority of users will use it. Like others have said, know your target audience and use sensible default values. If it is possible to add customisation that won't get in the way and you can assign the time for this then go ahead, don't just make everything customisable just because you can.

Re:User interfaces

[SQLGuru]

Something similar to .NET Master Pages is a good way to ensure consistency........basically, every page should start from one of a small number of templates you use for your program. And each of those templates should really be based off of a single master template.

Layne

Re:User interfaces

[Anonymous Coward]

Older versions of this book are titled "Psychology of Everyday Things". The two versions are identical. This is the best user interfaces book ever written.

Re:User interfaces

[morgan_greywolf]

Well, I never read any of those books. I've just studied what I consider to be good user interface design over the years.

And my #6 is not exactly the same. You want to feel 'native' to the OS, but at the same time, you don't let that dictate your design. For example, GIMP for Windows adopts native-looking controls along with the common controls for opening files and whatnot, but it also doesn't try to look like 'Office Picture Manager' either. Not that the GIMP is a shining example of user-interface design...but I think it illustrates my point :)

Re:User interfaces

[morgan_greywolf]

Try this little program for doing DVD conversions. It'll convert any thing playable my mplayer into a DVD ISO file. It's a front-end and requires a few backend tools, but it is, IMHO, a fairly good example of the principles I outline in my post.

Re:User interfaces

[morgan_greywolf]

s/my/by

Re:User interfaces

[Anonymous Coward]

Coming from a user perspective, also add...

Context sensitivity: Don't have stuff cluttering the screen if the user can't use it at a given moment. (A couple 3D apps left unnamed are really bad that way, and one or two are really good.) You should break down features into groupings based on what functionality can work at a given time. (Let's say a program can both burn and play CDs, might be a good idea to have one tab with the playing features and another with the burning ones, etc.) Instead of graying out unusable menu items, hide them. (Less to drag the mouse over, making workflow faster. Nor is there the psychology of "Why can't I use this?" - out of sight out of mind, right?)

Hinting: Maybe allow disabling of hints for power-users, but hinting (or even status bar info) when hovering over features is good for newbs. Nothing drives some people more nutty than to have a program with tons of adjustable features, but no indication/explanation of what any of that stuff does or whether it should even be messed with. (VLC is rough in a few areas in regards to that.) Also be specific in the hints for settings, don't just say something like "buffer value" but rather "reserved RAM buffer, in KB" or something like that.

Consider your screen real-estate: Think about how an app's layout will relate to it's usage. Will it need or typically be run full-screen? Or is it something that's actually better to minimize and let run in the background? Should it ever grab focus? (Or be allowed to even?) Do some features need space in relation information to functionality, or can a tidy icon do the job?

Use limiters if needed but not arbitrarily: If only base-2 (32, 64, 128, etc.) values work for an entry box, maybe having a selection menu is better than entering a value. Or limit values to the extent of valid ranges. (Don't let the user crash things if possible.) But no arbitrary limits. Someone might have the CPU power or RAM to use a setting that would seem wild to the average user. But you could provide a "suggested range" in such cases that would suit the average user.

Other UI features (not just GUI): Use or allow hotkeys where it'd make sense. However don't rely on them 100%, there should be some way the user can access the item through menus until they learn the program better. Allow other input devices (joystick/gamepad, tablet, MIDI) if they can make sense for the software.

Re:User interfaces

[visualchaos]

also not related particularly to User Interfaces but you may try using Ideo Method Cards. These are an aid to designers in a variety of projects and they help to prioritize design elements and classify user requirements. the cards are divided into four categories Learn, Look, Ask, Try and each card outlines an exercise the designer may use to get closer to her design goals. some of them are quite fun as well. http://www.ideo.com/methodcards/MethodDeck/index.html

Re:User interfaces

[leilani]

Also by Norman: Emotional Design. Really good, and really good at tapping into user wants.

Why Software Sucks is another good one. Far more lighthearted, and really just a quick read though it hits home on a few issues.

Don't Make Me Think is amazing, though more web focused. Still has a lot of issues relevant regardless of the UI you are designing.

Tufte, mentioned below, has some great ideas on data representation, and warrants a look or three.

Universal Principles of Design is also wonderful, and gives dozens of excellent examples.

Designing for Interaction is another good one, and really gets into the interactive side of things.

Re:User interfaces

[billDCat]

I agree with most points, although 4) is a point of contention depending on who you ask, and actually in the Design of Everyday Things, a point is made that interfaces that present all options may actually be easier to use than those who hide functions behind modes. While the example they gave was a radio which is obviously different than a computer interface, it's still best to keep this in mind. The problem is that when one control does multiple things based on some mode, that's when modal errors take place. These errors are easy to make, and can have surprising results. The VI editor is a good example of modal issues, having an edit mode and a command mode. The difference between the two modes as is shown in the display is very subtle, but the difference in effect of doing something simple like pressing "dd" in one mode versus the other is significant. (I'm sure others can come up with far more destructive key sequences, I haven't used VI for a long time). For an example that's a bit more relevant, consider the palette controls in Photoshop. There are quite a few palettes that are available, not all of which are relevant at any particular time, however it is far easier to just have them open and laid out on the screen in a constant arrangement than it is to have them showing/hiding as needs or modes change.

I'm not saying that point 4) is wrong, I do agree with it. I'm just saying that minimal does not always mean easy, as it may take a lot more work to look for features that are hidden versus ones that are in front of you (look at Word's tabbed dialogues for a perfect example of how to make it hard to find features).

One more thing: To add one book to the pile of recommendations, I would suggest Jef Raskin's "The Humane Interface". Very good reading, and a very relevant point is "the user's data is sacred". Make sure that the user has a way out of what they are doing at all times, and ensure that when something goes wrong, any data they entered (but perhaps not "submitted" or acted upon) does not get lost.

Re:User interfaces

[JustWorx]

"I've always hated writing user interfaces, and graphical user interfaces in particular."

In that case why bother? Leave it to one of the many people who have a clue and give a damn.

If your job is putting pixels in front of people then you should be executing a design process that leads to a user interface - not spraying pixels onto the application as an afterthought.

You will find the most famous authors on the topic listed at the Userati site. However if you want to get a feel for the topic, go read Joel on Software's Dickensian account of his days in the bread factory - and remember thats the user experience you're condemning your users to if you dont care enough about the subject.

Re:User interfaces

[bendodge]

I did try that, but I couldn't figure out how to get a menu or chapters working. I am now using QDVDAuthor and am fairly pleased. It was crashing horrible before, but today's updated package seems to work much better.

And yes, it does have the format stuff automated.

Re:User interfaces

[Impy the Impiuos Imp]

I heartily concur on Inmates. My office has microwaves from GE that are Microwave Oven + computer = computer. Spacemaker Sensor II or something.

If you take your food out (i.e. open the door), then close the door, but still have some seconds left on the timer, it'll continue to beep every 30s indefinitely. Irritating.

If you open the door (thus pausing the timer), then close it with time still left, then press the +30s button, instead of adding 30s to the remaining time and starting again, it beeps and tells you error. You must press clear and re-enter the time (typically pressing +30s several times.)

My home microwave, by a different company, has none of these issues, and behaves intuitively.

Re:User interfaces

[jma05]

I recommend all of Norman's lay literature. He is a Cognitive Psychologist who can write well for non-technical audience. This brings up another point. HCI should ideally be always grounded in Cognitive Psychology. It should simply be the application of the theories of cognition to tool interfaces. The problem is that we don't understand human cognition well enough to create structured and comprehensive rule sets of how interfaces need to be. So HCI is still a bit of an art. Nevertheless, there are some common sense guidelines and evaluation is king.

Reading about cognitive psychology opens you up to the bigger picture than what most HCI books can deal with. Unfortunately, cognitive psychology is not the kind of material that the techies like to read, the programming kind anyway.

Re:User interfaces

[steve weiss]

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? Reading the questions posted, I'd recommend becoming familiar with the broader principles that inform nearly any sort of design; then narrow your reading and research to specific GUI-oriented design. Developing a healthy sense and understanding for what makes an effective user experience is important to any sort of consumer design work (and effective UI design definitely is about understanding your consumer/target audience); "usability" as a discipline has yielded to the larger field of Experience Design (XD) as a key area of study for GUI-designers. Let's start from the 10,000-foot view: Books I'd recommend for your conceptual skills are: --Bill Buxton's *Sketching User Experiences: Getting the design right and the right design*. Bill's background at Xerox PARC and later at SGI/Alias|Wavefront (creators of the Maya 3D CGI software, among others) have made him a pretty revered figure in the industry. This book's a terrific primer on the process of thinking about design. --The upcoming O'Reilly release, written by Adaptive Path, *Subject To Change: Creating Great Products & Services for an Uncertain World*. What's the distinction between product and service? Adaptive Path--the outfit from which came Jesse James Garrett's seminal white paper on Ajax three years ago--started thinking about this as they examined the success of the iTunes and iPod experience; the book grew from there. Moving down to 5,000 feet: For best-practices from the usability perspective (hey, an easy-to-use site usually has a well-designed GUI), it's hard to beat the two canonical books: --Steve Krug's *Don't Make Me Think!* (now in its second edition) --Jakob Nielsen's *Designing Web Usability* Both books arrived as website usability emerged as the successor to the David Siegel School of "third generation web design" in the late 90's. Nielsen codified usability best practices through a research-intensive method, and Krug made usability accessible for the creatives who thought Nielsen a bit pedantic. Solid, foundational material that hasn't needed radical revising in nearly 10 years. Ground-level: Here's where you and/or your team go to work, and I heartily recommend you check out another O'Reilly title, *Designing Interfaces: Patterns for Effective Interaction Design*, by Jenifer Tidwell. There are several solid tutorials out there on in-the-trenches GUI design, but I've still seen nothing as effective as this one. Hoping this helps, --Steve Weiss Executive Editor O'Reilly Media Links: http://www.billbuxton.com/ http://adaptivepath.com/ http://www.useit.com/ http://www.sensible.com/ http://jtidwell.net/

Re:User interfaces

[localman]

If I had mod points today, I'd mod you up. But as I don't, I'll just parrot you: "Don't Make Me Think" is a great book on UI.

Re:User interfaces

[tarpy]

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

Actually, I'd say this: HCI is a discipline, and if you are unsure how to design an interface, talk to someone who is trained in UX/UI design.

Don't think reading one (or ten) book will suddenly make you able to design a good interface...it won't, learning how to correctly display information, actions, state, and any of another 100 considerations takes a lot of study, a lot of knowledge of your audience, and natural ability.

Just like I found out this past weekend with my (mis)adventures with under-the-sink plumbing, reading a HOWTO and printing out instructions from a website won't suddenly turn you into a competent plumber. Call the expert.
 

Re:User interfaces

[MrKaos]

So you're saying a good GUI would just have a window to type commands in ?

That's so korny, who would shell out for that? I mean for a real user interface you'd have to bash the commands into it so the computer actually gets the message.

maybe we could call it punsh!

Re:User interfaces

[morgan_greywolf]

Yeah, DeVeDe doesn't do menus automatically, but you can do it yourself with other applications. The last time I tried QDVDAuthor, it did the same thing you're saying -- crashed horribly. I haven't tried the latest updates yet because my overall impression of the program was that it was still quite immature. *sigh* Such is the nature of open source -- it usually takes a while before you have a nice, stable program unless it does something very, very simple.

Re:User interfaces

[evc]

Good design is good design whether it's on the screen or on the page. Two books I cherish are "The Visual Display of Quantitative Information" and "Envisioning Information" by Edward Tufte who is absolutely brilliant on all things graphic. I recommend them highly. See Tufte's website: edwardtufteDOTcom for purchasing info.

Re:User interfaces

[dktutor]

Norman is very good. So are the books written by or edited by Moggridge and Buxton.

Re:User interfaces

[Anonymous Coward]

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

The obvious conclusion is that GP is one of those peculiar idiots that, even when they are right, thinks everyone else must have it wrong.

While I'm here: a few things I have noticed in commercial GUIs:

1. Quit exposing your goddamn implementation, you morons. I don't ever want to see a label reading V_NAME, or any other equally meaningless thing from your database.

2. Quit with the funny colors. You can be as inventive as you want when you make your own OS and can set the standard. But red buttons on electric blue backgrounds in your Windows app are not allowed. I don't care how boring you think the default is. You're not fixing it; you're just setting your makeup gun to "whore".

3. No, you may not do that either. I'm glad you listened to #2, but you may not invent your own toolkit that resembles nothing else under the sun (I'm looking at you, MOTU). Please no: bizarre color schemes that make all the windows blur together, strange new widgets like sliding trays, idiosyncratic window management, or rows of cryptic title bar buttons that don't even use standard symbols.

4. Kudos to you for using regular widgets. You're halfway there. But try using them right next time. Tree lists are actually not meant to be used to navigate your interface. Don't make a tree unless you have something to put in the tree, see? Menus are not supposed to act like buttons. I don't want to see "Quit" floating in my menu bar, because (a) the menu bar is for menus and (b) there's already a button for that. It's up there in the left. Do you see it?

Re:User interfaces

[dstar]

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. WRONG! Wrong, wrong, wrongity WRONG .

Yes, you do need to make every friggin' thing customizable. Hide it behind an 'advanced options' button if you must, or put it in a config file, but make it customizable.

You don't know what I'd like best -- I'll guarantee that, because the things that make an interface usable for me make it unusable for others.

I dropped Gnome when Gnome removed all the config options I used to use. No, they don't know what I want better than I do, and neither do you.

Re:User interfaces

[bigpurpledick]

Test it on your wife

Re:User interfaces

[Hognoxious]

Or perhaps an image that you stare at while meditating and the computer reads your mind? Sounds like he's talking a load of woo-woo postmodern claptrap to me.

Re:User interfaces

[Flambergius]

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.

I have an addendum to this one: have a mechanism for power users to access all the functionality of your application. This should not to be part of the main GUI, nor does it need to a GUI at all. This way you don't have two important design goals, usability and expressiveness, competing with each other (well, not as much anyways). A nice architecture for this is have a intermediate, highly expressive and scriptable, command line interface and use that interface as the back-end for the GUI that most people will see.

Re:User interfaces

[randalny]

I'm surprised that no one has mentioned "Don't Make Me Think!", by Steven Krug. It is specifically about computer and web interfaces.

Re:User interfaces

[jonbryce]

Gimp is certainly not a shining example of user-interface design. There is a reason why Adobe is still the market leader, and I don't think it is the feature list.

Re:User interfaces

[deano700]

Further to Layne's comment about knowing your audience, consider the usage frequency. For example, a user who comes in four times a year to add a new account to the system has a very different set of needs to the person who adds new accounts all day every day. The features which aid the infrequent user are likely to drive the frequent user crazy, just as the brevity and data-entry focus for the frequent user is likely to leave the infrequent user baffled.

about face ..... alan cooper

[the_wesman]

get this one

Re:about face ..... alan cooper

[Burnhard]

Well, a quick peek at the reviews, 1 of 3 says:

At every chapter in this book I thought, "Well this book's been worthless so far, but I think it gets better in the next chapter." I thought that until the last (26th) chapter, which was actually half-decent. I've never been so disappointed in a book. Any designer with the slightest bit of experience will learn nothing from this book. Nearly every piece of advice is trite ("Design principle: Use noneditable controls for output-only text"). There's very little depth or thinking beyond the completely obvious. You will learn more from any other book (on any topic) than from this book. If you've already bought it, you should skip to the chapters with non-zero value. I recommend chapter 5 (personas), chapter 16 (undo), chapter 17 (save), and chapter 26 (misc). The section on perpetual intermediates is good too. I finished the book 10 minutes ago after a very tedious three months. I can finally put it on the shelf and never look at it again. Having some experience of reading UI design books, this is fairly typical in my experience. There is no "catch all" guide to designing UI experiences, because the principles you apply will depend on the application, the ergonomics and the libraries you are using, alongside the motivation of the user to get to know your particular method of interaction. My only suggestion would be to prototype, see what works and what doesn't and to never assume because "it's good for you, it's good".

Re:about face ..... alan cooper

[Anonymous Coward]

You peeked too quickly. There were 7 reviews. One was the one you quoted. Another gave it 3 stars but said the book itself was worth 5 stars but deducted 2 for the quality of the printing. The remaining reviews gave it 5 stars.

Personally I think he made a lot of good points in the book, and I also appreciated the energy with which he wrote. However, I can't claim to be well read in the field of GUI design.

Re:about face ..... alan cooper

[jeillah]

My only suggestion would be to prototype, see what works and what doesn't and to never assume because "it's good for you, it's good".

Although a good start, books and academic discussions on this subject are mostly theory or one persons experience with a certain user base. What it comes down to is making it work for your user. What's good for one group may be gibberish to another. Also no matter how great you think your design is, if your client doesn't like it, it's worthless. Prototyping gets the interface in front of the target user before too much effort has been expended on the project. Of course you have to make sure you are showing the prototype to the actual user, not just some management type who may have no clue as to what a user will actually want.

Re:about face ..... alan cooper

[Tim Browse]

Nearly every piece of advice is trite ("Design principle: Use noneditable controls for output-only text"). There's very little depth or thinking beyond the completely obvious. You will learn more from any other book (on any topic) than from this book.

And yet I suspect that from where we're sitting, each one of us could throw a rock and hit half a dozen pieces of software that fail to follow even that basic rule.

Part of the purpose of textbooks is codify good practices. They're not there to assume you know everything. 'Code Complete' would be a short book if McConnell had assumed you knew everything already.

Usage-Centered Design

[Anonymous Coward]

I am a big fan of Constantine and Lockwood's "Software For Use". Usage-centered design seems more practical and pertinent than user-centered design. There are some interesting articles and resources at their website, foruse.com.

Depends

[damusicman]

A lot of factors can determine how the GUI should be created... Whether it is for an individual program, or for an entire operating system is a factor. It should combine form and functionality. Two ends of the spectrum is Plan 9 from Bell Labs's Rio GUI which if highly functional, but is lacking in form or styling, and Windows Vista's Aero, which although it does look nice, is pretty much useless...

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

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:Depends

[Anonymous Coward]

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

Okay, I grew up on a farm ... and pushing down on the pig's snout is exactly how we made the bread go down.

Re:Depends

[Anonymous Coward]

Er, why would using a pig snouts as the lever on a toast *not* be intuitive?

Re:Depends

[IsItWashable]

Agreed - requirements specs and functional specs are often written by business analysts, with no reference to the end users. It's absolutely vital to involve users before the requirements phase finishes, and the design work starts. And, of course, those same users can be involved in all the testing phases, but particularly User Acceptance Testing (UAT). If what you implement sucks, you may all get a pat on the back, but will have utterly failed to fulfill the business need.

Re:Depends

[obijuanvaldez]

I'm not sure I entirely agree. Form or attractiveness in design should be neither trivial nor an afterthought. One of the design principles companies like Apple leverage quite often is the Aesthetic-Usability effect. It states that users will find that a more attractive design more usable in spite of whether it actually is or not. I don't mean to draw out extensive commentary on Apple but a good example might be iPods and iPhones. The inability of the owner to easily change the battery could be viewed as a significant detriment to usability in terms of functionality, i.e. form over function. However, the resulting attractiveness of the sleek design mitigates this concern for many, if not most, users and may even be considered by some as a false positive. Some might cite "at least the battery never falls out" or "the battery is do good that it doesn't need replacing" even though a better functional design would incorporate a superior battery that doesn't slip but can be replaced by the user.

Further, to speak to the article at hand, my favorite design book and the one from which I drew this principle is Universal Principles of Design. It details 100 principles, each on two pages, one a text description and the other a graphic illustrating the principle. Another interesting example is that users find applications that use desaturated colors to be more user friendly and associate saturated colors with being more professional.

Re:Depends

[Quiet_Desperation]

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.

Not really. I would *totally* buy that toaster. :)

Re:Depends

[The_reformant]

If your user needs to RTFM, you have failed in your attempt to design well.

Not a linux fan then?

Re:Depends

[Anonymous Coward]

"Form follows function" is one of the main tenants of good design. Does it pay rent? Can you evict it? If not, it's more likely a tenet.

Re:Depends

[Anonymous Coward]

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.

You seem confused. If you believe that "form follows function", why are you making a toaster-pig? Do you think your users have experience with many pigs that can make toast?

I think you'd do better to throw out the silly aphorisms and just try putting something in front of users. If your pig-toaster users can all figure out the snout-lever, who cares if a 19th century skyscraper architect approves?

Re:Depends

[pigwin32]

Also, providing consistent behaviour, correct capitalisation and spelling will give the user confidence they're using a professional tool and not something hastily cobbled together by a tool.

Re:Depends

[Anonymous Coward]

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

very true!! everyone knows you should yank its tail to make the bread go down

Re:Depends

[sm62704]

Well, if your only market for your piggley toaster is hog farmers* than it would be a good design.

Er, you fed your pigs BREAD? How did they taste? A friend of mine was raising a few pigs, he fed then 1/2 hog feed and 1/2 ice cream mix (he knew someone who got outdated ice cream mix for free from his employer). That was the best tasting pork I ever ate!

Pity the price of hog feed went up so much he stopped raising them.

*out west they'd call them "hog ranchers" I think.

Re:Depends

[sm62704]

If it were patently obvious that it was a lever then it would be intuitive. But if the thing actually looked like a pig, with no visible slots or gaps nobody would know it was even a toaster, and if they were told it was a toaster they'd have no idea how it would be operated.

Re:Depends

[sm62704]

I agree 100%, except I'm not sure that not having the battery be replaceable is actually bad design in the case of the iPod. You have to think primarily of your target audience, and most likely the target audience consisted mostly of people who upgrade every coupld of years anyway. Plus, there's the cost of the battery itself in relation to the cost of the item. If for example you hae a $50 battery running a $75 device, having a replaceable battery wouldn't make any sense.

But even if it is a design flaw, no design is perfect.

Re:Depends

[sm62704]

Actually you're going to need to RTFM with any OS. But one could concievably install and run Mandriva/KDE (or likely Ubantu, which I've read about but not yet used) without a manual.

You wouldn't have been able to use a car without a manual when they were first produced.

And contrary to conventional wisdom, a computer newbie finds Windows harder to use than Linex; at least the computer newbies I've installed dual boot on.

Re:Depends

[sm62704]

My dictionary didn't pay its rent so I evicted it.

Re:Depends

[sm62704]

That was exactly my point. A toaster should be a toaster.

Re:Depends

[Hognoxious]

Me too, but then I'm biased.

Re:Depends

[Amouth]

meaning.. don't make your tool/app look like my posts :)

Rule #1: Don't make the user look stupid

[PaleoTek]

Alan Cooper's About Face is a good place to start. I read Version 1.0 back in the day, and am reading the 3rd Edition now. Alas, he's gotten a bit more tedious in the interval, but is still smart, funny, and committed to better GUIs.

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

Re:HCI

[Hognoxious]

This got modded informative, implying that people with mod points thought there'd be people reading a tech site who didn't know that. Sheesh.

Sharp et al: Interaction Design

[Anonymous Coward]

I just bought this:
Sharp, Rogers, Preece. Interaction Design: Beyond Human-Computer Interaction, 2nd edition

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

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

[PrescriptionWarning]

exactly, just try to think about all the OSes and Applications you've ever used, and try to think about what you liked and didn't like. Then add in a little of your own flavor, try it out, and if you don't like it, redo it!

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

[UbuntuDupe]

User interface design really interests me. I understand that other people don't share this passion. Still, I think simple rules can provide a good guide, even if you have no clue. Here is rule I would propose instead of (or in addition to) that one:

Have ONE potential user try to use it as they would for its intended purpose. Then, eliminate the things that severely bother them until there are none. (Severe means things like, "Can't find a function after trying obvious ways of searching for it", takes a lot of effort to instruct it to do very common tasks, anythink irritating enough that they want to avoid using that part of the program.)

Believe it or not, that will put you ahead of about 50% of user interfaces out there.

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

[kaian]

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. That's a strange couple of sentences to string together...

I've found that really understanding the situation(s) the program will be used in is fundamental. Good user interfaces just fit with the situation, and feels second nature. Too many toss inn all the info and controls that they can into each window, where a better understanding of what the user need in each scenario would allow to remove most of it alltogether.

Also, consistency is king. So do adhere to good recognisible style.

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

[sm62704]

Doesn't matter, neither does anyone else

Wrong. Google knows good design. Lots of people know good design. Unfortunately, way too many people share your apathy towards the user.

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

[El_Muerte_TDS]

Most people throw things at the wall and see what sticks. If you keep things simple more will stick.

Google used to have a good design. But their search result pages have become worse.
The first line of google is:
"Web Images Maps News Video Gmail more"
And I am authenticated with Google, they know I don't have a Gmail account. They know I pretty much never use Maps and News. They know I use Groups and Scholar more regular than the 3 previously mentioned services. Then why don't they list those options. Also Google keeps insisting I use the Dutch version, even though my browser only says that I only accept English.
I also have a couple of problems with the page design of Scholar, Video, and Groups.

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

[Evil Closet Monkey]

Having this general disrespect and uncaring attitude towards the user is why so many user interfaces are an absolute nightmare to use. Looking at your target operating system and the standards defined for common user interface practices is very important, but to simply believe that a good user interface is spawned by simply making it look like the target OS is naive at best... or criminal with the number of horrific interfaces out there.

To use your example, I'll strike at the heart of Slashdot culture -- GNOME or KDE, both absolute cesspools of user interface design. Plenty of applications *look* like they belong there, but are so absolutely unusable that it doesn't matter if it is the most beautiful thing you've ever seen -- you still can't use the program to accomplish what you need. This is part to do with a simply lack of resources to within many open source projects to do proper interface design, but mostly because there is a mindset among many programmers that they somehow instinctively know how to create a good user interface. Because you sit in front of the computer all day does not mean you know what is best.

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

[dubl-u]

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 there are 20 important rules, that might be one of them. But if you're going to pick exactly one, it has to be:

Test all your GUI choices with real users and revise based on those observations.

The essence of any good design is that it works for your chosen audience. The only way you will know if your design works is to have audience members try it. All the other design rules -- including yours -- are derived from lessons learned in that feedback loop.

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

[forkazoo]

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.

For many apps, looking like the OS is a very valid design goal. There are, however, a great many applications that value consistency across platforms much more than they value fitting into the platform. Lightwave and Shake leap to mind for me personally, though a lot of high end graphics programs use the same philosophy. Both apps have supported Mac OS X, Irix, and Windows. Between them they have also supported Solaris and Linux and more. Neither tries to look particularly like the host OS so that you can move a Shake artist from Irix to Mac OS X without any retraining - they feel right at home. It's a valid design goal, if it suits your user base.

Shake also has a completely unique file picker dialog which is uniquely suited to dealing easily with file sequences, just as a nother example.

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

[sm62704]

Nothing ever done by a human will be perfect. very good, better than anyone else perhaps, but not perfect.

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

[tknd]

follow the same design principles as the target OS and applications with similar functionality as yours

And what if the principles in the target OS are actually incredibly wrong?

One example is "double click". In most environments today, you have to "double click" and icon but single click everything else. The result? People start double-clicking things that look like icons on the internet even though they're supposed to single click them.

Its a catch 22. You can either choose to be consistent and follow the same mistakes as everyone has in the past or you can try to fix the problem at the cost of not being consistent and have people double click things they shouldn't. Either way you lose: some people suck at double clicking and will hate you for it while in the opposite direction people will double click everything.

Another more personal example is a game I used to play. I thought the UI was horrible. It did not scale with the screen resolution so the elements looked incredibly tiny on a very high resolution. It was obvious the UI was made to be "pretty" rather that useful (because games are supposed to be pretty right?). The defaults focused on moving the controls to the outer edges of the screen but during actual game play your mouse is usually on the center of the screen as well as your eyes--so switching your view off the center of the screen to your life bar that was on the bottom right corner could easily get you killed. The UI elements, when left open, would cover up the screen with unnecessary artwork, so when an enemy was coming from the side you would not see them until they got past the UI's windows. The life bar was ordered in a non-optimal fashion such that your enemy's life bar was far away from yours--so in the heat of a battle it was not clear exactly how you compared to your enemy without your own visual guestimation (which could be wildly off because you rarely had time to stare at your lifebar). And the list goes on and on.

Nobody dared to change the UI scheme for this game. Everyone instead just made new pretty UIs with even more graphics to hide your field of vision. People, not aware that the UI was actually not very usable, didn't care because pretty graphics sell. Yet the UI played an incredibly important role in this game. The battles were insanely fast. Decisions had to be made in split seconds. Every 10th of a second taken away from the player is a lost 10th second against the player in what might amount to a 30 second fight with one loser and one winner.

So I set out an ripped the UI to shreds and went against many consistencies of the old and flawed UIs. I didn't care that I had to relearn how to read my UI. If it meant I ultimately had what would amount to a 5 second advantage in decision making time or getting information to my head a 10th of a second faster than my enemy, it was well worth it because in a 30 second fight, 5 seconds is 16% of the time. I made the life bars nearly double the size and re-ordered them so that my lifebar and my enemy's were flushing on top of each other--it made is dead clear whether I had more life or my enemy had more. I got rid of a majority of the fancy graphics and backgrounds and either made them transparent or not show up at all--so even when you had a window on the edge you could still see what was behind it. In my screenshots I moved the most important UI elements (the ones that give you information) to the center of the screen rather than the corners--now I didn't have to keep flipping my eyes around the screen to get information, instead it was all in one place.

Then I decided to let everyone else try it if they so chose. I was very quiet about releasing the UI to the public. I made a simple thread on the forum and didn't make any effort to keep it on the front page. I didn't care, the fewer people that knew about it the better off I was. But then it tipped and caught on like wild-fire. Before I knew it I was seeing nearly a third of all people I met in the game using

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

[Zey]

Given the terribly cluttered interface is just one of the things driving people away from Vista, you may or may not want to ignore those Vista Guidelines ;-).

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

[SQLGuru]

Vista is fine, but they sure did screw up Office 2007......I can't find anything easily....

Of course, I'm in the camp of "give me a remote with 84 buttons and I'll figure out which one I want" instead of the camp of "give me a remote with 10 buttons and make them only do what I need"......I want the power, not the protection.

Layne

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

[peragrin]

Actually MSFt tends to hide things with Poor GUI design, and frequently renames commonly used items. They are getting better however.

Something I do find interesting Is Office 2007 ribbon. A new and innovate take. if it works in the long term is something else, but at least they tried something else.

I just have to wait for MSFT to port it to the Mac.

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

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

[JacobO]

Vista is fine, but they sure did screw up Office 2007......I can't find anything easily....

I am with you on this one. But I'm an Office user of many, many years.

I was recently speaking with a relative who had been trying to use a previous version off MS Office, and some other suite (perhaps Corel?) and he indicated that Word 2007 was "so easy". Prior to retirement he had a secretary to worry about word processors.

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

[Richard_at_work]

I disagree - sure, it took me a day or so of being fairly lost when I switched from Office 2K3 to 2K7, but after settling down into it, I can honestly say that I most certainly prefer the 2K7 interface without a doubt. There was nothing especially wrong with the 2K3 interface, but the 2K7 one just feels so much easier to use after that initial learning curve.

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

[Marcion]

Interesting that the images in that document are in .png format.

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

[Anonymous Coward]

I disagree about Office 2007. For many people that have been using Office for years, the change can be a bit confusing but that's overcome rather quickly. For instance, a buddy of mine has been a supervisor in a warehouse for the past several years and doesn't have a lot of computer experience and has used Office for very basic tasks. Recently he's decided to go back to college to get his degree so he bought a laptop that came with Office 2007. Since using it, he's been raving about all the stuff it can do. I explained to him that the previous versions actually had most of that functionality and he said that he had no idea Office could do all of that. Now this is just one instance, but for him the ribbon did exactly what it's supposed to - make it easier to find and use it's functionality.

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

[Tom]

I, on the contrary, knock their interface every opportunity I get. It's horrible, and getting worse with every new version.

One example is that "hide the not-so-often-used options from a menu" terror. Whoever came up with that should be shot and buried next to the inventor of the "Start" menu. It drives both power-users and newbies mad, provides no mentionable savings and causes additional trouble whenever you do want those functions.

And that's just one example. Every UI "innovation" from MS is an abomination, and that crap is driving people away from windos, Vista or otherwise - namely everyone who's ever used something else. Wanna convert someone to Mac? Borrow them a MacBook for a weekend. The UI alone, compare to what they're used to from windos, convinced almost everyone who's spent as much as 10 minutes on my Mac.

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

[viniestra]

Rule 12: Reserve time for "fit and finish"!
To deliver high-quality fit and finish, schedule time to attend to UI details, including visual clean-up at the pixel level and layout corrections (alignment, spacing). Visual "fit and finish" is as important as standard bug fixing and other types of quality control.
Perception is reality, and if your customers don't experience quality in your product throughout, they may conclude there is lack of quality everywhere. A visual bug seen by all your customers might do more damage to your program's reputation than a rarely occurring crashing bug.

Do you agree? I don't.

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

[iwein]

... just to counter those 3 people who respond immediately with "But I did!"
Hah, so you get to say something is great and we can't say you're wrong? You must be new here.
I've never used it, but exactly everybody who I heard talking about it hated the Vista look and feel. The teletubby design of XP never got high marks either, so maybe I just know only people who are generally negative about UI's.

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

[master_p]

I find the Vista UI confusing. It's very difficult to say what is clickable and what is not. There is no clear separation of different functional areas. Window frames have confusing different decorations.

I don't care at all about DRM, and it has not been a problem for me for the little I have used Vista.

I have no security issues, since I don't visit 'weird' sites or run 'weird' programs.

Stability is top-notch; the last stability problems I had date back to using Windows ME.

I don't care at all about anti-competitive practices of Microsoft; they are #1 in Office applications, and their O/S is very good.

Win32 sucks as an API, but thank God some good people in Norwegia have taken it upon themselves to fix the problem by making the best API possible (yeah, Trolltech).

I think your conclusions are far away from what average Joe thinks.

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

[dstar]

Have you actually looked at the Start->Programs menu on Vista?

If you think that's good design, you're an idiot.

art of interactive design

[jrexilius]

by chris crawford..

its great.

google books

Re:art of interactive design

[kabrakan]

Mark the parent post as an example of good UI design. Concepts are separate with enough space between them not to confuse the eyes. Capital letters are not used so as to not confuse the reader. A general, downward flowing degree of importance is employed. A+.

Design of everyday things

[mattpalmer1086]

It's not aimed at GUI design in particular, but I'd strongly recommend "The Design of Everyday Things" by Donald Norman.

Also, "The Inmates are Running the Asylum (why high tech products drive us crazy)" by Alan Cooper is quite good (although about a third of the book is just a pitch for the author's consultancy).

Mac and non-Mac

[Zey]

Be prepared to use at least two design styles. There's the Mac way (and you'll find a lot of good guidelines in their Human Interface Guidelines for that), but, follow those on Windows and X11 and your applications will look rather strange and not at all platform native; even when using native UI controls.

I don't have any suggestions for books on good design, but, here's a classic site which covers some bad design mistakes: The User Interface Hall of Shame. The examples are fairly dated now, but, the principles remain true.

Re:Mac and non-Mac

[UbuntuDupe]

IMHO, it's a myth that Mac's have an optimal interface. I recently got a MacBook, and while I'm generally satisfied with it, there is a LOT Of irritating stuff.

-email client: Why the hell are the subject lines all darkened? Nothing in help about this. Ah, must be a "mail rule". Oh, there it is, I'll just turn it off. Wait, that option is all the way at the bottom of the screen, on top of the program launch icons. *click* No, I didn't want to load that program. Okay, I'll scroll down so that the button is in the middle screen and I can click it without launching another app. Wait, no scroll option? ****! Okay, how do I turn the lower app launch bar off? *search search search* Okay, there we go. Wait, they're still darkened. Oh, okay, I've got to tell it to apply to all. [finds option somewhere] Now, how do I get the bottom bar to come back...

-iMovie: I want to export some video captures from an image I made. Let's see, right click on the point in the video I want to use, where's the export-frame option? Nowhere. Okay, help search: "video capture". Nothing. Okay, "frame". Ahah, 8th option, how to make a frame into a clip. Closest option. I go to the frame I want and then ctrl-click it. Hm, OH, wait, I can right-click too! Why hide this option from me? Oh yes, I forgot: people who prefer using one hand (or are disabled losers) need not apply.

I grab the frame, and it makes me put it as a non-moving clip somewhere in the video. So, I do a few of these from different pictures. Now where are they? Okay, I get to dig through finder again. Now, let me move them all to one folder for easy upload. Wait, the second one I moved (and the rest) have the same name as the first. Okay, so let me choose a different name on moving it. I can't? Okay, fine, I'll rename them all, THEN move them.

-I took a photo of myself in PhotoBooth. Now I want to crop it and upload it. Okay, click on iPhoto. Crop image. Great, now I have it in an album. But where's the picture file? Um, show-in-Finder option? Nope. Save cropped picture somewhere? Nope. I have to go deep into the directory, photos->iphoto library->various weird folder -> copy it to a more useful place, then upload.

-Now I want to make the cropped image my ichat buddy icon. Drag to chat pic? No, that would imply interoperability. Export to ichat? No. I have to go to the buddy icon and then load it from the useful place I moved it to.

Listen

[C10H14N2]

What are the issues in designing an interface that is clean, easy to understand, and easy to use?
Listening to your users enough.

What are things to be avoided?
Listening to your users too much.

Really, the whole thing boils down to balancing the above and, unfortunately, it's a very subjective thing. /Appropriately, my captcha was "miseries."

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:I would suggest...

[Cyberskin]

I read the first edition of GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers and found it to be brilliant. It articulated many of the common sense principals I had honed as a web interface developer. As a Symbolic Systems major from Stanford I studied the psychological, physiological and neurological basis of human cognition and human computer interaction and found the book to be solidly based on many of those principals (attention span studies, visual catagorization, mental models, etc). I found it highly applicable to web design and developement, but I think the design principals are generalizable to any human computer interface really. If you are a beginner, or an expert I would still recommend this book. That being said I haven't read the second edition yet, but if you give any credence to Amazon reviews its supposed to be even better.

-Hyperic Web Monkey
http://www.hyperic.com

Re:I would suggest...

[Anonymous Coward]

You went to Stanford but you don't know the difference between 'principals' and 'principles'? Bullfuckingshit.

Re:I would suggest...

[Cyberskin]

Sure I know the difference. This is just a case of homophonic word substitution, whereas the psychological principle behind your comment...well...you are just bein an ass.

HIG Guidelines

[Anonymous Coward]

Even if you don't develop for Mac, GNOME or KDE, these documents have a fairly good set of guidelines, some of them are specific to the uniformity of the "experience" however. I would imagine Microsoft having atleast some type of guidelines for interface design in MSDN.

http://library.gnome.org/devel/hig-book/stable/
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html
http://usability.kde.org/hig/current/

Anything by Robin Williams

[Anonymous Coward]

I have the Non-Designer's Web Book that she wrote and it is awesome. She's written a lot of books that are UI related so you should be able to find something suitable.

Re:Anything by Robin Williams

[mr_mischief]

Amen. The first thing I did when I got to the replies for this question, before reading anything, was to search for "Robin Williams" in my browser's search box to make sure someone had mentioned her books. There's one typography specifically. There's one about general design principles.

Here's a list of her earlier books in the "Non-Designer's" series and more. She also has a list of useful resources for designers which includes her stuff and other stuff at one of her sites.

Re:Anything by Robin Williams

[acklenx]

I'll second that. The Non-Designer's Design Book (ISBN-10: 1566091594) is the book I read that makes _design_ a little less art and a little more science. Okay he doesn't really use science so much as he makes the "good" design choices seem less voodoo like and more like binary.

Designing Interfaces

[matt4077]

Tidwell: Designing Interfaces

Re:Designing Interfaces

[johannesg]

Agreed. Great book, taught me a lot about designing better interface. Although subjective, it has been noted by my colleagues that I do considerably better interfaces since reading it.

I'm no UI expert...

[Kjella]

...but I'd say most designs fail at one of these two things:
1. Split the elements into three categories:
a) Must set / vital parameters / things that can't have a default
b) Has a default, but users should change regularly
c) Nice to have - every other little setting

Make it very clear what the minimum effort is.
Show the second so users know they're there.
Hide the third behind an expander/button, for those that specificly look.

2. Group things logically by function

Those two things can be contradictory enough. I've met many UIs where either a) there's ten pages of configuration with one a-level option per page, or b) the advanced functions aren't logically ttached to the basic functions at all. If you can make an UI that cover those two well, I'd say you do better than 90% of the UIs out there.

Re:I'm no UI expert...

[anzev]

In reality, none of these are that important. You see, there's one thing everybody here failed to mention, and it's the fact that the thing using the USER INTERFACE is a human. As much as this is widely disputed at some points during the software development lifecycle, the fact remains that PEOPLE will be using this product. And you have to pay more attention to human psychology!

Be careful in choosing the right colors, know what a color means, and which feelings it induces to the user. There's an important difference in perception of even hard vs. oval edges. Know how users tend to use the program and try to solve their problem first. Then minimize things, see what you can automate, but not annoyingly smart -- like Word's Clippy. Then, make the thing look good. That's how you should design a good user interface. Never the other way around.

There's one more thing I'd like to point out. A lot of people here pointed out HCI as a good starting point. Well... It's nice to know the things already done on this, but If you have a radical new idea that you think can "shift the paradigm of user interfaces", don't just ignore it. Obviously don't just put anything in, do some testing, prototyping first, see if it fits the above, but don't just let it go, because it's not standard practice!

Re:I'm no UI expert...

[Kjella]

Be careful in choosing the right colors, know what a color means, and which feelings it induces to the user. There's an important difference in perception of even hard vs. oval edges. I don't know if you're being serious or not, but most of that is already decided by standard UI elements and theme, unless you're doing your entirely own thing which I hate. Try to be all smart and your application will look like a fish out of water unless you're really into making an art statement.

Know how users tend to use the program and try to solve their problem first. Then minimize things, see what you can automate, but not annoyingly smart -- like Word's Clippy. Annoyingly smart? Surely you're joking with me.

Then, make the thing look good. That's how you should design a good user interface. Never the other way around. Since I didn't say anything about making it look good, you can hardly claim I said otherwise. I think it's quite irrelevant, I've seen ugly and useful, pretty and useless - they're fairly unrelated if you ask me.

What I suggested was that you put the right functions in front of the user with the right focus and natural grouping. Whether you do buttons with square edges and puke colors or oval edges and pastelles, it normally doesn't matter unless you're rolling your completely own UI elements above and beyond theming with completely unexpected functionality. In which case you'd better be a genius or I'll have you shot (or at least look long and hard for an alternative).

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.

Re:Top ten list by HCI prof

[cerberusss]

testing your UI on real users

Oh wait -- testing the UI. On users. I see.

Re:Top ten list by HCI prof

[sadida_333]

While not directly about GUI design, I like John Maeda's The Laws of Simplicity. It is short enough to be read in one or two sittings but packed with ideas that make a lot of sense when presented to you in an organized manner.

He maintains a blog relating to the book concepts as well.

Re:Top ten list by HCI prof

[Rah'Dick]

I have read most of these books and fully agree. Alan Dix, however, has stated during a talk that I visited two years back that "Human-Computer Interaction" should actually be rewritten. I also recommend Steve Krug's "Don't Make Me Think", if you're a beginner. It doesn't go into great detail, tho.

Re:Top ten list by HCI prof

[anomalous cohort]

Also, consider reading Don't Make Me Think by Steve Krug.

Re:Top ten list by HCI prof

[fermion]

Even though he has gone corporate and is mostly Web Design now, I would add Jakob Nielsen to the list, in particular "Usability Engineering".

One thing that many UI people state is that the UI is supposed to be an interface that will make sense to the user, i.e. relate to how the user will work, and not, as most interfaces are, to simply expose the inner working of the program to the user. Most users to do care how the program works. They only care how they work. Web sites make this mistake by exposing company structure to the user instead of thinking of the user works.

I noticed this on Apple's telephone support the other day. I called in, and was prompted to choose the machine I was interested in. I was not interested in a machine, I was interested in returning a part. Once I understood that I had to choose a machine to get anywhere, I was ok, but to do that I had to abstract my own needs to the Apple organizational structure. The most difficult part of UI is abstracting company design to user needs, and no amount of testing will make that happen. The user does not often have the skill to state how the design in fundamentally wrong. The user can only say it is wrong. Of course, the user is no expert so saying the design is wrong may or may not make it so.

Re:Top ten list by HCI prof

[ednopantz]

My problem with Nielsen is that he tends to go completely jihad on some iron rule of design instead of appreciating when it is ok to break the rules. He claims to be sensitive to this, but it doesn't come out in his writing so well.

I would recommend the duck book since it provides a ton of examples of stuff you see every day: http://designinginterfaces.com/

Re:Top ten list by HCI prof

[Anonymous Coward]

The post was to recommend a GUI design book. We assume that this respect is from a novice, not from an expert who knows all the rules.

One problem out there is that we have armies of novice web designers who believe they are expert designers, typographer, color coordinators, and psychologists. They believe that are so brilliant, they don't have to follow the rules. Such arrogance mostly leads to bad things happening, mostly, A person, so to speak, must know his or her limitations.

I admit I don't refer much to Nielsen anymore. OTOH, I have not seen a better starting point, not even the Humane Interface, which is good but very high level. It is just like in coding, Composite Structured Design, Writing Solid Code, and The Practice of Programming all can be considered limiting, but they have excellent explanations of common practices.

When one is learning a practice, the first thing that must happen is to learn to the widely known rules that have been accepted practice. After those rules are learned and lived in for a while, then one goes off and breaks the rules. Breaking the rules all willy nilly does not make one a good practitioner, merely a clod. And gives us horribly designed sites like we see at universities, school districts, and other places that can't afford and manage competent web designers.

As far as the O'Reilly books are concerned, they are part of my library, mostly because I can so many of them at a huge discount, often off the remains rack. They have good editors, and simple language, and are a good reference. I, in fact, learned HTML from one of their first books. The publishing house is hardly comprehensive or rigorous enough, at least not anymore, to be used the starting point.

Re:Top ten list by HCI prof

[dfgumby]

I used the Shneiderman book in a UI class and found it pretty thorough. The main things I got from studying UI is how much you DON'T know the user. And no matter how much you want to blame them for screwing up, it is your fault as the user interface designer if the user doesn't understand how to use the system. You need to spend lots of time just watching users. As an excercise sit around watching people use a vending machine and try to document all the ways problems develop. Then think about how much more complex your own interface is. Another thing that came up in class was the use of paper prototypes. When mocking up a user interface a user is much more likely to critique something written down on paper than something they think you put a lot of time into (even though drawing the interface out on paper is probably more work than using a software tool). However, I would have to say I generally don't have the "problem" of people not asking me to change stuff.

on the web

[Uzik2]

http://jimjansen.tripod.com/academic/pubs/chi.html
It has references to paper works if you must kill trees to learn

Re:on the web

[Anonymous Coward]

I would also recommend:
http://www.joelonsoftware.com/uibook/fog0000000249.html

It is insightful and short... only useful as a starting point for thinking about these issues, of course, but worth a read.

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.

Re:The basics:

[sjaguar]

4. Don't get cute. Use standard controls that people recognize. In addition to using standard controls, have a consistant look. The application/webpage/whatever should be at least consistant with itself.

Re:The basics:

[Tsu Dho Nimh]

4. Don't get cute. Use standard controls that people recognize.

Same goes for icons ... make sure the icons are easy to distinguish among themselves, and if possible use ones wiht meanings that are already well-known. I remember one disastrous Linux app that had two identical-looking icons on one user dialog box, and no pop-up text to explain what they did. One closed out the whole app, losing all my work.

Development versus Design

[cbart387]

I've heard (and from my experiences I think is true) that people who are good at development are not necessarily the best for design, and vice versus. There's always exceptions, and I'm sure some on this site will say that they can do both well. If I was independently writing a software (for the general population) I'd want someone to do the UI, because my mind doesn't work that way.

Besides making UIs that look 'pretty' these are ideas that I've been pointed to in classes here and here. They are useful for both developers and designers of GUIs.

Programming as if People Mattered

[HellYeahAutomaton]

http://www.amazon.com/Programming-as-if-People-Mattered/dp/0691037639

Careful not to go down the road of the artsy fartsy web UI designers, as a lot of the other suggestions are.

Re:Programming as if People Mattered

[amper]

Excellent book! I second this recommendation.

Re:Programming As If People Mattered

[Hognoxious]

Humorous segways

I wasn't aware there was any other kind.

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.

Re:GUI design tips

[Anonymous Coward]

My biggest peeve is programs stealing the focus from other programs. If I load outlook, I know it'll take about five minutes to load, so I'll use another program in the mean time. While waiting for outlook to complete loading, it will steal the focus about three times. Just the tiniest bit annoying when half way through a password field on a webpage...

Re:GUI design tips

[Anonymous Coward]

Regarding color schemes and font selections... well your application needs to stick with the OS defaults for those.

I'm not saying that your application can't support color schemes and custom fonts and skins that make it look like some modern art got tossed on your monitor. I'm saying do not go jamming this stuff down the user's throat at the get go. Make your application so it can do that sort of thing for those who would like to do that if that is what you want to do. Then get a grip on yourself and turn all that crap off for the default installation.

The average user doesn't care about skins and custom colors and fonts to any great degree. If they do care at all about custom colors and fonts they probably went into the look and feel section of their OS settings and made some setting changes there to their colors and fonts. Disregarding their preferences to inflict your choices on them is simply rude.

Users who DO care about skins and custom colors and fonts are more than capable of locating your application's settings for these themselves and making whatever changes suit their fancy.

It's like a sandwich ...

[lysdexia]

I worked as a busboy my freshman year of college (`84). I was mopping vomit out of the bathroom. The Assistang Manager came in to have a leak. He said "I don't know anything about a roast beef sandwich, but I do know that if I ever made one, I'd slice it thin" (pause for dramatic eye contact) "and pile it high." He zipped, tucked his tie back between the third and fourth buttons on his shirt and left.

Thus I was enlightened.

Oh, and Jef Raskin's "Humane Interface" is still pretty good reading.

Re:It's like a sandwich ...

[drxenos]

You didn't mention whether or not he washed his hands.

Re:It's like a sandwich ...

[lysdexia]

The answer is in the question, Grasshopper.

Re:It's like a sandwich ...

[SQLGuru]

It was 84.......probably not.

Layne

Good GUI Design?

[flajann]

As one who has designed GUI for many years (pre-Web), I can say that good GUI design is not an easy thing to come by.

You have to look at and understand your audience intimately. Demographics matter, too. What works for 20-somethings might totally confuse 50-somethings.

And today, good GUI design is even made trickier by the expectations users have from using the best applications and web sites. If your application is very "MySpace"-like and is intended for that same audience, you'd better make sure it's a good match.

Also, gone are the days you can expect your audience to RTFM to use your application. It must be obvious from the first click of the button.

But to our credit as GUI designers, today's audience is much more sophisticated than those pre-Web. So, if you stick to certain measures, it's actually easier than it was before. And there are many tools to help you, too.

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.

JoS

[waterford0069]

User Interface Design for Programmers by Joel Spolsky.

test it with users.

[Racemaniac]

i've had a basic course on UI design, and one of the basic points was to test it with users, look at the results, and correct things you saw went wrong, and start over again...
basically you just make a mockup (or in the beginning even a simple paper prototype) and ask the test subjects to do certain things, and make use of think aloud (aks them to as much as possible say what they're thinking, doing, and thinking they're doing. a random/weird action may suddenly become clear when you realise your users are understanding certain things completely differently than you).
and besides that, look at other interfaces for similar purposes, it's useless to try and reinvent the wheel (depending on the application, ofcourse make sure you don't run into legal trouble for exactly copying something existing).

User Interface Design for Programmers

[micky_ray]

Joel Spolsky has written an online book called User Interface Design for Programmers that I find pretty good http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html/. There is also a longer print version that has more content, but I haven't had the chance to read it yet.

Mick

Oh dear...

[Anonymous Coward]

I hereby tag this "article" with ROFLDOYOUHAVENODISTANCETOANYTHING? and now I filling this post out with pointless lower-case blabber just to circumvent the lameness that is the "lameness filter" of Slashdot's not entirely brilliant comment interface. I have had no cups of coffee today, but two glasses of orange juice. One two. 2.

HCI Theory

[IndieKid]

The core text on my Human Computer Interaction course at University (College for you American folks) was this. It might be a bit long in the tooth now but it covers the general principles of how to design a good user interface and how to actually measure user interaction with an interface, as well as the theory (some psychology type stuff mixed with Computer Science) behind the principles.

It doesn't really cover web stuff if that's what you're after, but the most of the principles are largely the same. Having said that, I still refer back to this book from time-to-time even though I've worked exclusively with Web applications for the last three years.

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:Macintosh Human Interface Guidelines

[jacquesm]

better yet, go straight to the source and find out what Xerox was up to.

Re:Macintosh Human Interface Guidelines

[Anonymous Coward]

Apple's "Human Interface Guidelines: The Apple Desktop Interface". Addison-Wesley

ISBN 0-201-17753-6

Original poster, I bought it out of love, you seek it for knowledge. I respect that.

Thanks, amper, for bringing that up.

For the small-dicked wonder who mentioned Xerox, see appendix A for mentions of both Xerox AND SRI International BEFORE Xerox.

Some suggestions

[Registered Coward v2]

Donald Norman Design of Everyday Things (ISBN-13: 978-0385267748) He will get you thinking about the implications of your interface design; this classic may be hard to find but he has other books out as well. While his examples focus on mechanical objects the thought process and criticisms provide insights into how to think about the end user in your design and avoid become someone "Who won an award" for their design. Once you read teh book you'll get what I mean. http://www.jnd.org/

Bruce Tognazzini Tog on Interface (ISBN-13: 978-0201608427) A bit dated but the concepts and idaeas are what matters. He has a website as well as other books. http://www.asktog.com/

Finally, there are classics by Edwin Tufte you may want to checkout as well. He focuses on displaying information (mostly quantitative) in a manner to support understanding; and hates PowerPoint type presentations with a passion. Tufte has a website as well. http://www.edwardtufte.com/ His one day course ie excellant.

Re:What I like to do.

[somersault]

While I like Linux and can use a command line fine, I don't really see how the graphical control panel is a negative point in Windows (or Mac OS for that matter, which also has a good command line, being based on BSD and all..). A lot of the configuration options in Windows are hidden away in the registry rather than in plain text files. Yes, I prefer having easily accessible configuration files, but the fact is that Windows was designed to be used mainly through a graphical environment, while Linux is more flexible and is designed to be usable even without X server.

A notebook (pen & paper)

[ByOhTek]

A lot of people have different views on a UI. Some people think the Apple style is the end-all/be-all, and some don't. Some go for the style of Windows, some go to a completely different direction.

Look at a few apps with good UIs, write jot down what elements you like about them. See if you can find elements you don't and jot those down.
Next, go to some similar apps with bad UIs, write down what they did wrong and what they are missing, in your oppinion.

You should actually get a fairly good idea of how to make a decent UI from this. Now, take some of your UIs, really look at them, pretend they were written by someone else if you have to, and figure out "What is it missing, why don't I like it?"

Spolsky.

[MythMoth]

I particularly User Interface Design for Programmers by Joel Spolsky.

If you're designing web software, then read through the archives of Use It by Don Norman. I don't like his books - Designing Web Usability is the only paperback I've ever bought that had usability issues! But he's mostly on the ball.

Re:Spolsky.

[sootman]

+1 for Joel. +10, actually, if I'm allowed. I really recommend reading the above linked (online, free) book. And if you've got the time, you should pretty much read everything he's ever written. Even his stories about buying office furniture or shipping packages has little hints and clues, not about GUIs per se, but about all the little things that make any experience good or bad. And there's lots of good other stuff too, like dealing with people, creative approaches to problem solving, etc.

Even when he's wrong, the stories are still good. He has a series called 'Working on CityDesk' that has lots of little bits of good info. Despite the fact that his company's web-editing app CityDesk tanked ("nobody wants to compose in a big TEXTAREA on an HTML page") and they now focus on selling the bug-tracking software that they originally developed for in-house use, there is still a lot of good info. I love this bit about XML and databases. (About 2/3 the way down.)

And one other important thing to remember is to NOT go all by one source. Find some others. (Joel frequently mentions others in the industry.) As we saw above, Joel was as wrong as could be, and Norman, despite having lots and lots of good info, is a little too detached from reality most of the time. Forget Designing Web Usability, go read Design of Everyday Things instead.

Re:Spolsky.

[Anonymous Coward]

Agree with this - very good (and funny) book.
Also recommend:
Don't Make Me Think by Steve Krug
The Design of Everyday Things (Donald Norman)
and Tog on interface

Re:Spolsky.

[ategen]

Joel's book is awesome. You learn a lot of principles that just make sense.
Chapters include:

1. Controlling Your Environment Makes You Happy
2. Figuring Out What They Expected
3. Choices
4. Affordances and Metaphors
5. Broken Metaphors
6. Consistency and Other Hobgoblins
7. Putting the User in Charge
8. Danger for Extremes
9. People Can't Read
10. People Can't Control the Mouse
11. People Can't Remember
12. The Processor of Designing a Product
13. Those Pesky Usability Tests
14. Relativity: Understanding UI Time Warps
15. "But...How Do It Know?"
16. Tricks of the Trade
17. Designing for the Web
18. Programming for Humans

I have

[borizz]

User Interface Design and Evaluation by Stone, Jarrett, Woodroffe and Minocha. It's the book my university uses for its course titled Interface and Interaction Design. I like it, but then again, I haven't actually seen any of the other books.

About Face 2.0

[Anonymous Coward]

About Face 2.0 - Essentials of Interaction Design is one of the best books I've read on user behaviour and expectations, and how that is applied to GUIs. In terms of how test and design GUIs, paper prototyping is a great way to get your test users to interact with a design without having to code it first. If you're looking for a book to read on it, check out this one.

Top ten list of Game UIs.

[Anonymous Coward]

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

How well does all that apply to Game UI's?

Great book for web apps

[dorker]

Steve Krug's "Don't Make Me Think" is an excellent book for web usability. Many of the principles in the book apply to good app design as well.

http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1199369216&sr=8-1

Interaction Design

[noz]

Read Interaction Design. Learn. Prosper.

This one helped me

[martyb]

This one helped me a lot: "The Windows Interface Guidelines for Software Design" by Microsoft Press. (ISBN 1-55615-679-0)

I'm sure it's out of date now (it targets Win95 & NT), but I got it so I could help test some Windows applications back in the day. It was a great help in learning how to lay things out on the screen, in dialog boxes, menus, etc. Even more importantly, I learned the rules for keyboard navigation -- it's amazing how much can be done without having to take hands off the keyboard. Things are quicker, too, because I can key my way through drop-down menus without having to wait for each one to paint before I could click on the next selection I wanted.

I'm interested in what its follow-ons are and what people's experience have been with it.

Re:This one helped me

[Tsu Dho Nimh]

Design guidelines for humans are based on human eyes, hands and brains. We're not evolving fast enough to make that book obsolete :)

I have a copy too, and it's still useful to me.

Well you can start by

[AbRASiON]

Reading this old classic article, I always loved this one (and agreed so much)
http://homepage.mac.com/bradster/iarchitect/qtime.htm

While you're at it, Vista's explorer - yeah, don't copy anything from that either.
See more info here from me.
http://it.slashdot.org/comments.pl?sid=364823&cid=21406737
Specifically take note of what I whine about in the JPG's - it's that kind of shit which kills users.

Programming As If People Mattered

[Lodragandraoidh]

"Programming As If People Mattered" Nathaniel S. Borenstein -Princeton University Press 1991 - ISBN: 0-691-03763-9

Dated, but simple and very much applicable today. Humorous segways and examples abound.

Top Books

[will_die]

The top book in this area are generally considered to be..

About Face by Alan Cooper. Version 3 is out
Don't make me think by Steve Kung. This is for web.
Anything by Jakob Neilsen. Now mainly focuses on web but he is the main UI person around. Has a web site http://www.useit.com/
GUI Bloopers by Jeff Johnson a little dated but far too much informaion about every aspect of the user interface.

Then you have the books for the language or framework you are working on. Java, Apple and Microsoft all have books on how the user interface should work for thier environment and language. Most of theses can be freely downloaded or read online.
Then for a higher level look along with other information _Code Complete 2_.
If you can make it through all of thoses you will be one of the top UI people around.

GUI Bloopers

[superjordo]

Focuses on what people have done wrong with examples and explanations. Written by Jeff Johnson.

Go to the Master: Joel Spolsky!

[microTodd]

Joel Spolsky wrote "User Interface Design for Programmers" which discusses exactly what you are asking. Not the technical aspects of the API, but the Human Interface aspects that make an interface easy-to-use, intuitive, and useful.

Here is the Amazon link

He was also nice enough to put the book online for free: http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html

Re:Go to the Master: Joel Spolsky!

[egardner4]

I second this recommendation. This book is not particularly deep but it does give a general sense of what to do and what to avoid. It's a fairly gentle introduction to HCI principles with respect to GUI development.

Read the HIGs -at least when they are well written

[Sweetshark]

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html
Gnomes HIG is decent too. Dunno about the current state of the Microsoft HIGs ...

KISS me

[sm62704]

The old adage called the "KISS" principle applies: Keep It Simple, Stupid. This has fallen out of favor with the younger generation. Today's apps are busy; too busy. Everyone and their dog wants to be Bill Gates so they copy Microsoft.

However, at the opposite end of the spectrum isn't Apple, but Google. Google does it right. Simple, clean, light, fast. There is little to no trouble finding any of the myriad things Google has to offer these days, yet the interface still isn't cluttered.

IMO if your interface would fit a Microsoft product, it sucks. Microsoft writes the WORST interfaces. Big, heavy, bloated interfaces (and code to match) that give the impression of having more than it actually does, and offering more than you need.

Now, I'm a bit biased from my college training, as I was a fine arts major, and the instructors were mostly minimalists. One of my better instructors, when faced with a busy piece, would often say "there's less here than meets the eye". That's Microsoft.

Is there a patent on the circular menu or something? I have yet to see one an any commercial or OSS application.

If I weren't so damned lazy (and wasting all my time at slashdot) I'd use the KDE codebase to write a GUI that instead of having the windows-like taskbar at the bottom, would have a command line. You would still have icons, wallpaper, etc, but instead of a "start" button like Windows or KDE you would click on any empty part of the screen to pull up a circular menu. If you just started typing (without clicking anywhere first), what you typed would show up on the command line at the bottom of the screen. I still find it a hell of a lot easier to type "dir" or "ls" than to right-click "start", find "Home" or "Explore" in an old fashioned, should be obsolete straight menu, then click and click and click to get to where you were when you pulled it up. I find it easier to type "del ??task.bat" than to use Windows Explorer, drill to where the files are, hold down "alt" and choose the files I want to delete, then... well, GUI is great but command line interfaces have their strengths, too.

But to reiterate, what's worse than Microsoft? Any newspaper's web site.

-mcgrew

PS- don't go to my site looking for good design, it's cobbled together without much effort or thought. It loads fast though.

Re:KISS me

[Anonymous Coward]

I agree with you that clean, non-cluttered interfaces tend to be the way to go. I personally enjoy using Google's interfaces (not all of them, but most). As you said, clean and fast.

However, I very much disagree that anything "Microsoftish" is bad. This is very untrue. Yes, Microsoft does make some unintuitive GUIs (Visual Studio's options menus or Windows Media Player come to mind), but something like Office 2007 (yay ribbon) is a stroke of pure genius.

You have to remember, Microsoft is targeting a huge market of people so their code is going to be large - Word alone has thousands of different options to make everybody happy. BUT, Microsoft does a good job of bringing the main options forward and making their Office software quick and easy to use. Going with a blanket "Microsoft sucks" statement may get you modded up, but it's not always true.

In addition, you mention the utility of the command line vs. the GUI. I actively use Linux, and I do enjoy using the command line. But, when I think about teaching someone like my mom or grandmother how to use a command line tool, I feel a cold chill run down my spine. Yes, GUIs can be more inefficient, but they are necessary for people who do not know (or want) the power of the command line.

And, about a statement like this, "Microsoft writes the WORST interfaces. Big, heavy, bloated interfaces (and code to match)" - you're just looking for mod points. How much of Microsoft's code have you seen?

Re:KISS me

[The_reformant]

For some tasks sure a command line is fine, but lets take an example task that I find myself having to perform on a very regular basis:
perform an operation on an arbitrary sub-set of files in a directory

So my choice is spend half an hour composing a regex that selects the files I want to operate one or just control click them on the GUI?

I also disagree that microsoft apps are a bad example of GUI design, lets compare them to the much touted apple whose window control buttons have no glyphs and are only distinguished by colours which 25% of the male population have trouble in distinguishing. Or the speed of the start menu versus the dock.

Now yes the interfaces are more complicated than googles, but guess what visual studio does a hell of a lot more than google (and in fact can perform search). Its a busy interface but it shows a hell of a lot of information at a glance. Something I would have to toggle in and out of buffers for droppping into terminal windows and so on to accomplish through a emacs (say) type editing workflow. Each of these little context switches add up.

Why is the circular menu so good, I find them pretty appalling even to control things which are traditionally "circular variables". Take for example pan pots on cubase. Controlling these with the mouse is a royal PITA (linking them to hardware pots is another story of course)

Now I can see from the background you provided that busy interfaces aren't going to appeal to you since you like a minimal aesthetic but this isn't necesarily going to apply to all markets, and I think these days the proportion of feature utilisation of something like word is actually a lot higher these days since people are expected to produce much more carefully formatted documents in a flexible number of formats.

Re:KISS me

[sm62704]

something like Office 2007 (yay ribbon) is a stroke of pure genius.

We're still using Office 2000 where I work. Those menus that don't show all the items unless you wait are a pain (I've changed it on my machine, somebody here clued me as to how).

Word alone has thousands of different options to make everybody happy.

They should make thousands of different products then. I hate swiss army knife software!

Going with a blanket "Microsoft sucks" statement may get you modded up, but it's not always true

Perhaps, but it's been my experience. And since I've gotten a "troll" and a "flamebait" today it's not likely I'm doing much karma-whoring. Maybe they've gotten better, but I'd have to see it. I actually liked DOS, and back then I hated the Apples they had in my kids' schools (although I liked the earlier IIe).

But, when I think about teaching someone like my mom or grandmother how to use a command line tool, I feel a cold chill run down my spine.

It would be there, but you would still have icons to click.

you're just looking for mod points. How much of Microsoft's code have you seen?

I've seen the product. You used to get an OS on a floppy, now it takes an entire CD. Linux distros get not only the OS but nearly every program most people would need, including several competing versions, and it's on 3 CDs for Mandriva. The one Windows XP CD only has an OS and a few simple apps like Write and Paint, and only one of each of them. With a Linux distro you have three or four browsers, an entire office suite or two, paint programs, several media programs, etc.

I have a ten gig drive for XP and Linux and an 80 gig drive for data, Microsoft continually squels about running out of disk space.

Re:KISS me

[sm62704]

What I'd like to see in a GUI isn't really minimalist; you would still have icons, a menu system, etc but a command line as well that you wouldn't have to open a shell ti use.

Google "gui hall of shame"

[gfxguy]

For a lot of good discussion on things that people have done just plain wrong:

Google "gui hall of shame"

Re:What I like to do.

[MajinBlayze]

I can't possibly see any reason why having more options is a benifit

To me, that's what Linux is about, having options.

That being said, the new windows shell sounds interesting useful, if a little late to the party.

Gui Bloopers

[hibiki_r]

This one might not have all the rules you might want, and some of his concepts are debatable, but it goes into the nitty gritty details other books don't.

Another Helpful Book Rec...

[endofoctober]

...would be Steve Krug's Don't Make Me Think. While specifically focused on web design, the book introduces some helpful concepts that are fairly universal for UI design. I also second (or third or fourth by now) anything by Tufte - genius stuff (and he'll be the first to tell you that), and very thought-provoking.

Re:What I like to do.

[SQLGuru]

GUI interfaces are easier for input (no switches to remember, easy to navigate, etc.)
Command lines are easier to schedule and include in custom batch scripts
Command lines allow input prior to the program loading

Both have their place.

The big problem I have is that most administrators* that rely on the command line (in particular DBA's using SQL*Plus) don't help themselves out and manually enter that string of commands instead of batching them up or writing a GUI to simplify their normal tasks. (* administrators that I have personally encountered, your experience my be different).

Layne

Rule #1: Don't make the user look stupid-Mirrors.

[Anonymous Coward]

According to slashdot the user already is stupid. How can the UI designer make it worse?

About Face!

[me( coffee )]

About Face 1,2, and 3, by Alan Cooper, are the best interface design books I have ever read. I have recommended them to many people and have never had any complaints, only thanks.

Apple's Book on UI

[Anonymous Coward]

Apple wrote what I understand to be the defacto standard on User Interface Design (I have a copy in storage) - it was written in the 1980's but apparently is still very applicable.

Don't make them use the mouse...

[technomom]

Keep in mind that touch typists HATE to have to use the mouse. Be sure to design so that enter pages can be navigated logically using the keyboard. By logically, think left->right, top->bottom (at least for the North American English speaking audience, I can't speak for other cultures).

Also, make the system intelligent. If a lot of the data entry is repetitive, build in some typeahead and use intelligence (e.g. a bill-to address usually IS the same as the ship-to address so provide for that). Get yourself a zip-code lookup. There is nothing more annoying than having to enter the same data repeatedly.

Use the system yourself for a while. Really. Not for 2 or 3 record entries, use it for 100 or so REAL entries to find trouble spots you imagined and requirements that were never raised (Some surnames ARE longer than 15 characters, some names have accented characters, some people DO put capitalization in the middle of their names, Oops, what do we do with this order from Toronto? It seems to have a weird zip code that our numerical filter cannot handle...). And of course, find out what annoys you when you use it and FIX IT.

Good luck!

Edward Tufte

[dogd1ck]

"The Visual Display of Quantitative Information", by Edward Tufte.

Edward Tufte (Re:Some suggestions)

[Beorytis]

Absolutely recommend Tufte's work, and for a much broader audience than those implementing GUIs. (Really everyone from weathermen to magicians). Enjoyable reading to boot!

"There's no bullet list like Stalin's bullet list!"

Ignore the books

[Thaelon]

This is surprisingly simple. Ignore all the artsy fuckers that thing GUI design is an art. It isn't. It's a surprisingly hard science.

Good GUIs minimize the amount of physical user interactions required by the user to perform any action. Mouse down is an action, mouse up is an action moving the mouse 5mm is an action. You get the idea. You need to be aware of EVERY tiny action and try to eliminate as many as possible. If you must use a right click menu with 2-3 menus deep, provide a hotkey for the same action.

Good GUIs absolutely, positively, never throw a modal dialog with only a single button. And avoid one with two or three buttons if possible.

Provide a hotkey for everything.

Use one thread for the GUI, one thread for the behind the scenes work.

Make sure your cancel buttons actually work to halt long resource intensive processes.

Don't use hover menus. Ever. Seriously, never. The mouse is a feedback only device until a button is clicked. Tooltips are OK as long as the vanish the instant the mouse moves off of the (small) trigger area, blocking what a user is trying to see is obnoxious.

Above all, don't annoy your users. Your GUI is a means to use your software, that is all.

Much can be learned here for free. Interface hall of shame on the left bottom. It's what NOT to do.

Jef Raskin's The Humane Interface

[RealGene]

..will clarify why most interfaces suck, and what you can do to avoid sucking also.
--Gene

Re:Jef Raskin's The Humane Interface

[stewbacca]

I love these kind of books. Study bad design to understand good design! The best part is they actually offer a solution to a problem, instead of just griping about the problem.

"About Face" by Alan Cooper

[kcdoodle]

I read this book years ago. It makes you think about features people come to expect in programs. The author is about "putting in ALL on the programmer". What I mean is, many of his ideas are great, but are very hard to implement.

Some example pointers: "Infinite undos - keep track of EVERYTHING done in the program, and let the go backward and forward through the changes", another: "Silently fail - when a user clicks on the wrong thing, DO NOT make a pop-up that says - 'You did something bad', just do nothing, the user doesn't need to be told he is stupid".

Actually the book is extremely short on actual implementation, but that part is up to you.

Re:"About Face" by Alan Cooper

[Anonymous Coward]

"Silently fail - when a user clicks on the wrong thing, DO NOT make a pop-up that says - 'You did something bad', just do nothing, the user doesn't need to be told he is stupid".

Huh? There's nothing worse than clicking on a button (which has been presented to you and is not obviously 'disabled') and having nothing happen. My first reaction is 'did I click properly?' then 'how long should I wait to see if anything happens'. You shouldn't generally be able to click on the 'wrong' thing because it shouldn't be shown or should be obviuusly disabled. If it's unavoidable, you should produce a nice polite message which doesn't make the user feel stupid but explains clearly why the program can't do what they asked, e.g. "Sorry. Cannot write to CD as it has already been finalized. Would you like to eject the CD and load a blank one?" EJECT|CANCEL

Technical Communication

[pmbasehore]

I recommend the book Technical Communication by Mike Markel (http://www.amazon.com/Technical-Communication-Mike-Markel/dp/0312441975/ref=pd_bbs_2?ie=UTF8&s=books&qid=1199371904&sr=8-2)
It goes into a lot of the basic theory behind good communication in general, which is really all an interface is (communication between the user and the computer). It does not have a chapter on interfaces specifically, but it talks in depth on good electronic interfaces like online documents and webpages.

Recommendation...

[TemporalBeing]

Back when I was in High School I got the starter set to learning Visual Basic 5 that Microsoft Press put out. It came with two books, one was more thorough on Visual Basic, but the other (the title of which escapes me at the moment) went into all the controls and GUI elements, etc. And (while most here would not like this) I would use Visual Basic as a tool to teach GUI design and focus on content like that book had - which, btw, went into accelerator keys, how controls relate, and more. (I'd use VB only because you can ignore most of the rest of the program and focus on GUIs alone; I'd use and recommend other languages for all other aspects of programming.)

Follow Apple's advice

[Anonymous Coward]

Apple has the best user interfaces ever.

Why?

The OS is not a program to talk to the machine or to manage resources, it represents the interaction with the user. Use a Mac for 20 seconds and then go back to use a Windows machine. The Windows machine sucks.

Why?

Because the Apple OS is made in such a way that everything you see on the screen is manipulable, it is direct manipulation into action, or how we called it 15 years ago: WYSIWYG (What You See Is What You Get). Direct manipulation is the key, that is why they came up with the desktop (the recycle bin, folders, etc.). It could have been drawers instead of folders, but anyway...

Since most of the development nowdays is web development:

1. Everything that shows on the screen must be modifyable (opened, moved, changed, deleted).
2. You can browse the objects through the user interface (see Naked Objects).
3. Ajax look and feel (no reload of the page).
4. No scroll (or minimize scrolling). Everything must be visible at all times.
5. Unclutter the UI by using icons or drop down menus.
6. Use meaningful colors to mean different states of objects.
7. Use consistent names, colors and shapes.
8. Allow sorting in searchs.
9. Allow storing past search criterias.
10. Unlimited undo.

Ok-Cancel

[hansamurai]

Not a book, but a comic. I'm not sure how much it will actually help but it's humorous and gives us non-GUI programmers an insight on their world.

OK-Cancel

Designing Interfaces

[elh_inny]

I highly recommend http://designinginterfaces.com/.
Taken purely from usability perspective, aims perfectly at developers.
It introduces a set of patterns (similar to to the famous coding patters by Boch et al. - should be known to any OO developer).
The patterns are easy to navigate and easy to apply - you don't have to be working 100% of your time on usability issues to be able to apply these recipies.

One minor downside, I think there is not enough focus on web side side of things in that book - the capabilities of browsers have grown recently, thus allowing much greater capabilities there. In such case I'd still recommend the book as as a start and scavenge the web for the rest.

Furthermore there are tons of resources and communities devoted to GUI design and usability issues, you may wish to start here http://www.stcsig.org/usability/ for instance.

IAAUIDE

[sandbenders]

I am a user interface design 'expert', and I can tell you the best solution is to hire an expert, if that's possible. This is a whole field of study- I studied it for 2 years, got my MS, hit the real world and then REALLY started to learn about it. I did include some titles below, but getting good at this requires a totally different kind of thinking than writing good code (which was my old job). That doesn't mean you aren't going to be able to do it, but it does mean that it's going to require you to think about things from a totally different point of view. Imagine an art major trying to write good, well-modularized code.

I have read a number of answers above- some are good, many have nuggets of truth or basic guidelines, some are downright awful, but the one truth is this- you are not your user. What is good or easy for you is not necessarily good or easy for your users. Ultimately, you will need to watch them use the interface to make it truly good. This doesn't require eyetracking equipment, video cameras, etc. Just ask them to use it and sit there and watch, silently. It will be the best thing you can do to learn about how your users use the app.

Here are the titles I promised:
Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug
Designing Interfaces: Patterns for Effective Interaction Design by Jenifer Tidwell
Designing Web Usability by Jakob Nielsen
Usability for the Web: Designing Web Sites that Work by Tom Brinck, Darren Gergle, Scott D. Wood
Contextual Design : A Customer-Centered Approach to Systems Designs by Hugh Beyer and Karen Holtzblatt

-Sandbenders

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

Visual language

[Don Philip]

Along with the other excellent posts recommending books, I'd like to add the following: Horn, R. E. (1998). Visual language : global communication for the 21st century. Bainbridge Island, Wash.: MacroVU, Inc. Horn describes a system of visual language that might be of use in interface design. He makes you aware of some of the issues surrounding the display of visual information, etc.

As well, have a look at: van Merriënboer, J. J. G., & Sweller, J. (2005). Cognitive Load Theory and Complex Learning: Recent Developments and Future Developments. Educational Psychology Review, 17(2), 147-177.

In particular, pay attention to Sweller's 'split attention' effect, in which the cognitive load is increased if the user has his/her attention divided among related interface elements that are separated on the display.

Tufte

[csirac]

I've been tasked with coming up with a GUI that involves data visualisation and report presentation, where before I've mostly done very discrete back-end or embedded systems stuff.

Because there's real-time data visualisation (as well as historic stuff), I've heard about the Tufte books before and so bought all four available at bookware.com.au - Beautiful Evidence, Visual Display of Quantitative Information, Envisioning Information, and Visual Explanations.

Still waiting on them, probably won't be able to appreciate them all in time, but hopefully I can make my app suck less than the existing solutions I'm tasked to replace.

My application is loosely what might be traditionally known as SCADA... but for various reasons we're not using traditional SCADA packages. We're presenting industrial process data, traditionally there are real-time figures and "dials"/bar graph gauge type indicators, along with graph plots that resemble the paper and pen chart recorders this software replaced many years ago.

Any particular one of the four books that people might know to be most useful for me, or a suggested reading order anyone might have?

Re:Tufte

[Anonymous Coward]

I have been in similar situations and can tell you that SCADA can be a mixed bag.

Some manufacturers that made the original physical interfaces of dials and such spent significant effort on Human Factors analysis and thus are worth copying / using to inform your design; others not so much.

The other thing you need to latch on to is your user group. Use sketches. Get their feedback often. Just including them in the design process will ease the implementation and help you avoid critical mistakes.

I saw one system that was built for a weighing station at a paper mill. The operator of the weigh station could log incoming shipments of wood in about 5 seconds without ever looking at the screen with the old system and weigh-out the same shipment in another 5 seconds with a quick glance.

The GUI interface that the developer's foisted on this guy for the "new and improved" system was a disaster. They spent most of their time making sure they were acquiring the data from the scales in the most efficient (who cares?) and reliable (ok, fair enough) manner. He was completely lost. One critical keystroke sequence he had used with the old interface had subtly changed by one keystroke for no apparent reason and he HAD to click on portions of the interface to do his job.

IF someone would have spent 15 minutes IN THE SHACK watching him do his job they would have figured out that the people back in the office that wanted to do some monitoring and analysis were the guys that needed the fancy GUI, not the guy in the weigh shack.

Re:Tufte

[Quietchu]

Visual Display of Quantitative Information is a great book and a quick read. I recommend it to anyone who has to put together any type of visual presentation. Tufte presents tons of graphical examples and breaks them all down. He presents both positive and negative examples, explaining where the negative examples falter and suggests improvements. If you are presenting any kind of data, I would highly recommend starting with this book. The way he drives concepts like information density has changed the way I look at almost any visual information and drastically improved my ability to critically examine visual information presentation.

Re:Tufte

[fossa]

I have all four Tufte books and I have read a few of the other interface books suggested by others. Books like Raskin's The Humane Interface and Norman's The Design of Everyday Things tend to focus on "widgets" for lack of a better term, specifically the minimization of modes, steps, and things that must be kept in the head to perform a given action, and the design of natural mappings of controls to what is being controlled (favorite example: stovetop burners are arranged in a square; majority of burner controls are linearly placed with some sort of picture indicating which burner is affected; vastly simpler is a square layout of the controls matching that of the burners; my grandmother almost started a fire due to this confusion). These are essential of course, but Tufte's books bring another much needed perspective: an interface is primarily a presentation of information, and the presentaion should be guided by library science and information design principles.

More to your question, I agree with the other poster to start with Display, though I've read the most from that one and simply skimmed the others. Display seems to focus mostly on plots of scientific data. The next two have things like the weather animation depicted on the cover of Visual Explanations and neat train schedules from around the world which may or may not be more relevant depending on what you're doing. I attended Tufte's travelling lecture, and I believe I still have his list of sections, pulled from the first three books, most relevant to interface design; I may be able to dig it out later in the day.

Tufte's message board is a wealth of information on dozens of related topics. Apparently Tufte published an out of print booklet, Visual Design of the User Interface, much of which became a part of Envisioning Information.

Re:Tufte

[fossa]

Well, this may or may not be useful, but the notes from Tufte's presentation say "Web site design, computer interfaces, information kiosks: Visual Explanations, pages 146-150, then every entry in the index under 'interface'; Envisioning Information, chapters 2 and 3, then every entry in the index under 'interface'."

An excellent IBM presentation on GUI design

[bchernicoff]

User Interfaces: Past, Present, and Future; Good, Bad, and Ugly is from last year's JavaOne, but isn't really Java specific. The slides are available to everyone, but I highly recommend you sign up for a free Sun Developer Network account if you don't have one and watch the multimedia version. Also, the whole Desktop development category may be of interest.

GUI design books

[ATL_gadget_grrl]

I have heard this a lot from my Business Analyst colleagues - they can gather the bejeezus out of requirements, but translating them into GUI is tougher. I usually recommend Jakob Nielsen's Web Usability book (even though it's old, the basics never change), and Universal Principles of Design by Lidwell, Holden, and Butler as starting points. If you prefer a cookbook-type approach, you can explore Jennifer Tidwell's work on design patterns, which provides you with some basic ideas for the most commonly used GUI widgets. I caution you to also consider the information design/information architecture. You can learn more about the basics of these topics by taking a look at Jesse James Garrett's Elements of User Experience. Ultimately, though, this is something that most people cannot get straight off just by reading books. It takes practice and review cycles to truly craft your skills. You'll get better as you iterate through. Good luck!

GUI Books

[arakasi]

The Design of Everyday Things, Donald A. Norman

About Face 2.0: The Essentials of Interaction Design, Alan Cooper and Robert Reimann

Designing Interfaces, Jenifer Tidwell

Re:GUI Books

[stewbacca]

The Design of Everyday Things, Donald A. Norman

This is the Designer's Bible of sorts. Although it predates most modern computer UI design elements, the concepts are still extremely valuable. As a matter of fact, I'd say that most bad UI design wouldn't exist if people understood the knowledge offered in this book. I'd suggest reading this as a foundation, then buying other books that are UI specific.

p.s. If you see The Psychology of Everday Things, don't be confused, as that is the original title of the book. It is the same book.

Has anyone tried Office 2007

[Dutch Gun]

I'm probably setting myself up for a some abuse here, but has anyone other than myself tried out Office 2007 (which is available at my workplace)? I'm curious what the general consensus was - or even some personal anecdotes... Personally, after getting over a bit of a learning curve, I've actually found the whole context-sensitive ribbon system to be pretty innovative, and I actually prefer it now to older versions. I recall a similar concept used in CorelDraw, where specific toolbars would change based on which particular drawing tool was currently in use, and what type of objects in the drawing were selected.

http://blogs.msdn.com/jensenh/archive/2006/08/22/711808.aspx

I've read some documentation (some interesting videos too, but I can't seem to find them) on the justification for the shift in thinking - about how, for example, the explosion in the sheer volume of functionality makes packing every single function into a static menu structure somewhat impractical. To be honest, when I look at some other modern applications with their enormous menu systems, I'd actually have to agree.

While one may or may not argue the benefits / drawbacks of a specific implementation such as Office 2007, I think an interesting point of discussion is the growth of dynamic interfaces in general - that is, interfaces that adapt to the context of the current work that is being done, to display the functionality most important to a user based on that specific context. Adaptability may even be appropriate, as a computer learns what tasks a user attempts in specific circumstances, and then adjusts itself to try to make accomplishing those tasks easier in fewer steps.

Computers are becoming more and more powerful, and it should be an interesting challenge to try to package all this functionality in a way that doesn't overwhelm users with more and more complex interfaces.

Re:Has anyone tried Office 2007

[coryking]

I think Office 2007 is a huge step forward, especially for Word. The designers took a rats nest of features and laid them all out in a clean, easy to discover way. Better still, it took advantage of modern hardware so you can preview what a given tool will do to your work before committing yourself to it.

The real crazy thing about it is that prior to Office 2007, people always bitched about how bloated Office was. To a point, I agreed. With Office 2007, I almost feel like Word doesn't have enough stuff in it! Everything it can possibly do in Word right in front of me now!

My question is, can this design ever work in an application like Visual Studio? What about Photoshop?

User Interface Design

[pianoman113]

The best book I've encountered on UI design is an ancient tome entitled "Principles and Guidelines in Software User Interface Design" by Deborah J. Mayhew. Search for it on Amazon; looks like there are 30 used copies.
This was used as the text for my GUI design class in college. Very enlightening, even though I HATE writing GUIs.

Apple's Human Interface Guidelines

[bagoas]

Tog's great.

Apple's HI Guidelines are really the distillation of [practical, achievable] best practices, as laid down by all the HCI greats that have ever worked there:

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGHIDesign/chapter_5_section_2.html#//apple_ref/doc/uid/TP30000353-TPXREF130

There's plenty of theory and pontification, but this is backed up by API's. If only Apple would consistently follow their own dog pee.

Re:What I like to do.

[somersault]

You can get command line style inputs in GUIs just by going to the properties for a program, or a shortcut, and there is a scheduler in Windows (haven't tried scheduling tasks in Linux, apart from on startup, where I just added the task to one of the many many startup scripts, one of the rclocal ones or whatever they're called)

Asking SLASHDOT???

[Anonymous Coward]

I want a good user interface, so I am going to ask a crowd of people who have tolerated a crappy user interface for years. Brilliant!

Check out Ableton Live for a good exemple.

[Pocaille]

http://www.ableton.com/

I was really impress by its UI.

Re:What I like to do.

[somersault]

It's a benefit when you want your OS to be flexible. For example as plenty of people point out, you can run Linux on anything from a washing machine to a supercomputer without too much messing about, because of its modular nature and the amount of people out there that do work to improve or customise it, often just for fun.. a world without choice quickly goes stale.. look at what was happening with IE until Firefox got big, and what was happening with Intel until AMD got their Athlons out the door :)

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.

Re:Hall of Shame

[NaDrew]

Don't forget to have a good look at the Interface Hall of Shame for examples of what not to do. I used to love the laughably bad examples on that site, but it hasn't been updated since 2000. Now it's almost an example of what it derides.

Re:Hall of Shame

[matthewd]

I think the company that maintained this is no longer in business, and archives of the pages are kept alive by various fans of the site. But you are correct, there is nothing from 2000 on, which means nothing pertaining to XP or Vista. The content for the Hall of Shame was largely reader generated. If someone were to pick up the banner and start a new Hall of Shame it might be more a labor of love than anything.

UI Class Book

[10e6Steve]

Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology, by Ellen Isaacs and Alan Walendowski. It is an easy read with examples as the authors design an application. It goes over the basic design rules, getting feedback, a little of the software engineering process, understanding the user, doing usability tests and usage studies.

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!

Re:Pig Toaster - duh

[Anonymous Coward]

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! I do believe that was the exact point being made, but thanks for explaining the obvious anyways.

Re:Pig Toaster - duh

[LiquidEyes]

and of course the suckling piglets are the option buttons too.

Platform and Purpose

[JCSoRocks]

It seems that nearly everyone has assumed you're writing a "windows" application (or linux or mac or whatever OS you For example - a windows based internal data entry application or a web based customer portal for looking at reports. If you're going to read a book you have to make sure that it applies to what you're actually going to be writing, otherwise you're wasting your time.

I think that three things determine what guidelines you should be looking at-

Platform - Obviously different OSes call for different designs, but even a web application has different rules than a web page. (One is generally for performing a task while the other is about gather information or reading content)

Target Audience - #1 rule is always that your customer doesn't know your audience - and neither do you. You have to do usability tests. It's the only way to know if what you're doing is "right".

Purpose of the software - This will determine what you optimize your application for. Speed, ease of use, appearance, etc. Although not necessarily mutually exclusive you usually have to make some sacrifices in order to achieve your primary objective. Ex - An internal data entry application will probably be optimized for speed first and ease of use second.

Good luck! Personally, I think UI design is a blast.

Designing The Obvious

[Khuffie]

Designing the Obvious is a fairly good book about UI design. I highly recommend it. Here's a link.

Do not repeat the mistake of others....

[gnalre]

The problem of GUI design is most people come to it with little or no understanding of what underpins it. Basically we a talking about communicating with humans and therefore we need to understand the human psychology. Therefore I would start with books that explain how people visualize objects or how they approach problem solving. While studying other designs have merit, often the mistake is to repeat a design in another situation where it is less appropriate. Also the process of convention is also important. Windows is so ubiquitous that it is difficult to move away from its principles, but that doesn't mean that it is a good GUI by any stretch of the imagination and until you can understand why there is little chance of you writing a good one of your own.

Another important area is how the GUI is designed and tested. The process is very different to software since it requires fine grain of iteration and extensive interaction and analysis of test users.

One suggested book is Human-Computer Interaction by Jenny Preece(and others)http://www.amazon.com/Human-Computer-Interaction-Jenny-Preece/dp/0201627698/ref=sr_11_1?ie=UTF8&qid=1199374522&sr=11-1/

Re:What I like to do.

[SQLGuru]

The at command (Windows built in scheduler) will run a GUI based app, but since the GUI *assumes* graphical input, if there is a problem, it will usually try to display it on the screen....which is running under another process, so you won't always see it. I'm not saying it isn't possible, just that command line tasks work much better under a sceduler (just redirect the output to wherever you want). And while some GUI programs will accept command line input, they have to specifically be coded that way, otherwise, they aren't of much use in a batch mode.

Layne

Re:What I like to do.

[Anonymous Coward]

Windows command line and GUI have something linux doesn't have. CONSISTENCY.

They're both consistently shit, you mean?

human interface design

[capsteve]

it was/is an apple design guide for the mac os interface. addison wesley was the publisher when it first came out.

IMHO the mac gui through it's various permutations (mac os 9/next/os x) is still one of the best gui's out there. sure there are other gui's that have a lot of bells and whistles that the mac os is missing(3d desktop and jello effects of beryl/compiz,desktop gadgets of vista, better multi-button integration) but as far as consistency, user feedback, and ease of use, the mac gui still wins hands down.

couple of suggestions

[BillAtHRST]

Here are a couple that I just bought and like a lot:

Designing Interfaces: Patterns for Effective Interaction Design [ILLUSTRATED] (Paperback) by Jenifer Tidwell (Author)
http://www.amazon.com/gp/product/0596008031

User Interface Design for Programmers (Paperback) by Joel Spolsky (Author)
http://www.amazon.com/gp/product/1893115941

Eastern Standard Tribe by Cory Doctorow

[SkipF]

http://www.craphound.com/est/

Protagonist is a User Interface / Experience consultant. Good story and good (albiet, non technical) commentary on interface design.

Joel Spolsky's "UI Design for Programmers"

[JoeUmitsubame]

I personally found "User Interface Design for Programmers" by Joel Spolsky to be an excellent resource. A fellow developer suggested it to me after experience some of my option-laden interfaces, and it actually did change my ideas of how a UI should be designed so that others can actually use it. It's all about concepts; it has no code and is not specific to a particular OS or UI toolkit. Some of the examples don't even have to do with computers.

If you want to check it out, the author has the http://www.joelonsoftware.com/uibook/chapters/fog0000000057.htmlfirst chapter on his web site.

-- Joe

User Interface Style Guide

[APL bigot]

See: http://www.amazon.com/review/product/0201577577/ref=dp_db_cm_cr_acr_txt/104-4713685-0897556?_encoding=UTF8&showViewpoints=1 for a review. BTW, that's Amiga User Interface Style Guide, but the principles aren't OS specific. Emphasis on general interface principles.

Re:User Interface Style Guide

[Anonymous Coward]

Indeed. That's one of the best books ever written on UI, and used to be recommended reading for e.g. Gtk+ developers. Very difficult to actually get a copy though. Many, many amiga apps disregarded it*, so if you've used an amiga, don't mix up your practical experience of amiga guis for the considerations that book recommends.

* Though, due to the amiga "screen" (persistent-per-application-associated named virtual desktop, sortof) paradigm, custom uis tended to be isolated from eachother and therefore less jarring than your typical blender or xine plonked on a linux desktop (or winamp or msn plonked on a windows desktop for that matter).

Re:User Interface Style Guide

[APL bigot]

Actually, the posted review link, shows that there are 9 available. One (or is it 2?) less than yesterday. Perhaps one of our Slashdot tribe has purchased a copy. Mine sits on the shelf with the rest of my Amiga library.

Ralph Babel's Amiga Guru Book is however almost (really?) impossible to obtain. I've wanted a copy of that one for awhile.

Go to a toy store

[TheGrapeApe]

I know this sounds strange, but I've been working as an app developer for *very* untechnical people for quite a while...in all modesty, I'd have to say that I am better at interface design than any programmer I've ever worked with by leaps and bounds...probably because learning CS was *really* tough for me, but I forced myself to do it anyway, so I can relate a little bit better to the average user when they're looking at the front end of a complex system. My secret when I need inspiration for some good UI design? Toys. The Fisher Price "playstation"-type ones are the best..

You're probably like "What??"...But think about it for a sec...most of the time when you're designing an interface, what is your goal? To make something that is 1) intuitive and 2) something that the user can hammer at repeatedly without getting annoyed/bored/cranky. Who does that better than Fisher-Price? Toddlers, for the purpose of UI design, are just like your users...they're not "dumb", they just don't start out with the same level of knowledge about the system that you're developing i.e., they need to use their intuition to learn about it. So take your cues from a toy company that's been around since you were a baby and make your UI just like their toys; Unbreakable. Colorful, big buttons that draw the user's attention...If you give them a square hole, give them a square peg to put in it (and make sure it's designed properly so they don't choke on it).

Honestly, UI design has always been the most natural thing to me...I tried to read a few books on it, but found that they typically bloviated on strange tangents, buzzwords, and irrelevant minutiae. So here's my advice in a nutshell: skip the books, go play with some toys.

One thing that most programmer's don't know, but they seem to teach every Lib arts student: The 'Z'. When people read or look at something, they tend to do it in a 'Z' pattern starting at the top left of the page and going to the bottom right.

And if anyone tries to tell you the mantra "If you make it easy enough for any idiot to use, only idiots will use it", ask them if they've seen www.google.com; There's always a "sweetspot" in UI design. If most of your users are only going to be using 1% of your interface (in google's case, the search box), don't clutter their view up with the 99% percent that they don't need (the advcanced search features).

Book suggestions

[counterexample]

• Bruce Tognazzini headed up the Macinotsh interface team, his official was "Interface Evangelist". Anything by him will be good. I recommend "Tog on Interface," it's a series of articles he wrote on interface design.
• Font matters. Size, headings versus body, when to use serifs and when not to, etc. "The PC is not a Typewriter," by Robin Williams, is a good resource for this.
• She also wrote a good book on web design called "Web Design Workshop" you might like.
  
  Interface is criminally overlooked in software design; power to you for taking the time and effort to do it right. The key point to remember: The user shouldn't have to learn anything. The interface should make it obvious how to do what needs to be done.

The Original Human Interface Guidelines

[Bones3D_mac]

Sure, it may not mesh well with the current "throw your shit anywhere" philosophy of interface design, but I guarantee you any interface you design from using the original human interface guidelines will be easily navigated and highly usable.

Don't get a book!

[BrendaEM]

Want to learn about GUI design--then study GUI's, and how user interact with them. Because you are aware of GUI's you will notice what you like and don't like. In the end I don't think there is much to be learned about interaction--from a media that does not allow it. [There are also lot of Graphic layout magazines, and websites that probably represent the worst in graphic layout.] There are a lot of good and bad user interface designs. A good place to look for bad GUI design are 3D design programs and development tools meant to be used by a company internally. Almost all Flash-powered GUI's on websites are artful, strange, and awful. What's good in GUIs is harder to come up with, because the best GUIs go unnoticed. Ask yourself, what program do I use every day, and have not cursed at it? Because the answers to that question are few, I would be wary of any preexisting GUI knowledge.

Best Book I ever read on Design

[grominar]

Best Book I ever read on Design is by far Jakob Nielsen's Designing Web Usability http://www.chapters.indigo.ca/books/Designing-Web-Usability-Practice-Simplicity-Jakob-Nielsen/9781562058104-item.html?ref=Search+Books%3A+'Jakob+Nielsen' It provides factual, mesurable data for it's conclusions.

An off-beat recommedation

[smkstack]

Eduard Tufte has some interesting and quite beautiful books on design and the presentation of data. While all of them are not specifically about the GUI of computer applications I think he provides some very compelling ideas about how the information of our programs gets presented graphically and contextually. His are great books and I recommend them for a fresh view of how our work can look.

A few notes from an interaction designer.

[Aqua OS X]

IMHO, if you have time it's valuable to take a few graphic and or product design classes. You'll learn things about visual communication and the design process that are often ignored in HCI books / curriculum.

As for recommended reading, you might want to check out:
The Art Of Interaction Design by Chris Crawford
Designing Interactions by Bill Moggridge
The Humane Interface by Jef Raskin

You might also consider subscribing to a design publication like Communication Arts.

GUI Design

[thethibs]

1. Anything and everything written by Edward Tufte
2. The Art of Interactive Design. Chris Crawford.
3. The Elements of Typographic Style. Robert Bringhurst.
4. Anything and everything about use cases. Without good, non-technical use cases based on the user's intent and workflow, you don't know what you are trying to achieve.
5. Avoid the programmer's quest for efficiency. "A place for everything and everything in its place" makes an annoying interface. Redundancy is good; give me everything I want wherever it might be useful.

I do this for a living

[Anonymous Coward]

I'm sure this will get buried (especially since I'm doing this as anonymous), but maybe you'll read it anyway.

My advice to someone in your position (no HCI background, just a coder that wants to make an interface usable) is this:

1. Design the interface on paper (or with a quick software prototyping tool if you've got one you're good with). This should take you less than one day. Perhaps less than one hour.

2. Get people (real users if possible, other people not working on your project, or team members as a last resort) to "interact" with your prototype. Give them some scenario to work through and have them tell you what interface elements they'll use and how (don't explain it to them in advance). If significant changes would happen on the "screen", reflect that so they're not using their imaginations more than they have to. You'll find out that nobody has a friggin' clue what they're supposed to do with your interface. Ask them what they thought they should do and what they wanted to do. The key is to figure out how they were interpreting the interface and what they were expecting with regard to the scenario you gave them.

3. Redesign the interface based on what you learned worked, didn't work, and was expected in their minds.

4. Iterate until you feel confident. THEN code it up.

The hard part is that no set of rules can really tell you what will work in a particular situation. Until you can understand how someone is going to be thinking when they use your interface, you won't be able to put yourself in their shoes to design it well.

Good use of color and contrast

[halcyon1234]

While whitespacing, alignment and font are all things you need to consider, don't overlook the importance of color choices. You need highly contrasting colors that are easy on the eye, and that take into account colorblind users (about 8-10% of your userbase).

Some guidelines I wrote (for an assignment for an HCI course I just took) for color selection are:

1. Do use dark backgrounds, and light text.
2. Don't use adjacent colors of similar lightness.
3. Don't use Blue as a background or for fine detail.
4. Do use shades of Purple, Violet, Red for background. AND Do use shades of Green, Yellow, Orange for foregrounds
5. Do make sure black-and-white and monochrome versions are legible.
6. Don't rely on color alone.
7. Do give high-priority data high contrast.
8. Do use tools to check your contrast.
9. Do check colorblind compatibility

Some resources to look into from my bibliography:

"Luminance Contrast Color Guidelines." Arend, L. Logan, A. Havin, G. Color Usage Research Lab. Nasa Ames Research Centre. 7 Oct 2007 http://colorusage.arc.nasa.gov/guidelines_lum_cont.php
"Color & Contrast: Web Checkpoint 12" IBM Human Ability and Accessibility Centre. 1 Jun 2007. IBM. 7 Oct 2007. http://www-03.ibm.com/able/guidelines/web/webcolor.html
"Effective Color Contrast" Dr. Artidi, A. Lighthouse International. 2007. Lighthouse International. 7 Oct 2007. http://www.lighthouse.org/accessibility/effective-color-contrast/
"Web Content Accessibility Guidelines 1.0." World Wide Web Consortium. 5 May 1999. W3C. 7 Oct 2007 http://www.w3.org/TR/WAI-WEBCONTENT

Re:Good use of color and contrast

[careysb]

Just out of curiosity, what's wrong with a blue background except for perhaps being overused? Of course the shade of blue would have to have appropriate contrast with the foreground color(s) being used.

Re:Good use of color and contrast

[halcyon1234]

Blue has a very low luminescence. It contrasts poorly with other colors, especially those that have blue in them. If you have a blue background, no matter what color is in the foreground, it will be harder to see than any other color background.

Re:Good use of color and contrast

[halcyon1234]

A more detailed explanation is available at:

http://colorusage.arc.nasa.gov/guidelines_lum_cont.php

Under the heading Pure blue should not be used for fine detail or background.

Re:Good use of color and contrast

[careysb]

"Blue can be used in most contexts if care is taken to achieve adequate luminance contrast. This can be done in a number of ways. Instead of blue on black or vice versa one can substitute white (or some other high luminance color) for the black. In the next figure the small blue text on the white background is nearly as legible as the black text:"

This is from the page hyperlinked by the previous poster's link. (See: colorusage.arc.nasa.gov/blue_2.php)

Carey

colors

[DriveDog]

Colors and contrasts, etc... can't recommend a book offhand, but try to use colors that can still be discerned as contrasting by people with common color-blindness combinations. There's been a lot of research, some of it from predictable places (IBM, etc.)

Some more recommendations

[Anonymous Coward]

To be a good user interface designer you need to be well readin a number of fields.
Some of the more important books that are not explicitly about UI design are:

- Anything by Edward Tufte

- Ware, Information Visualization

Don't Make Me Think

[oneiros27]

If you want a quick overview, that even your manager (might) understand, see Don't Make Me Think by Steve Krug

It doesn't go too in-depth on stuff, but it'll give you general concepts to consider, and is a generally fun read. It's the first book I typically give to folks new to UI design.

Stay away from anything by Jakob Nielsen

[Wabbit Wabbit]

Despite what others might say, he is a charlatan in the truest definition of the word.

Most of his advice is utter bunk, and his though process is entirely disconnected from logic and reality. I'll give him credit though for building a reputation around himself the way large consulting firms like Accenture have managed to do --a lot of huff and puff, and very little quality output.

I feel this is important to say, because many people are familiar with his name and when they hear someone ask about "GUI" or "usability" their first instinct is to shout JAKOB NIELSEN!

So...whatever you go looking for, don't waste your time on him.

(note: I spent over ten years of my twenty-five year programming career as a gui programmer/usability expert on both retail and commercial software products for some very well-known companies)

Re:Stay away from anything by Jakob Nielsen

[MartinB]

Most of his advice is utter bunk, and his though process is entirely disconnected from logic and reality.

...which presumably is how he got his doctorate, got all those Patents and put together all the academic publications. And if you're playing time served willy waving, then he had your ten years of experience over ten years ago.

Sounds like standard subjective kneejerkism to me, rather than a thought out critique of his methodology. Which, incidentally, only lightly depends on heuristics, and has a lot more to do with objective testing. But hey, you knew that because you've read more than his alertboxes. Oh, wait...

HCI books I used

[manual_overide]

In my HCI class, we used Robert Bailey's Human Performance Engineering as well as a book on paper prototyping that is linked to in the also bought section on the HPE book's amazon page.

The HPE book was amazing. The previous revision was from the early 90's and was still totally relevant because he author doesn't really go into which controls should be used where. It's more about how humans process information and what developers can do to exploit those tendencies to improve usability.

The paper prototyping book was interesting too. It's a neat and cheap way to prototype things. You just draw each function on an index card, then go through and flip the cards while a user "clicks" on buttons and things.

good book

[dweebzilla]

Good book for web based design & simple testing. Don't make me think A Common Sense Approach to Web Usability, 2nd Edition http://www.amazon.com/exec/obidos/ASIN/0321344758/ref=nosim/arm06-20 The ideas in it translate to non web as well - and the price is right.

Re:Windows Vista User Experience Guidelines

[rla3rd]

Downgrade to XP :)

Don't Make Me Think by Steve Krug

[GrayTwig]

I found this book a while ago and really like the principles and ideas. People expect certain things about a web site -- if there is blue underlined text people expect it to be a link. If there is something to be clicked it should look like a button. Very easy read but good ideas.

Re:Don't Make Me Think by Steve Krug

[bynary]

Excellent suggestion. Kudos...

Specific recommendations

[SanityInAnarchy]

I think that book on design might help with more specific recommendations. For example, #1 and #2 are about making things simple, but you don't talk about how. #4 touches on it, but you don't have numbers.

One of the things I've heard is that we can keep track of seven things at once -- so try to keep seven items or less that the user has to keep track of, and add depth if you need to. (If you have 20 or 30 config options, split them into categories.)

The other thing I would suggest is to constantly check out other programs, and notice the things that they do well. This is especially good if you have direct competitors, but also look at completely unrelated programs. You don't want to be constrained by someone else's design, but at the same time, it's nice if things are predictable.

And what someone else said: Know your audience. If you're writing a Linux program at all, pick a GUI library and stick to it, and provide a rich commandline interface. If at all possible, let your users run the program entirely from the commandline, with no X at all, but even if you need X, give us a commandline and a GUI.

Usability made easy

[k.ovaska]

User interface design is quite easy, actually. No need to read books. Here is a short guide.

Use command line interfaces. Users like the command line because it's the most powerful interaction method and users want to be in control.

Using short command names is user friendly, because then users don't have to type so much. For instance, instead of the horribly long name "list" use "ls". However, if you need to choose a name longer than 5 characters (because, for instance, all shorter names are already taken), consider putting one vowel into the name to make it easier to pronounce.

Use lots of command line options: the more the better. Remember, users love to be in control, and what more control would they need than the ability to tell the computer that you want to sort files according to the MD5 sum of the last modification date in UTC+9 timezone?

Documentation is important so that users can learn how to use your programs: thus, make sure you put comments in your C source.

When installing programs, users want an optimized version for their architecture so you only need to provide a source package and let users compile it themselves. You can include a makefile if you want, but do consider leaving it out because compiling the program by hand is an excellent way for users to get familiar with your program and its source code.

The Non-Designer's Design Book

[Rikardon]

Norman's book is great, but it's NOT a GUI design book. It's a theory book, albeit a very understandable and accessible one. I would recommend it as a general background for understanding human limitations so you can consider those in your GUI design, but I think the OP is looking for something more immediately applicable.

The best general-purpose design book I've ever read, by far, is Robin Williams' Non-Designer's Design Book (Second Edition out now; Third Edition due next month). It doesn't deal specifically with GUIs either, but it IS immediately applicable to all sorts of design, GUI and non-GUI. As the former head of the usability group at a large hardware and software firm, I've used principles from this book as the foundation of a one-hour training course I delivered to over 60 developers at a former employer.

At the end of 40-45 minutes of instruction, all developers I've taught are able to apply the principles from NDDB to redesign a particularly hideous sample UI from the old IBM Aptiva PCs. At the start of the hour, none of them can usually explain what's wrong with the existing UI, though all agree it's hideous. By the end of the hour, everyone can ID what was wrong, and come up with various ways to fix it.

The book is short, cheap, and brilliant. It's the best starting point I could suggest; I've never found a better one.

Re:The Non-Designer's Design Book

[Intron]

"The book is short, cheap, and brilliant."

What a coincidence, so am I!

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

Apple's Human Interface Guidelines

[jeff4747]

Back in the day, I read this. It was a very good GUI design book.

Re:Spolsky's "UI Design." High Priority Stuff, Yum

[pg--az]

Amazon says 159 pages and the cover is different - my old copy is 144 pages, but 144 Very Good Pages - High Priority Advice, much of it simply not to be found in my other thicker books.

Re:What I like to do.

[The_reformant]

yeah media player is fugly

The all important buttons

[Cannelloni]

Where ever possible, use verbs in the imperative form (Print, Save, Preview, Submit) on buttons and in menus, not just OK, Yes or No. This is a common error i GUI design. Keep all tests short, simple and to the point. Avoid jokes (the joke may be funny the first time you see it, but after that...). Look at how other people design their software, and steal ideas. Focus on primary functions, not features. For positive and non-destructive actions, the buttons should be highlighted so you can just press Enter to activate them. Cancel always stops the proposed action. On a Mac system, the positive action (Save, Shut down, Print) is nearly always to the left on the screen, but under windows in the center or to the left... Under Linux it seems to vary a great deal. Use simple and logical keyboard shortcuts that preferably consists of two, not three, keys. This makes routine actions simple for experienced users. Good luck!

Books will not teach you this

[coryking]

There exists no book that will teach you good user interface design. Buying a book about "user interface design" is like buying a book on "Learn Visual Basic in 24 hours"--too sepecific. You want the usability version of "code complete" instead--one that is all about theory and "why".

The most incredible and exciting thing about good design is it involves lots of *watching* and *listening* to the people who will use your software. There are no rules of interface design besides "dont violate the costraints of your medium (i.e. dont roll your own widget set"). Like "the rule of thirds" in art, those too are only soft rules and can be broken if you know what you are doing.

Good usability comes from good requirements gathering. You have to get out of your office and *listen* and *watch* the people who will use your work.

The book should spend very, very, very little time on heuristics and "rules of good interface design" because quite frankly, there are very few rules. The best book will probably not have screen shots of stupid error messages; it should be mostly wireframes and paper prototypes. The best book will only have about 1 sentence about fitts law. "Rules" are obvious; users are not.

You want a book that covers how to interview. The book should cover how to write a good persona. The book should talk about how to *correctly* screen for participants (like why you always ask the risky questions like somebodies income last and why you bracket it). The book should talk about how to *correct* do a usability test so you get valid results (for example, never try to correct "mistakes" or help them if they get lost... instead always ask what they expected to find and than shut up and watch). The book should dedicate an entire chapter to cardsorting and why it is so damn useful. The book should dedicate at least half a chapter to paper prototypes.

You do not want a book on "how to write a good interface". You need theory and practice. Usability is the most fun thing you can do in computing. *Nothing* is more exciting than spending two hours watching how somebody works and thinking of about a billion ways you can improve their experience in a way they would appreciate.

Agreed. It is an easy, quick read too.

[CFD339]

I've found it very helpful in understanding key issues, and pointing out the common mistakes.

Web design

[Xest]

Learning about web design is a decent idea because many of the ideas of good website design can also be applied to any applications.

Specifically look up things on web usability and web accessibility, you'll be amazed at how much of it is relevant to non-web applications. In terms of accessibility the web content accessibility guidelines (WCAG) are a good started.

Of course, HTML and CSS is a fairly straightforward playground to practice layout and design also, especially as pretty much every OS has a web browser and text editor to hand to try things out with!

Qt

[debatem1]

some people love it, some people hate it, but Qt is good for the novice UI coder with some development experience. Trolltech puts out a book on Qt 4 that is very good. As far as style, DO YOUR USE CASES. Understanding your users' needs is more important than including every last option. Oh, and a good looking UI will not win you fans as quickly as a well behaving UI- but it helps.

Edward Tufte

[Anonymous Coward]

Edward Tufte is mostly known as a data-heavy charts & graphs guy, but his ideas are about explaining complicated things visually, which is all a GUI does. His books are amazingly well done, I recommend the whole set. "Beautiful Evidence" is the latest.

Spolsky's "User Interface Design for Programmers"

[the_olo]

Joel Spolsky's User Interface Design for Programmers points out numerous user interface design issues that are non-obvious to programmers. I highly recommend it.

& Stick to conventions!

[Anonymous Coward]

I agree w/ everything you have said, and would like to add CONVENTIONS.

I did a lot of interface work in Comm. College. I get miffed when I see that Ctrl-C copies, but Ctrl-V doesn't paste! Stick to the things that are common. Back? Undo? Step back? USE THE Z KEY!

Mostly though, the KISS rule is akin to godliness. Let them customize in a customization screen, though the app should work FLAWLESSLY w/o ANY customizations. Categorize the Customize screen as much as you can so people can logically drill down to what they need.

Also, look at scoping the changes. If it is a larger system, w/ multiple users, this may be a necessity.

A good rule for a complicated system is to use Profiles and Roles. Where a Profile can be user changeable customizations
Roles are Admin Changeable customizations. This is so the admin sets how "simple" their specific users need to be.
That's usually far more complicated than needed though, but if you get to that case, please for the love of your favorite deity, make it export/importable so that upgrades, etc. don't wipe profile work. I have seen this system work good, and bad. One particular application I work with had profiles so convoluted, and time consuming to set up, and a version change tossed it all!

Grammar Nazis be warned. I went two publick skewl, and passed all mi class's

Tracking seven things

[Anonymous Brave Guy]

One of the things I've heard is that we can keep track of seven things at once -- so try to keep seven items or less that the user has to keep track of, and add depth if you need to. (If you have 20 or 30 config options, split them into categories.)

As a point of interest, that's mostly an urban legend in this context. See the magical number 7±2.

That's not to say that keeping your options organised into reasonably sized, coherent groups is a bad thing, of course. It's just that the number seven isn't quite as special in this context as a lot of developers seem to believe.

Also, notice unconscious linguistic imprinting...

[AntrygRevok.net]

In English, we generally unconsciously associate "holding-back" with the left-side of the page
& "going/doing-it" with the right-side of the page
( check the graphology stuff, used in criminal-cases btw )

If I could have one single wish answered in Linux/KDE it'd be this:

MAKE THE HOLD-BACK OPTION ALWAYS BE ON THE LEFT FOR ENGLISHERS ( & similar L-to-R languages )
and the corollory
MAKE THE "COMMIT/DO-IT" OPTION ALWAYS BE ON THE RIGHT

if that one single thing were implemented,
it'd mean I could react to a decision-box window by instinct,
rather-than being stopped every time to
discover what the hell goddamn variant of "flow" this particular window implements.
( do they use /dev/random for it?
how many millions of us are sabotaged by it every hour? )

The best book to get for UI design? 2, actually:

Don't Make Me Think ( made for web-meisters, but it's still UI stuff ) by Krug
( Advance Book Exchange ( second-hand books search ) http://www.abebooks.com/servlet/SearchResults?sts=t&tn=don't+make+me+think&x=0&y=0

: )

& The Design of Everyday Things

Re:What I like to do.

[chaoticgeek]

meh... My classes on windows server we are expected to use the command line, they show us how to do it the gui way and the command line way.

a different view

[sohp]

I'm going to suggest a book not about computers or software at all, but about visual communication: Understanding Comics. Jakob Nielsen endorses it (that might not be a positive recommendation for some of you..).

Re:a different view

[Plaid Phantom]

While a great book, I don't know that Understanding Comics is particularly relevant to desktop application design.

If you're designing a visual interface for a game or something like that, however, then it could be something to look through with regard to motion, animations, and communication.

Magic Ink by Bret Victor

[troytop]

Check out http://worrydream.com/MagicInk/

The ubiquity of frustrating, unhelpful software interfaces has motivated decades of research into "Human-Computer Interaction." In this paper, I suggest that the long-standing focus on "interaction" may be misguided. For a majority subset of software, called "information software," I argue that interactivity is actually a curse for users and a crutch for designers, and users' goals can be better satisfied through other means.

But the customer isn't always right...

[Anonymous Brave Guy]

The problem is that what users want and what they need may be two very different things. To give a simple example, a lot of users still think they work faster with the keyboard than the mouse in a typical office application like a word processor or spreadsheet, despite the fact that most of them are measurably wrong when observed objectively.

As a sales pitch, giving users what they want (i.e., what they think they need) may be smarter than giving them what you know from evidence that they actually need. Then again, sometimes that's just a short-term illusion. If you want to make working software and get long term satisfaction from your users, you might be better to rely on the research. After all, "everyone knew" that the Office 2007 interface was going to suck because it was so different and they'd have to relearn everything... until they tried it.

Jakob Nielsen

[Anonymous Brave Guy]

May I ask what you have against Nielsen? Aside from his rampant self-promotion in recent years, which ironically has reduced the value of his own web site according to his own principles, much of his real content has always struck me as quite useful and based on objective evidence.

Re:Jakob Nielsen

[scafuz]

Well.. your questions gives itself a good half of the answer :)
beside that, I find that usability is, usually, just a matter of common sense. The problem with Nielsen's books [and maybe others that I haven't read] is that makes you think that "your opinion"==="common sense" so that you start making things in your own way, thus messing out UI elements in your interfaces.
Maybe I'm wrong, but when it comes to User interfaces, and, to be onest in so many other aspects og software engineering, anyone should stick to his own job: a programmer should program, a designer design and so on. Mixing things isn't a wise move [I know...this would open a million post worthy thread...]
If you need cook a pie, buy a book of recipes not a book which just describes the ingredients

Don't Make Me Think

[egandalf]

"Don't Make Me Think" is an absolutely fantastic book which covers the basics of good design in a clear voice. It contains images as samples and outlines why they are good. For someone who is old at the tech side and new to the design side, this book is a must-have.

2 books

[Anonymous Coward]

Consider:

Don't Make Me Think: A Common Sense Approach to Web Usability (2nd Edition) by Steve Krug
A plane ride book but worth the price.

Designing the Obvious: A Common Sense Approach to Web Application Design by Robert Hoekman Jr.
A lot less detailed thank About Face 3 by Alan Cooper (which is also a good book).

Bill Buxton

[james1983]

Bill Buxton's "Sketching User Experiances" is well worth a read if you are trying to do UI design. You might also want to have a look a employing a User Experiance/Design specialist.. they are worth every penny.

Maybe, maybe not...

[Fjodor42]

Designing the User Interface (Amazon link) is praised by many, but hated by equally many.

Personally, I made it a point to burn it (literally), but if you can look beyond the silly metaphors (or, as I'm told, get the 3rd edition), you might get some insights. On a personal note, though, I would recommend that you look at it at your local library before purchase...

Best regards,

F

Great expectations

[Anonymous Coward]

The one element of UI design that must be respected above all else is user expectation. A great UI is one that always gives the results that the user expected. If the user clicks a button they expect to perforum action A, and it performs action B, that frustrates the user. That's what makes people say "this is a bad UI."

What all that hinges on is knowing your target customers. If your customers are professionals who make a living using this software, your primary goal is creating a smooth flowing powerful UI that lets the user work quickly and efficiently. In that case, you can probably get away with a little clutter and lots of advanced features right out front. If your customer is the average PC user, you need a simple UI that is as clearly labeled as possible, very responsive, and shows only what is required to make your app perform its primary expected function. Google's website is a great example of how to do that. It's a search engine, and its primary elements are unmistakably the text entry box, and the search buttons. Everything else is much less prominent on the page, and your average user loves this because they don't care about all the advanced powerful features of google's search engine. They expect the page to search for the text they enter, and it does that with just a couple clicks.

If you have trouble making a good UI that suits a novice user because you yourself are an advanced user, consider getting a less technically minded friend to help you with the design. Somebody who isn't as familiar with computer software will likely give you plenty of UI design ideas that you might not have thought of otherwise.

Re:Pig Toaster?

[maestroX]

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

Oink! a pig toaster would feature a big lid on top.

3 simple rules

[IdeaMan]

There are just 3 simple rules to Programming and UI design:
>Consistency
>Consistency
and
>Consistency.

If it's a program and you didn't KISS, if its consistent then it's easy to fix.
If your UI shortcuts, menu layout, menu options, window placement and mouse behavior are the same as the other applications the users are familiar with, learning your app won't be a problem.
Consistency is very difficult in programming. What happens is that you learn as you program, then should go back and update the old to match the new, better way of doing it.

tufte

[The Shrubber]

Speaking as a total ignoramus on UI design, I would also suggest reading everything and anything by Edward Tufte (the Visual Display of Quantitative Information might be a good start). It won't give you any special insights into UI, but it should help to reinforce the point that making a good UI isn't about dumbing things down (a common geek misconception), but having a very strong sense of respect for the user. Good luck! (And the Norman book that everyone recommends is also a great read)

Mod parent up

[Anonymous Coward]

Mega dittos!

Grandmothers rule

[Anonymous Coward]

I've always believed that if your granny doesn't understand it...no one will.

i) Keep it uncluttered
ii) Keep Advanced options tucked away, particularly those ones that aren't generally going to be used by the average/novice user
iii) KISS (Keep It Simple Stupid)

Testing

[Bombula]

I'm surprised you didn't mention testing, and neither have any of the other up-modded posts. Testing is a VERY effective way to implement this addendum to your list:

2.1)In order to 'just work' the UI must function exactly as expected. Expected by who? NOT by you, the coder, but by the user. Which user? The least experienced user you can find. Their expectations will be pure, unfiltered, unbiased, uninformed, and will lay every flaw in your UI design bare. Want to know how the UI menus should work on your cell phone? Give it to grandpa and ask him. Why? Because he won't put up with clicking 18 buttons through a menu tree to get to the second most commonly used feature of the device.

Ah, but why bother to test if you have good design principles like those in your list - KISS, form-follows-funtion, eliminate as many steps/clicks/motions/decisions as possible in any function or process, etc? Because sometimes it just isn't possible to KISS it or make it 'just work'.

90% of your UI will be made of up things you can apply good design principles to. That 90% will utilize 1% of the user's time and effort and cause 0.01% of their frustrations with the device. The 10% of the UI you can't apply your principles to will consume ALL the rest of the user's time and effort and be the source of ALL of their frustrations. THIS is what you need testing for: as long as something works perfectly intuitively - or exactly how you would expect it to work - then it will seem effortless and cause zero frustration, even if it isn't simple or doesn't just work automatically.

Re:Testing

[jgrahn]

In order to 'just work' the UI must function exactly as expected. Expected by who? NOT by you, the coder, but by the user. Which user? The least experienced user you can find. Their expectations will be pure, unfiltered, unbiased, uninformed, and will lay every flaw in your UI design bare. Want to know how the UI menus should work on your cell phone? Give it to grandpa and ask him. Why? Because he won't put up with clicking 18 buttons through a menu tree to get to the second most commonly used feature of the device.

That reminds me of a Peter da Silva quote I stumbled on yesterday:

Apple's original usability studies contradicted the Xerox ones. The difference? Xerox studied people who were used to the idea of computers and user interfaces. Apple studied random lusers.

If I am forced to use a GUI application, I sure as hell don't want one tested on computer illiterates. Would I buy a knife tested on 6-month-old toddlers? A bike tested on overweight grandmothers? A single malt tested on teetotallers?

Re:Testing

[dstar]

Luckily, I don't think we have to worry much about that last one. I'm pretty sure that wasting a good single-malt on a teetotaler is illegal pretty much anywhere you'd actually try a single-malt from. I mean, it probably isn't in Utah, but... would you buy a single-malt made in Utah?

For values of "everything"

[cicho]

For values of "everything" that don't include "iTunes". Just don't copy that PoS.

(Is iTunes as bad on Macs as it is on Windows? And is iTunes a representative piece of software by Apple?)

Dashboard for Controls

[zarozarozaro]

In the AV world we use this...

http://www.infocomm.org/cps/rde/xchg/infocomm/hs.xsl/avindustry_1157.htm

Have a reason for the GUI, don't reinvent editor

[Killer Eye]

Ask yourself: is the GUI adding anything over a text editor? In other words, never "literally translate" a file to a GUI. If your file is a bunch of name-value pairs, your "GUI" shouldn't just be a list box that lets the user edit strings.

Some good starts (far from complete):

1. Filter information; hide advanced material by default, and maybe force the really advanced stuff to require a separate text editor. Use progressive disclosure, so that only a subset is ever visible.

2. Present information, don't just map it to the file. For example, maybe you physically store a color as "r: 0.6, g: 1.0, b: 0.75", but you wouldn't give the user an R field, G field and B field: you'd show the actual color, and allow editing in any way supported by the system (e.g. on a Mac you can enter CMYK, or even pick crayons!).

3. De-jargon your terminology. For example, if your file says "alpha: 0.7", your GUI should say "transparency" or "opacity" and use a slider with a live graphical sample or other more intuitive method to set the fraction.

4. Avoid editing strings most of the time. Even if a setting "can" have any value, it is often useful to give the user a menu of common values with an option to add anything else they want. For example, why not keep track of recent values a person has been using?

5. Don't force users to use your crappy text editor for really complex stuff. Usually, if your file format is at least plain text, this is avoidable. But if you store some huge paragraph of text in a database I can't see, and your GUI gives me the crappiest editor imaginable as the only way to change it, then your GUI is causing more problems than it solves (and the real project should have been to write a text importer for your opaque database).

Amiga User Interface Style Guide

[DruggedBunny]

Commodore's Amiga User Interface Style Guide was really good in its day, and though of course Amiga-specific, it pushed hard for consistency and clarity of communication to the user in the little details such as when to 'gray out' inapplicable menu items, buttons, etc:

Amazon link

I think it's still worth a read if you can get it cheap. Amiga applications benefitted greatly from the Style Guide, even if criticism of a particular developer's app might have come only from a third party who'd read the book. Developers appreciated the way other "Style Guide-compliant" apps worked so nicely together and adapted their programs to suit, resulting in the majority of applications becoming consistently laid out, and therefore very intuitive, for the end user.

Okuda got it right...

[who's got my nicknam]

LCARS. Nothing more needs to be said!

Observe a user

[tknd]

So far most people here have said "go read HCI book Z" or offered their own opinions on what you ought to do. Reading the books is a good start but I think you will find that after going through the material, you'll come across a lot of things that make sense yet, try to apply them, yet still fail miserably in your endeavor. That's because nobody has told you the hows. They've only told you the "whats".

So ultimately, here is how you can learn the "how":

Take a piece of software or some gadget. It can even be a web page or something like a GPS receiver. Now that you've decided, write up a couple tasks for using the object. If it is an online furniture store for example, say "task 1: add king size bed with dark wooden frame to cart". And keep going until you've got a pretty realistic list of tasks someone would do using that software or hardware.

Now go find 3 to 4 of your friends who aren't really geeks or nerds. Try to pick from a variety of people: females and males, old and young. Usually it is best to get people that are not familiar with the object you're testing.

Now sit down with each of them individually and say plainly, "I'm conducting a usability test. My objective is to observe how people use this object. The goal is not for you to complete each task, but for me to observe how people can or cannot use the object's interface." Once they understand that they are not being tested, but rather the object's interface, start with your first task you thought of. While they are performing the task, tell them to try to "think out loud" so you can have a better view of what they're trying to do. Don't tell them how to complete the task or anything about how to use the interface. When they ask a question about how something works or what they should do, just say "I can't answer that" or "I don't know." Don't put them down, and if they give up or they don't think they can complete the task tell them it is all right and move on.

Your goal in this process is to observe how people (humans) use an interface. That is why you cannot tell them how or give them any instructions. You simply say "this is the task" and observe. As they're working you try to ask open questions about what they're thinking or why they did something even if it was lightning fast or snail slow. If they click on something that is obviously wrong, don't tell them "that's wrong", instead ask them "why did you click on that?" or "did that do what you expected it to do?" You are trying to figure out their thought process to hopefully gain insight as to why they are not completing the task. Keep in mind that there is nothing wrong with the person, but rather that the problems exist in the interfaces. You won't get anywhere if you start coming up with reasons to blame your users for their faults in using the interface.

The results are very eye-opening when you first do this. In my first study we came up with a list of tasks and thought they were pretty simple. But when we observed different people attempting the tasks incredibly simple things had all sorts of problems. On many tasks the people failed or couldn't complete. On some tasks that seemed complex, people were still able to finish. In short, it is actually pretty common to see things all over the map on an untested and new interface.

This will do a number of things for you:

• You will have learned how to conduct a face-to-face usability test: you come up with a list of common tasks for your software, find a bunch of people who are not familiar with it, have them run through the tests while you take notes or even record them on a camera.
• You will see first-hand that designing interfaces is hard and that people come from all sorts of different backgrounds which influence how they use the interface.
• You will hopefully find areas where the interface is particularly weak: this usually involves areas where the users simply could not complete the tasks.
• You will hopefully find areas where the

User interface design for mere mortals

[Anonymous Coward]

User interface design for mere mortals / Eric Butow.

This book is a primer that puts together the leading practices and ideas about
user interface design and usability design and testing into a "big picture"view
of how people can and should design and implement user interfaces that
your customers will enjoy.
The book begins with grounding in user interfaces so you understand how
we got from the beginnings of user interface design to where we are today.
Then the book delves into designing user interfaces and usability testing for a
product; that product can be a hardware product such as a printer, a software
interface, or a Web site.

Quicktime player...one of the worst designs ever.

[Joce640k]

Quicktime player won all sorts of awards for "design" but it's a total piece of crap. All form and zero function - unbelievably basic mistakes/problems. Take the opinion of fashion designers with a pinch of salt.

A book...? How about Joel Spolsky's "User Interface design for programmers"?

http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html

Tufte-Dashboards and headlights.

[Anonymous Coward]

"Any particular one of the four books that people might know to be most useful for me, or a suggested reading order anyone might have?"

They're all good books but you may have trouble going from theory to practice. A book I'd recommend A website I'd also recommend Here's some more. A nice tool for those doing 3d flash and it's open source. Have fun!

Re:Quicktime player...one of the worst designs eve

[cicho]

For that matter, Quicktime player (an earlier version) feaured prominently and deservedly on Interface Hall of Shame.

Second the book suggestion. No need to agree with everything Joel Spolsky says, but at the very least it's a good way to jumpstart thinking on avoiding UI annoycances.

Don't Make Me Think

[IronXAres]

Try out "Don't Make Me Think". It is a great book, showing a variety of websites (practices will carry over to other apps), and details the author's thought process and redesign of the sites to make the GUI more intuitive and accomplish the goals of the site. It really helped me out and made me think of things in a completely different way.

There are only two rules

[bandmassa]

1. Keep it simple and consistent. Even technologists get tired of complex user interfaces (compare Logic 8 with ProTools for simple v. complex) let alone ordinary users.

2. Obey rule one of die.

Don't waste your money on books

[SAABMaven]

It's all primitive crap. I trust people who rehash others' material and republish it in order to make money, more than I trust people who want to help you by feeding you with more primitive crap.

Why do I say primitive?

Because today's GUIs have not evolved one iota since the original rip-off from PARC. Software has followed the cultural landscape: suburban sprawl, huge resource drains, high social cost. 'Make 'em wait' is the watchword of the day. And give 'em carpal tunnel; force repetitive motions, unnecessary click-throughs etc.

You'd be better off:

1. Follow your instincts;

2. Completely decouple your UI from the business logic of the app so that the UI can be easily replaced by the user; allowing users to switch UIs at need. (even provide a scripted command line version);

3. Talk to the users!

Talking to the users is the biggest no-no in the field. You're supposed to tell the users what THEY want, and involve Marketing to assimilate them. As an Architect, I broke this rule in 1998 when I talked to stock traders on the floor of a 'major city' stock exchange; the result was a scripted, 'skin' UI that could be configured by the user (e.g. they could drag controls around the screen and resize them, make them left- or right-hand, how sinister) and rescripted from the server on updates. It was ahead of its time, was written in TCL-TK, so I could show running prototypes to the users and then immediately program in their suggested changes and improvements so they could experiment with them right then and there.

Alas, 9/11 came and went, and the project was bangalored, rewritten in Java and turned into expensive bloatware. Good news is that it had the buy-in of the traders, who knew that they had their input and that their concerns were addressed. Operations bought in because it was instrumented, out-of-box (no stupid monitoring scripts running on yet another Unix host --- today's Architects try to add as many moving parts as possible). Even Management bought in because it was simple and cheap, got Linux onto the Floor and got expensive HP servers off of the Floor.

Cheers!

Books vs Reality

[Burntfinger]

If at all possible get a real end user involved early on in the design process. My late wife and one of my best client's office manager were my testers. If they could understand it, I rarely had a problem. Other than that, just keep in mind that the purpose of a GUI is to make life easier for the end user, not test their technical knowledge.

Gooey design

[FreqShow]

It may be overkill for what you want but have a look at http://www.uie.com/

Re:What I like to do.

[lm317t]

"GUI interfaces are easier for input (no switches to remember, easy to navigate, etc.)
Command lines are easier to schedule and include in custom batch scripts
Command lines allow input prior to the program loading

Both have their place.

The big problem I have is that most administrators* that rely on the command line (in particular DBA's using SQL*Plus) don't help themselves out and manually enter that string of commands instead of batching them up or writing a GUI to simplify their normal tasks. (* administrators that I have personally encountered, your experience my be different).

Layne"

You forgot one major thing. Command line programs also have versatility that gui programs can never have. Think of all the things you can do with dd, netcat, ssh, used in combo with can take stdin/stdout. With one line I can do things like search pdfs or MS Docs for a string and have them print the matching line or send it to a file. I could stream MP3s or soundcard in/ouput from one box to another, incrementally backup/mirror a directory offsite, etc.

This versatility is why we love our command line based utilities and why I think excessive use of MS Windows stifles innovation and creativity. GUI only programs must have all possibilities thought-out for a program ahead of time. Because of these reasons and others, it seems to me that nearly every program should take command line switches and handle stdin/stout appropriately. Guis are great for simple mindless tasks, but the commandline unleashes creativity.

Adobe melt down on e-books and open source

[vidaddy]

Two years ago I was directly hooked to Adobe Systems executives on a variety of subjects. Behind their Video Beta wall I challenged Bruce Chizen to get Macromedia Flash or face online annihilation. At the same time I requested an e-book GUI for their Acrobat platform that would allow for a simple scroll across panoramic e-books. I ended up assigned to this arrogant project manager named Alan P[isser] who wrote me saying that "if this is going to happen, it is because I am going to make it happen!" Wholly avid response! I also asked that they offer the outdated code for Premiere 6.5 into Open Source so the Linux community could have a slick video editor. Amidst record profits [or so they say] Adobe shined me on both ideas. Bob Kiger Videography Lab Oceanside, CA http://videographyblog.com/

Re:Good ... Tips (Is this about Linux?)

[killfixx]

I'm not trying to start anything but...this entire comment seems to talk about linux gui developement during the previous 15 or so years...

Only recently has GGUI (the extra g is for good) been a consideration in OSS...I'm not trying to start a war...Just...

"* Always use bizarre, scary sounding code names for the name of your application. For best results it should be an acronym for something that doesn't make any sense, and the acronym should be recursive."

hehe!! :)

Palm Reading

[BlindSpot]

There are some great UI design tips in the Palm OS manuals. The gist is that because (older) Palm devices have screen and graphical capabitilities that are much more limited than the PC, you really have to think about how you are going to present your UI. The tips there provide a guide for what to focus on, and the concepts extend well into the PC realm.

Can't remember the exact book title but you can find it here (NOTE: free signup may be required).