Slashdot Mirror
Improving Software Usability?
kevin_conaway asks: "Software usability is one of the hardest things to get right. Writing good, usable software is the holy grail of software development, yet few developers give it more than an afterthought. As a professional developer, I delight in writing software for other developers but shy away from writing an interface that the end users will see. What resources/books are recommended for improving your Human Computer Interaction (HCI) / software usability skills?"
http://developer.gnome.org/projects/gup/ This is definitely worth a read. Many people who are good programmers aren't necessarily good at user interfaces, or worrying about how people will interact with the software. That is an area that open source software really needs to improve on, both in efficiency in usability, and in aesthetics.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
The best resource for making sure your software is usable is to watch people use it. While large companies can afford professional UI designers and formal usability studies, even a humble F/OSS developer can do some simple UI testing. ...?" and it's a good way to start finding bugs that only a user will discover.
When I'm working on software that is intended for users who are not developers or otherwise computing professionals, I usually try to get a regular user to sit down with my software for a half-hour or so and I watch them use the software. Generally, I just say something along the lines of "hey, wanna do me a favor? play around with this program for a bit and tell me what you think". Then watch over their shoulder. Generally this is a good way to get a list of what sorts of things are poorly placed "how do I...?", things that are confusing "what is this?...", features that users will like "can I
A few tips that I've found doing this include
If any option is unavailable then it should be obvious WHY it's unavailable.
No matter how obvious your icons are, they should ALWAYS have text with them.
Avoid dialog boxes as much as possible
If you make your program look too much like another program, then you better make sure it looks and works exactly like that program. In other words, either stick completely with the standard way of doing things, or do it completely different. If you take some common UI element and tweek it, then you'll just confuse users. Menu bars tend to be the most common violators of this.
Understand color. A lot of applications throw colors around willy-nilly, if you are going to use color then study up on color theory and learn what colors go together, what colors are calming, etc.
Famous Last Words: "hmm...wikipedia says it's edible"
Jef Raskin's The Humane Interface
Did you ever notice that *nix doesn't even cover Linux?
I recently read "About Face 2.0" I found myself dis-agreeing with some of the details and felt there were a few ommisions but the definitions of software was sound
Also Joel on software has a great book excerpt online to get you in the mood
About face link
Joel book excerpt
Designing from Both Sides of the Screen. Worked really well for the project I worked on, and it's a great process and implementation book.
It's not that I'm asking the big questions, it's that I'm asking lots of small ones.
I couldn't agree more. As a systems analyst and systems engineer, the first thing I do is spend at least a week working with and observing the people (workers) that will be using whatever I design. After I have the semi-final product, I do the same thing again, this time observing and talking to them about the program. Sometimes a rewrite of the UI is required and I don't have a problem with it on my end. If they are unhappy with the product, they won't use it or will use it reluctantly which is unacceptable in my book. The guts of the program are easy, the UI can be very hard. It's more about psychology than engineering in my book.
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
These are two guys who have some good stuff to say about usability - Jakob Nielsen (http://www.useit.com/) and Don Norman (http://www.jnd.org/) - Don Norman is the author of 'The Design of Everyday Things', mentioned above.
Also worth a mention is Joel Spolsky - http://www.joelonsoftware.com/
If you want to that the basic principles, simply go with the Apple Human Interface Guidelines. Yeah I know, sometimes Apple do weird things too... But the first part of the book (the first 3 chapters) contains the basic information you need to create a good interface, totally platform-agnostic. It's been my guideline for years, since the System-Finder times. *sigh* back then the interfaces were easy and there was no brushed aluminum to foil the day.
r ience/Conceptual/OSXHIGuidelines/index.html
... so I suggest you go for the "Original" Classical environment Human Interface Guidelines book for the first two appendices:
i nes/HIGuidelines-2.html (on total bottom of page)
http://developer.apple.com/documentation/UserExpe
That version contains updated and modern Part I for the super buzzword "U-Ex". But they decided they did not have sources anymore
http://gemma.apple.com/documentation/mac/HIGuidel
The resources are relatively adequate, but the bibliography extends to much more than the basics, it covers all the "why's" and "how's". It predates Mac OS, though, so the books were mostly rewritten, but the basics are still prevalent on many topics.
IIRC, you have to click "Resample" in the Image resize dialog to actually resize the image in pixels. Not exactly intuitive, but it is there. I think PSE4 gets a lot right in the UI in general, but it has some rough edges.
If you're more interested in practical GUI advice, I highly recommend GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers (not a referral link). ISBN: 1558605827
The book goes in-depth on the basics of good GUIs laid out using your standard widgets (little, if any, talk of bleeding edge HCI theory). It gives tons of examples of what the author views as good and bad GUI practices. Some of the things he cites are more nitpicky IMO, but overall it's a valuable resource that'll make you more aware of the common pitfalls of GUIs and how really good GUIs are laid out. It also talks about proper messages to display to the user, like don't present a user with a yes/no question and give them OK/Cancel as their buttons...
http://www.ok-cancel.com/ is a great site for non-technical, insightful discussions of user interfaces; plus a great web comic on the subject.