Slashdot Mirror
User Interface Design for Programmers
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.
they consider it a creative process rather than a logical one;
Are we supposed to assume that creative and logical are now mutually exclusive? I always thought they were complementary. I sure as heck wouldn't find computers interesting if it was all rote and mechanics.
What is music when you despise all sound?
Is that users are fucking idiots.
Some user just posted an item how she highlighted her work and then hit 'backspace' and deleted everything.
She wanted to know what we could do for her.
'Feel bad' was about all we could come up with. 'Laugh' was another, but we didn't think she'd like that.
The opposite of progress is congress
Bookpool has it $2 cheaper than Amazon, and you're not giving business to someone who is abusing the patent system.
4 1
http://www.bookpool.com/.x/ejmrmq9fa6/sm/18931159
Most programmer think they know how to do UI.
(Frankly, I think many of them do, to a certain extent, if they're reasonably smart and understand ideas like not throwing too many options at the novice user)
It's visual design where the failing comes in. I think.
Or maybe I'm just generalizing from me.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
make sure you can't disable it
I think that crosses the line from "UI testing" to "hardware durability" testing.
and say that programmers shouldn't do UI design:
Programmers shouldn't do UI design.
I give you one example: the Linux desktop. No offense, but there is no freaking consistency. Ahh, the examples I could mention, but I got a UI to code...
The last thing the world needs is more programmers designing user interfaces. Most programmers know they suck at it, and their results are/tend to be pathetic. Nobody knows how many lives have been lost (measured in hours of frustration) by bad programmer-designed interfaces?
Let's face it, an interface is too complicated for most programmers to handle. A UI can be seen as a multidimentional problem (dimension in the real sense of identifying property) that can be viewed from multiple points of view, and each point of view filters out various dimensions of the program underneath it. It also requires you to be able to actually view things from those multiple POVs.
So for those programmers thinking about UI, don't do it! Stick with command-line interfaces, and let other people take your code and wrap it in something like AppleScript studio, or whatever.
Good UI design just takes a lot of time and a lot of listening. First, you design the interface to do what you want it to do. You try to pretend you know very little about the actual mechanics of what gets done behind the scenes to make whatever it is happen (a difficult proposition, but you should be able to get relatively close). Then, code the interface (just the framework, don't waste a whole lot of time at this point).
Then, show it to someone representative of the intended audience. If you're coding a general purpose Windows app, show it to your grandmother. See if she can figure out how to work it. Encourage conversation about it. If she can't figure it out, don't get argumentative. Find out what SHE thinks the interface is trying to do, and try to find out what about the interface makes her think that. Then, try to get a few ideas on how to improve it. She won't be able to give you any real specifics, but maybe she can give you a thread you can explore in detail on your own.
Re-design based on what you learned. Show it to her again. Repeat until she "gets it". Then, go show your new design to someone else in your target group. Make changes by what they say. If what they say contradicts what your grandmother said, do your best to reconcile the differences. Make up any gaps you can't fix with documentation targeted at the bits you can't seem to make any less confusing.
A lot of engineers fall into the trap of designing interfaces and sticking with them, even if they are deficient. They insist the users are just "too stupid" or just "don't get it" or just "aren't using it right". They fail to realize the whole idea of a good UI is to make sure users CAN'T use it wrong, and to make it as difficult as possible for the user to fail to understand.
"The customer did something wrong" is NEVER a reasonable excuse for a problem in a UI. If the customer did something wrong, it's YOUR fault for making it possible for the customer to do whatever it was he did wrong.
You can read nine(!) sample chapters on Joels website
"I deny nothing, but doubt everything." Lord Byron
That brings back bad memories. Last year, during my freshman year of college, I was one of the lucky test subject in a study conducted by one of the CS students. (See http://www.users.muohio.edu/birchmzp/csi/dharna.pd f). It was a poor VB project that had an annoying talking head bouncing around the screen, giving instructions, that I was explicitly told "not to dismiss." And yes, it used Microsoft Agent... I wanted to kill it. Especially when I had to repeat the same action over, and had to listen to the same instructions from it again. On top of that, the VB program's buttons were greyed out until the thing shut up.
*shudder*
I went back to my room and stared lovingly into the login prompt on my FreeBSD machine for an hour after that experience.
"Hu, ho, ho-ah-oh-oh-oh. Hu, ho ho-ah-oh-oh-oh. Mario Paint! Whoaaa!"
GAMES:
1. If the user doesn't have to stop what he's doing to solve an inexplicable puzzle every few minutes, he'll be done waaaay too fast.
2. Obey the principle of most astonishment. Surprise the user as often as possible! Preferably with something terrifying that makes him literally fling himself out of his chair (example: the aliens in Alien Vs. Predator love to sneak up on you along walls and ceilings and suddenly let you have it from three directions -- a guaranteed excuse to press "pause" and go put on a new pair of underwear).
3. If the user screws something up, HE MUST BE PUNISHED. Usually, this means his onscreen persona (resume, spreadsheet, etc) should die a wretched, gory death, scaring the crap out of the user (see #2) and he should have to start whatever he was doing over from his last save point. This of course encourages saving documents frequently, always a good thing with Microsoft software.
4. If the software includes networking features, you MUST include a "taunt" feature. Allow preformatted taunts and on-the-fly taunts; both are equally fun for all. "Hey, BILL! Your powerpoint SUCKS!"
5. And, finally, you have to include a few easter eggs and hidden areas. These should include a "must-have" that isn't granted to ordinary users (like, say, print preview).
And, people said video gaming wouldn't ever get me anywhere!
Farewell! It's been a fine buncha years!
"Yes but that's how I would think it works" they'll say. Says I, "Yes but you're a certain type of guy who knows what's going on underneath it all, from the user's point of view he's looking for something completely different."
That's why our company has people like me, renaissance people if you will, who can think with both sides of the brain and provide a bridge between the technical people and the creative people who design the user interface.
It's a good learning process, all this interaction means that they get to learn a bit more about the needs of the user and I get to learn about the underlying technology. Books like this would probably help us all.
Another book that's doing the rounds at our place is The design of Everyday Things. It covers much more than just computing and gives a good insight into the psychology of the user. Some of the psychoanalysis stuff is a bit deep for my liking, although overall it's quite informative.
Drill baby drill - on Mars
There is a shorter online version (nine chapters) of the book available on Joel's site (excellent stuff, btw.)
Luke, I am your signature. Search your feelings, you know it to be true...
Just model everything after vi!
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
For many developers, I don't think that UI considerations are all that important. I've often spent a long time thinking about, and discussing with users, the best means of controlling a particular (web) application. In practice, though, users tend to spend a bit of time figuring out an interface -- however esoteric or poorly designed -- and then use it without complaints. They may not be using it 'optimally', but they're happy enough anyhow.
I'm playing Devil's Advocate, I know; but still, when cost/benefit analysis comes into play then there are arguably very many cases where it just doesn't matter how much effort goes into user design: even with the simplest, most elegant interface, users will take some time to figure out how to do things - and besides, many users are now trained into using Microsoft-style interfaces, meaning that they _are_ the 'most usable' format to follow irrespective of classical design/HCI principles.
Finally, I think that there's a marked difference between having something "look nice" and "be usable". And I think that many developers *are* adept at designing systems that are usable; it's the "prettiness factor" which is more elusive - and which most users tend to care and think about.
Hi! It looks like you're posting a sarcastic comment to Slashdot! Would you like me to make fun of the humorless and daft who take your posting posting literally?
Reliable, Great Value Hosting: $7.95/mo 2.4G/120G
Wierd. I think the paperclip is a great idea.
I have even been thinking about how to make a framework for guessing what the user is doing in GNOME.
Before adopting WHATWG, read the moonlight.NET EULA [http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx]
Benjamin Meyer
Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
This psyco-babble about grandma being the target annoys me. Sure everyone is a novice at sometime. However most applications are used by experts. (they started at beginers, but have learned it) How do you support those experts who are doing a task everyday? They have different demands, now your easy to learn app needs to be easy to get the common tasks done with. That is a completely differnent level of design.
Take configuring the network on windows. It is fairly easy, except for two points: the task itself is complex (Assume that dhcp isn't implimented for whatever reason), and getting it wrong can be serious (though microsoft will detect and prevent a lot of getting it wrong problems, good design there) to the rest of the network. Experts only territory, if you don't know what those fields mean, you should be taught by an expert. Because it is experts only territory, seperating things (DNS from ip/netmask) just slows down the expert who wants to type in a bunch of numbers and move on. The beginner should be turned off by the amount of data there, in hopes that they don't screw things up. (in NT based systems the user isn't given access to change this, more good design) Note that I specificly picked something where making it easy for the beginner makes it harder for the expert, and made the argument that the beginner shouldn't be here anyway - this argument doesn't apply to everything, often you need to support both types of users.
Then how do you deal with contradicting feedback? What if users are contradicting each other? A very good example would GNOME: half of the users scream "more options! more options!" while the other half screams "less options! less options!" (this is of course a heavily oversimplified view of the situation; but you get the point).
I's happened more than once that users contradict each other.
There is no spoon or sig.
"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."
All too often the terms programmer and Software Engineer are used interchangeably. UI design is the domain of Software Engineers. A programmer should design user interfaces as much as a baker should be enlisted to make a gourmet dinner. Combine this with the fact that Software Engineering is both a creative process and a logical one, and we can begin to see why I continue to question Joel's understanding of Software Engineering. I am not saying the book isn't good. It probably is, as long as you keep these caveats in mind.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Windows' file dialog - not only does it not remember the scrollbar location or sort order, it doesn't even remember the 'details' view - the thing that makes sorting even possible (why is any other option?), so to open the file you want, you need to:
* select the "file/open" menu entry
* move to the view drop-down list, click
* select the "details" option, click
* move to the column you want sorted (say "modified"), click
* scroll down to the desired file
* move to its name, double click
How many man-hours are lost worldwide to this UI idiocy alone?
Many times in my career as Web developer, I've had the responsibility of taking an existing site and growing traffic. In each case, the sites started out as ugly, since the 'design' was just wahtever seemed adequate by whoever coded the initial HTML.
The first step of improvement was to get a professional designer to come and fix the site - put together a more useful navigation system, adding breadcrumbs, etc.
The traffic would always double (at least) after the re-launch. Part of the increase has to do with old users having to deal with a new system, and clicking around more than they used to, but the rise in traffic was consistent over time, because more user-friendly interfaces meant more users could find what they were looking for.
So, design is not just making things pretty, and it's certainly not art, since art is about personal expression - design is making things useful, or optimizing their usefulness.
And slick design is often appropriate. If you run an e-commerce site that looks like it was put together by a 14-year old kid with a copy of Frontpage, you will scare away business because they think you're some fly-by-night operation.
So, spend the money, hire a designer. You can get a decent redesign for a few hundred bucks.
every stain tells a story
Unfortunately, UI can also be an area that should *not* be consumer-driven.
The recent facination (last five years) with media player authors to make "pretty" interfaces that immediately grab a user's interest is a great example. The UIs are far less usable, are inconsistent, are frequiently slower and buggy...yet authors keep pumping out these damned bitmap interfaces to DVD players, movie file players, audio file players, etc.
The problem is that every time someone does something with a tiny bit of justification, everyone copies it wrong.
Bitmapped interfaces have seen two major insurgences that are still present. The first, pointed out earlier, was in media player apps. There are a number of cases, but I think the first instance I know of was WinAmp. WinAmp was trying to fill a hole that had never been filled before. It needed to remain constantly up on a user's desktop to keep title, volume, and position available. However, it needed to save space (see the minimized form) -- I can't think of a good way to provide equivalent functionality using standard widgets. Anyway, a difficult HCI call -- to deviate from the standard OS interface was made. It has definitely had drawbacks, but there's at least a good argument that it was worthwhile.
Along came a huge number of media player designers, all of whom looked at WinAmp and decided at the bitmapped interface was what made the thing successful. They started churning out all kinds of horiffic unusable media players that *did* catch the eye, and *did* get users to try them out...only to hit irritation with the interfaces. Media players pioneered spikes hanging off of windows.
The other major example is graphic plugins, dating back to Kai's Power Tools. For those not familiar with the tool, KPT is a set of Photoshop plugins. It was written by Kai Krause, an extremely talented graphics programmer. He felt that using custom bitmapped widgets was a good idea. Again, his decision was somewhat arguable, but it let him showcase some of his software's effects, and more importantly, he did a reasonable job for someone going with an inconsistent interface -- he did a few things that would have been difficult with a conventional widget set. KPT had a tremendous functionality set, and succeeded wildly, allowing the company to grow, change names, and develop and acquire other software products like mad. The company continued to produce other outstanding products, also with bitmapped interfaces (with greater and lesser degrees of justification for their nonstandard interfaces. KPT Bryce is a notable example.
Naturally, a number of other, less talented, Photoshop plugin development companies that were producing products that were not particularly price-competitive or feature competitive looked at KPT and said "Gee...KPT uses a bitmapped interface and is successful. That must be what we're missing." Over the next few years, a *flood* of inconsistent, bitmap-interfaced Photoshop plugins hit the market. These were, as a rule, less well-done than the original KPT, and were a complete pain in the ass for a set of people that mostly used Macs, and had traditionally had one of the most consistent user interfaces in the history of personal computing.
Bitmapped, custom interfaces are almost always a bad idea.
There was also an influx of CD-ROM based titles with bitmapped interfaces starting in the early CD-ROM days. Lots of low-budget titles, educational titles, etc. Macromedia Director played a major role in the proliferation of these. Again, a bitmapped interface added nothing to usability, and frequently exposed bugs. It took a few years, but eventually designers realized that users didn't *like* atrocious bitmapped interfaces, and stopped.
Today, almost all games have a menu system that uses a nonstandard, bitmapped interface. Part of this is because they often have console ports, where there *is* no standard widget system, and part of it is because there's a perception that the customer *wants* a m
May we never see th
It takes a LOT of work to make good user interfaces, and nearly all of that work is repetitive and boring. It is easy to create inconsistencies, too. Programmers who just want to work on core or library-type routines are a dime a dozen because they basically don't have to know much about the end use of the app, just the technical requirements of the toolkit they're writing. Sort these records, rip this data from a file into memory, pack these strings into this byte array, etc. They are generalized functions that get used over and over, so there is some satisfaction in perfecting them and a need for them to be optimized. UI programmers have to know as much as possible about the people using the program, the business model that the end users have (why are they using this feature/function?... what is the ultimate goal?), and the types of environments it gets deployed into. It puts more of a burden on their mind as they work.
... this would be it after (out of obvious necessity) the data engine and memory model.
UI design on the other hand requires a TON of manual labor that cannot be done by anyone but a good programmer. You have to account for all the little things that a user just might do to your UI while maintaining the state of the form/program. That means coding responses to any number of potential events that might be fired instead of just letting the OS decide what will happen. UI design is frustrating and boring for most people because of this. If you have a form that has 60 fields on it spread over several tab pages and you have a status bar with an explanation of each field, you instantly have 120 callback functions, an enter and exit to and from each field to update that status line with that field's description and then to clear it. You have to write form field validator routines that check each field's data before packing it back into the database, issuing the right kind of error if the data is unacceptable. Heck, just the task of plugging all the database fields into the form elements can be painstaking for a form of moderate complexity.
And all the code has to be consistent, clean, etc, so the next guy knows what is going on. To impliment ONE well-designed form can take days of uninterrupted programming time. Forms with many many fields just slow things down even more... halfway through the afternoon your mind is swimming in a sea of callbacks and field names. Debugging a form? Don't go there.
I think basic "quality application interface programming," not even design, is the most underappriciated aspect of the complete software engineering task. If you had to pick just ONE THING to say, "We're going to make absolutely sure we don't **** this up."
To make an analogy: The UI programming is like the Marine Corps (boring sweaty grunt work) like the "rest of the job" is to being an Air Force fighter pilot.
When developers design UIs there's always the problem that they know exactly how the system works and because of that they lose perspective on what makes sense to others. In my experience, though, that's not what most frequently causes bad designs. Our designs usually go astray because we don't choose the right audience. If you're building a web server, for instance, you can safely assume that anyone using the server's UI will have at least a decent mastery of software and how to use it (even if they know anything about web servers). Thus, not everything needs to be all wizarded-out.
However, if you're building a new instant messaging client, for instance, perhaps you want to make sure the dumbest possible user, who can scarcely use a mouse, can use the software without trouble.
Generally, the more you build something in the interest of the dumbest users, the more the UI suffers for more savvy users. So, assuming that no one can use a mouse, isn't always a good starting point.
The key is to figure out who your target audience is, try to design for the vast majority of them (probably leaning a little towards the dumber ones), and perhaps decide on acceptable "casualties" for the few absolute dumbest of that range, in the interest of the rest.
--
Simon
For non-text selections, backspace (on Windows, not Mac OS) should not delete selections. That's what the delete key is for.
What are you talking about? Can you name one major application which behaves in this fashion?
Both backspace and delete are removal keys. The difference is solely in the direction in which they remove, and when the block is pre-specified, the difference is moot.
and feel like ridiculing users will somehow socially elevate them
Speaking as a former tech support employee, I can firmly say that for me and my coworkers at the time, it was more an issue of catharsis. I've also been a telemarketer, and the flak I recieved as a technical support staffmember was far worse.
The customer acts as if it's the ISP's fault that the phone company has hosed their phone line again. The customer acts as if it's the ISP's fault that little timmy has fux0red their modem settings again. The customer acts as if it's the ISP's fault that they've forgotten their password again.
When I was tech support, I was one of two support monkies that I never saw reduced to tears in the course of about two years, and I came damned close more than once. I suspect you've no idea the sort of abuse that irate assholes subject tech support people to. So, when a user is shocked that the same thing that would happen in any application has happened here and can't be bothered to find and hit undo (I don't care what the AC said about it being a web application; undo works just fine in IE 3-6, Netscape 2-4 and Mozilla,) I think that the tech support crew is fully within their rights to be annoyed.
For the sake of professionalism, this may not be shown to the user, which the poster was careful to be clear that they did not do. Perhaps you've just got a bias towards hating technical support. Of course, if you're an Earthlink customer, I understand wholeheartedly; I'm convinced that they actually go to significant effort to find the bottom of the barrel people available.
I'd like to see a couple of said jackass tech support people be laughed at by the mechanic
Not very in touch with pop culture, are we? It is a classic truism that the service industry is mistrusted, shat on, and that the customer defends their actions by presuming that the service industry members all do this, and that they had done it first is somehow implied. You've really never heard a story about getting screwed by a car mechanic? I'd be hard pressed to find a less damning example, except maybe a used car salesman.
Hint: the services which get it the worst are the ones which people feel tied to without alternatives (utility monopolies especially,) the ones which cost the most (auto mechanics get it doubly because cars with failings often have other failings on the horizon, and the users which allow them to fail don't maintain well, leading to cascade failures which they blame on the mechanics,) and the ones they understand the least (plumbers and computer techs get this one a lot.)
It's really about insecurity. As you enter a service industry, you find that the more the customer knows about their service (on the average) the less horrible they are to you. If you can explain a delay or a problem to them, they're generally much more tolerant. The people which are the worst are the huge clueless fucks, especially the ones which don't know that they're clueless fucks, doubly especially the ones which think they're something other than a clueless fuck. Do you get shat on by tech support a lot? Could this be a hint?
(which they're unable to fix, despite the fix being a quick, five-minute change)
I'm willing to bet you're a moderate quality amateur mechanic, hence the choice of looking down this particular nose. Can you replace your sink? Can you pull up your floorboards? Have you ever installed a ducted air conditioner? Can you plan a seeding cycle? This is the sort of arrogance which nearly every professional
StoneCypher is Full of BS
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
-- !todd erases a red dot! I steal music on the internet.
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.
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?
Just a quick note to add that I too have Steve Krug's "Don't make me think" on my top shelf. This book is about sensible web design, but many of it's principles, including the concepts of "Usability Testing on 10 cents a Day" apply to any GUI design project.
As a side note, my whole career I've pretty much specialized in putting GUIs on things -- I haven't stopped laughing at some of the posts in this thread since I started reading it -- If the sum of slashdot posts is any indication, GUI design is really totally misunderstood by the average developer.
"That naive cube! How long must I suffer this!" --Sheldon J. Plankton
Coping Apple's interface designs seems to work well for folks who are too cheep to hire anyone that knows anything about information architecture or GUI design.
:p
I advise doing that.
"Things are more moderner than before- bigger, and yet smaller- it's computers-- San Dimas High School football RULES!"
The front of The Design of Everyday Things tells the story of the renaming of the book. I can't find the text of the intro anywhere on the web (via googling for specific phrases) so:
--Phil (If you haven't read this book, you should do so now. It's that good.)
355/113 -- Not the famous irrational number PI, but an incredible simulation!