Forgot your password?
typodupeerror
GUI Software Books Media Programming Book Reviews IT Technology

User Interface Design for Programmers 331

Posted by timothy
from the but-programmers-don't-need-interfaces dept.
ellenf contributes this review of User Interface Design for Programmers. "Aimed at programmers who don't know much about user interface design and think it is something to fear, Joel Spolsky provides a great primer, with some entertaining and informative examples of good and bad design implementations, including some of the thought process behind the decisions. Spolsky feels that programmers fear design because they consider it a creative process rather than a logical one; he shows that the basic principles of good user interface design are logical and not based on some mysterious, indefinable magic." Read on for the rest of ellenf's review.
User Interface Design for Programmers
author Joel Spolsky
pages 144
publisher Apress
rating 8
reviewer Ellen
ISBN 1893115941
summary Aimed at programmers who don't know much about user interface design and think it is something to fear, Joel provides a great primer, with some entertaining and informative examples of good and bad design implementations, including some of the thought process behind the decisions. He feels that programmers fear design because it is a creative process rather than a logical one and shows that the basic principles of good user interface design are logical and not based on some mysterious indefinable magic.

Spolsky's light writing style makes this book an easy read, and his personal stories and anecdotes help make his thoughts on user interface stick in your mind when you're done reading. He provides programmers with a few simple guidelines to follow, such as "People Can't Read," and "People Can't Control the Mouse."

His focus on the logic of good user interfaces and his push to develop a good user model is bound to resonate and get programmers to think about making their interfaces logical from the user's perspective, rather than the perspective of the inner architecture, which the user could typically care less about.

The reminder to focus on the tasks the user is trying to accomplish rather than the long feature list that usually gets attached to product specifications should be read by product managers as well, of course. In fact, the absence of specific platform details makes the book a good read for anyone involved in software design -- with the caveat that it is not aimed at people with much design experience. This is a great starter book and makes the process understandable, friendly, and fun-sounding. (One of the things I appreciated was how much fun it sounds like Spolsky has when he's working.)

Spolsky encourages showing the in-progress software to users and watching them use it. I think one of his best points about usability testing is that if the programmers and designers cannot bother to watch the users during the testing, they're unlikely to gain much from a thick report by a testing lab. He encourages simple, quick, and casual usability testing, something even the smallest firm could afford and from which they would could draw useful improvements.

If you have much design experience, you'll find this book a bit basic, but even then the examples are worthwhile to read and remind yourself how a good idea can be poorly implemented sometimes -- usually by taking it too far! I was personally hoping for some richer comments about designing web applications, but if more people start paying attention to the basic guidelines he's covered here, web users will benefit.

In summary, the book is aimed at programmers without much design experience and Spolsky does a great job of hitting his mark. I think product managers without much design experience would benefit as well, as it provides a good basis for thinking about user interface design.


You can purchase User Interface Design for Programmers from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

User Interface Design for Programmers

Comments Filter:
  • Re:$9 cheaper (Score:4, Informative)

    by SoCalChris (573049) on Wednesday October 01, 2003 @12:34PM (#7104415) Journal
    Bookpool has it $2 cheaper than Amazon, and you're not giving business to someone who is abusing the patent system.

    http://www.bookpool.com/.x/ejmrmq9fa6/sm/189311594 1 [bookpool.com]
  • try before you buy (Score:4, Informative)

    by Henry_Doors (472185) on Wednesday October 01, 2003 @12:41PM (#7104488) Homepage
    You can read nine(!) sample chapters [joelonsoftware.com] on Joels website
  • by kulmala (3852) on Wednesday October 01, 2003 @12:45PM (#7104533) Homepage
    There is a shorter online version [joelonsoftware.com] (nine chapters) of the book available on Joel's site [joelonsoftware.com] (excellent stuff, btw.)
  • by Anonymous Coward on Wednesday October 01, 2003 @12:46PM (#7104539)
    The book you're looking for is "The Inmates Are Running The Asylum", by Alan Cooper.
  • by Sigma 7 (266129) on Wednesday October 01, 2003 @01:38PM (#7105151)
    any (non-browser) program that opens a URL thorugh the OS, be it the start menu, should OPEN UP A NEW FRICKIN' BROWSER WINDOW rather than highjacking an existing one.
    Actually, it's the browser that makes that decision. If you find that these third party applications hose whatever background content you were holding regardless of the available, you might want to switch browsers.

    I can tell you how to fix that in IE: Goto Tools -> Internet Options -> Advanced. Look for an item called "Reuse windows for launching shortcuts". Uncheck it.
  • by tchapin (90910) on Wednesday October 01, 2003 @04:05PM (#7107175)
    It's web-focused, but a lot of the lessons apply to any domain. Check out Steve Krug's website [stevekrug.com]. This book is totally awesome. Short, sweet, yet it packs a mental punch.

    UI design can be really difficult. A lot of the issues are in how the information / features / tools / whatever are organized in the application. Some call that information architecture, but I don't make that distinction. Another issue is that of labels & names.

    I am a professional UI Designer, currently working in telephony-based speech recognition. Very often, the "subject-matter experts" at my clients are too close to the issue and try to force their viewpoint on the application. One of my jobs is to convince them that users won't understand that sort of thing. Another is to try to make sense of the mish-mash of requirements for the application.

    All in all, it's challenging and fun work.

    Todd

  • by nachoboy (107025) on Wednesday October 01, 2003 @04:12PM (#7107255)
    It seems as if you are only familiar with the GUI method of setting network properties. While it's easy to make fun of Windows XP for all its gaudiness, Microsoft finally added a whole slew of great command line tools which are often overlooked. netsh for example is a great command line, hierarchical interface to network adapter properties and settings. Spend a little time with it and you'll never go fishing through those silly dialogs again. diskpart is another great addition that should have been there long ago. sc for service configuration and bootcfg for making changes to your boot.ini - the list is pretty extensive. More info in %systemroot%\help\ntcmds.chm.
  • by Watts (3033) on Wednesday October 01, 2003 @04:18PM (#7107307)
    At a recent project review meeting, developers at my company listed the strengths of our development process. To my surprise, user interface design was mentioned as one of our stronger points. While I haven't been around long enough to see many projects, I definitely didn't believe this was the case.

    I think what has happened is that web applications have expanded the user base of our programs while lowering the training curve. Where we might have built an application for a specific group in the past and conducted training specific to their needs, we're now deploying web apps that are used by a much broader group that gets no specific training.

    You can get away with mediocre user interfaces when you're there to tell a group exactly how it works (and they pass on that information), but if your work needs to be quickly understood by a broad base, then usability is a necessity.
  • by mrsbrisby (60242) on Wednesday October 01, 2003 @05:03PM (#7107845) Homepage
    it's hideous to keep hearing about how programmers cannot possibly design good, clean, consistant user interfaces. i have a hard time finding a case where it's a non-engineer that has ever in the history of time designed and developed a consistant and usable interface.

    It's safe to say that non-artists have a hard time "drawing" things- but the widgets themselves must be _designed_ by an engineer. usually, the best looking, and best feeling interfaces are those built with constant feedback between artists and engineers.

    So I place the precarious difference in what it means to design, versus what it means to draw.

    I can't draw a straight line with a ruler, but the software I have built has a user-interface that is generally approachable, but always usable.

    Part of the engineers job is to decide where options, already categorized, will go- by deciding what those categories go, and where the user will need to find them. The engineer can usually sit back and "think" as if they have never seen this interface before, and any engineer that will actually say that labelling a button "Func2" just to save space is actually good UI isn't a proper engineer at all.

    But while engineers do like consistancy, and while they can appreciate approachabilitiy (though to reiterate: they may need prodding to get it there) their first goal is to make it usable. That means that after the user _already knows_ where every button can be found and what every function is, they actually feel comfortable using it.

    This is a scary thing; the rest of the world doesn't seem to think "usability" means this at all. And they don't otherwise have a word for "approachability", and still somehow all three are intermingled with consistancy into one umbrella of user friendlyness.

    Many engineers like to solve this problem with configurability- to make it possible to change every behavior of the software (that they think) possible, so that users can find their own usable system.

    The problem is that nobody but an aspiring engineer or better can do that.

    And if nobody but an engineer can actually define (and therefore design) the usability, and if clearly usability is paramount in a programs, well, use, then it should not only be obvious and apparent, but you will grin widely when you notice that not only are engineers the best user-interface designers, they are the only people who can make it work.

    Apple computer is often cited as an example of consistancy (well, except for their cross-platform offerings) but do you honestly think it was the artist that did anything but decide what a slider should _look like_? Not that a slider was the best tool, or that "some kind" of gauge was necessary, but find an artist that does this, and I'll start calling them an engineer.

    Well, not now anyway... Almost everyone has seen a slider, so let's change that above examine to be a quokulfork. Non-engineers, your challenge is to decide what the quokulfork is, and since you can already draw it, do that, and decide how it works, and why it's necessary.

    I mean, the quokulfork: the most needed UI element.

    You can't think we've thought of all of them. After all, how did Macintosh go so long without a slider widget?

"Consistency requires you to be as ignorant today as you were a year ago." -- Bernard Berenson

Working...