Slashdot Mirror
GUI Design Book Recommendations?
jetpack writes "I've always hated writing user interfaces, and graphical user interfaces in particular. However, I suspect that is largely because I have no clue how to write a good one. I don't mean the technical aspects, like using the APIs and so on. I mean what are the issues in designing an interface that is clean, easy to understand, and easy to use? What are things to be considered? What are things to be avoided? What are good over-all philosophies of UI design? To this end, I'd like to pick up a book or two (or three) and get my learn on. I'd appreciate some book suggestions from the UI experts in the Slashdot crowd."
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.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
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.
Wake up to find out that you are the eyes of the world...
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
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.
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.
by chris crawford..
its great.
google books
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.
What are the issues in designing an interface that is clean, easy to understand, and easy to use?
/Appropriately, my captcha was "miseries."
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.
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
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..
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
...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.
Live today, because you never know what tomorrow brings
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.
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.
Brackets contain world's first nanosig, highly magnified:[.]
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.
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.
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.
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.
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.
I'm a consultant - I convert gibberish into cash-flow.
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.
--- These are not words: wierd, genious, rediculous
It should combine form and functionality
Wrong. "Form follows function" is one of the main tenants of good design. Make your toaster as pretty as you like, but don't forget that its function is to make toast, with the least amount of effort for the toaster user as possible.
If you make your toaster so that it looks like a pig, fine, but if you use the pig's snout as a lever to make the bread go down, you have a shitty design. It should be obvious to the user HOW to make the bread go down.
If your user needs to RTFM, you have failed in your attempt to design well.
-mcgrew
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
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
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?
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.
Irony: Agile development has too much intertia to be abandoned now.
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 :)
which is totally what she said
Don't forget to have a good look at the Interface Hall of Shame for examples of what not to do.
-- Ed Avis ed@membled.com
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 only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
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
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
No sig today...