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.
To just put Clippy, or any other Microsoft Agent into your app. And tyo make your app really cool, make sure you can't disable it.
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?
Quit posting Amazon referral links you dingbat!
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
I'd rather spend the extra $9 than give a scum-sucking troll like you a cut.
.. many developers set out quite deliberately to test the theory that the users "could care less".
English: it's not *that* difficult a language...
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
Ref: Save $9 by buying this book at Amazon.
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...
What's up with that! Software is the highest form of art. It has everything every other medium has plus, it is interactive. If that's not creative, then what is?
This is my sig.
I don't really think a lot of good programmers fear UI design as much as they find it irrelevant.
If this book makes a good case as to WHY good UI development skills are important, than I think we'd have a winner.
"Ask not what your country can do for you." --John F. Kennedy
So why not hang out at fuckedcompany.com instead of slashdot? Sounds more like your crowd over there.
"Eve of Destruction", it's not just for old hippies anymore...
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.
You mean they're into the asian nun bondage scene?
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
I've always found it to be somewhat the reverse: many programmers, most particularly those involved in the open source community, seem to view user interface design as something that enables them to fill the user with fear.
Or at least that's how it seems based on using any number of free apps with terrible GUIs. Maybe there is a UI design guide for sadists too.
In Soviet Rush, today's Tom Sawyer gets high on you.
So instead of successful and high-flying Amazon you would rather have the patent granted to some Joe Schmoe company that is about to go bankrupt and brings in lawyers to "capitalize on its intellectual property"?
The patent would be granted, it's just the matter of who it is granted to, so far there is nothing in Amazon practice to suspect them of abuse.
Dude, you were almost funny. If you had just put in a line at the end, something like "Unemployment is so great" or "Thanks for fucking the economy, Bush!" Then that would have been really funny. As it is, its just sad. Good luck next time (and finding the asian nuns).
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
Logic is an art -- as much an art as a science. The internal structure of logic is the science. Knowing where and how to apply logic, that's art.
Good interface design requires both: the rigors of logic combined with the humanity of art.
-kgj
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...
Well, this is not all bondage but it does have asian nuns in it.
We use Spolsky's FogBugz product for bug-tracking, and this guy does it right. The interface is clean, simple, and does exactly what you need.
I've "trained" about a half dozen people on it--the training consisted of "here's the URL, go to it". And they all got it right away.
If the book is as good as his product, then its a Buy.
Thanks a lot, big brain. (K. Vonnegut, "Galapagos")
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.
As opposed to UI Design for Plumbers?
I just don't want to support a company that is so blatently abusing the system. I don't think patent's like Amazon's should even be granted in the first place, but that is a whole different discussion.
When it comes to buying books online, I'm always going to try to avoid Amazon, and give my business to the company who is at least not being an ass about how they do business.
On top of that, Bookpool is cheaper than Amazon, and I've always had excellent service from them.
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.
There are three concepts which really need to sink into the head of anyone trying to develop a good user interface on any kind of tool, device or application. * know the users their goals * don't make the user feel stupid * provide rich feedback so the user is confident Any application which merely connects APIs to Widgets will just fail horribly. The GUI isn't intended to expose the implementation to direct, marionette-style control. The GUI is there to understand the user's intentions and then achieve the desired results with the internal tools available.
[
If users complain that they can't use the system because some functionality is 'missing' - and it turns out they haven't worked out how to use a scrollbar - do you spend significant time and effort redesigning the interface, or train the users to drive it properly?
You *need* larger scale, controlled tests to determine if a problem is *significant* before making any changes. Get it so that 90% can use it with no problems and give the rest more training - that's a more sensible approach than trying to make every application useable by the average brain donor.
The "quick, simple and casual" approach might be a good idea to get a feel as to where to target the main testing - but using it to drive useability requirements is probably not a great move.
Some user just posted an item how she highlighted her work and then hit 'backspace' and deleted everything.
First, I assume that this is text that you're talking about. For non-text selections, backspace (on Windows, not Mac OS) should not delete selections. That's what the delete key is for.
If it *is* a text selection, you should be providing an undo feature.
The main problem is that a not insignificant number of people in tech support (which is admittedly not a fun job) are jackasses and feel like ridiculing users will somehow socially elevate them. I'd like to see a couple of said jackass tech support people be laughed at by the mechanic when they bring in their car (which they're unable to fix, despite the fix being a quick, five-minute change) or their tax preparer when they bring in their taxes. Or their doctor when they come in with an obviously diagnosable case.
How would you feel if there was a User Friendly starring doctors? "Doctor, I feel sick and my legs are swollen." "Let's see...you're currently taking hyponeophenothol for depression. Did you take any drugs in the last day?" "Uh, yeah, some muscle relaxants." [Picture of doctor smacking head in frusteration.] "Well, the best thing to do would be to take 300 mG of cyanide. As soon as possible." "Okay. [click]"
This is pretty much the template of a Greg-user-support cartoon on UF, but with medical workers instead of tech workers. Less funny when you're on the recieving end, portrayed as the "stupid user" who isn't conversant with the specialized field involved, isn't it?
May we never see th
That's crazy talk. The user interface is what I have once I've gotten the computer to do what I want.
Don't know what happened there.
This is the real link.
Benjamin Meyer
Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
The human thought process is normally to some degree creative and to some degree logial.
For some tasks, too much logical thinking with too little creativity will give bad results.
The point here is that with UI design, it's different: Any significant amount of creativity in your UI design means that the UI is different from what prople are used to, and that will generally reduce usability. To create a decent UI, you need logical thinking, and lots of it.
It's people like you what keep computers restricted to losers who have hours of time to figure out how to use their command line interfaces.
I applaud your honesty. Really. (Assuming you're not just bragging about your mad coding skillz.)
Microsoft's Human Interface Design group settled on blue (out of the limited colors available on the text console) as the color for the infamous "Screen of Death" as it was a more calming than other colors such as red.
Test subjects were reported to feel angry, agitated and frustrated when red was used.
It was known that Windows had frequent crashes, the choice of blue was to help prevent "office rage".
Wow, someone who does a proper breakdown.
May we never see th
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."
I completely identify with this statement. I loathe user interface design because, quite frankly, I don't think I have an artistic bone in my body. As a consequence, I've always concentrated on component as well as application engine design. If I were an artist AND a programmer, shit, I'd be making video games or something then, instead of writing business apps for a living.
Spread the RC luvin'
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.
what's wrong with $
missa agree!
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.
you would rather have the patent granted to some Joe Schmoe company
What are you blathering on about? What about not having ridiculous patents like "one-click shopping" issued in the first place? By boycotting places that go after these types of patents, you're sending a message that they're bad for business.
Don't you Amazon employees do anything apart from troll the Slashdot forums all day?
"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
But then it would take on a whiney tone and be truly sad. It's good how he wrote it. It already has a punchline: "wake up refreshed to yet another completely useless day".
I've just done a quick test: I created a page with a textarea element (multi-line text box), served it up from one of my machines, typed and selected some text and hit backspace, then Ctrl-Z (Windows) / Command-Z (Mac). I got the following results:
So if your punters are using IE6 on Windows, they can undo that mistake with Ctrl-Z. I would assume that this also applies to Mozilla cross-platform. Don't know if it works in IE 4, 5 or 5.5, but it may well do so.
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
Those aren't funny. "I can't believe they pay me to be a /. editor" is. Or "College kicks ass" would be more fitting.
I don't think people necessarily fear UI design so much as they see it as just so much scut work that needs to be done. It tends to be a pain in the ass to get all of the widgets lined up nicely and controlling the bits of your program that they're supposed to control. A decent IDE helps lessen the pain somewhat, but it's still not as fun as coding the parts of your program that get the real work done.
20 January 2017: the End of an Error.
Dude, did you ever actually have any sales off Slashdot to justify such a dedicated referral posting?
Spolsky seems to have a good grasp on the idea of Joint Application Development: you have to sit down with the users and ask them how best to make your software help them do their job. It is much more important to have software whose process model is intuitively obvious to your user than anything about how it looks or feels. The only way you'll ever know what passes for "intuitively obvious" is to sit down with your users and find out from them.
Unless you have in-person access to a large pool of potential users, this advice doesn't work quite as well for shrinkwrap software. When making something any fool can use, only a fool will use it. And from the old school, fuck 'em.
This is not my sandwich.
Biggest pet peeve is the simple "Yes"/"no" interface seen for a dialog in most games.
Many developers insist using just 2 different neutral colors for Yes/no, and no real indication of which color means "yes, I choose this one!" compared to "no, I don't choose this one". The result? It's a toss up.
One nice way of doing it is to darken the option you didn't choose. Don't use red and green(maybe modeled after traffic semaphores) as toggle colors.
Past few jobs I had as a developer, either management or the other employees did the UI design by drawing it or painting it with a paint program. The design constantly changed on their whims. "It is not intiutive" they would say about some UI they designed a week ago, so they would change it again. Not knowing that each change required a lot of rewriting the code. For example, going from a combo box to a listview to three combo boxes requires rewriting of the code and more work for the developer. I often hoped they would get it right the first time, and then I could code it and lock in the code as golden, but no, they had to keep changing their minds.
The book at the time everyone else was reading was "Don't make me think" but it was never passed around to me. Wish they would have let me read it, they only bought one copy (Cheapskates) and while my name was on the list, it never got passed to me. Maybe it would have had they not let me go? All the changes they kept making caused delays in releasing the code I was working on, so I got accused of not working fast enough. Which is why I think it is important to nail down the UI the first time, than to keep guessing at it and changing the UI on the fly.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
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?
that right. using the pateNTdead eyecon0meter, it's possible to filter through/out most of the greed/fear based ?pr? ?firm? scriptdead georgewellian fuddite southern baptist freemason corepirate nazi payper liesense hostage ransom MiSinformation, being spewn about, buy felonious stock markup FraUD execrable.
the kode is available/growing exponentially. you know where to look.
now, be careful. this program works on several (more than 3) dimensions.
consult with/trust in yOUR creator regarding decisions of the heart/mind/conscience/wallet. more breathing. seek out/communicate with others of non-aggressive/positive behaviours/intentions. that's the spirit, moving you. it's ALL about yOUR motives.
for each of the creator's innocents harmed, there is a badtoll that must/will be repaid by you/US. the perpetrators of unprecedented evile will not be available to make reparations.
Like the system bell in vi.
t
I'm one of those freelancers who write a lot of code and also do a lot of graphic design work. Writing UIs and using UIs not written by myself have shown me a very simple rule that works in most simple to moderate cases. The keyword here is WORKFLOW. People use UIs to do something, and the process of doing that something is called the Workflow. If you understand the Workflow, you will know how to design the UI. I'm not talking about the fundamental UI things like where to place an OK button, but at a higher-level where you look at the UI as the app. A recent non-trivial project I did involved a distributed system with the UI as an important element. I received a detailed but messy design spec containing mock-up UIs done in MSWord (!!). The designer tried to cram like 2 dozen controls into a single UI screen. Anyway, I took a long time reading the spec and spent even longer thinking while away from the computer. Finally, I saw the Workflow. I simplified it into a linear state machine with a couple of loops. I then wrote the UI and organised it with a horizontal tabbed menu. The user just have to move from the left-most tab to the right-most tab, spending time in the UI screen of each tab. It worked wonderfully, my client understood it immediately when I demo'ed it to them. So, to summarise again: Capture the Workflow!
www.rexguo.com - Technologist + Designer
The worst crime is to be wierd just for the sake of being wierd. Proximtron and Spybot are offenders here.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
I don't see why programmers should be bad at user interface design. The most important rules of UI design are the same as those for programming:
- Keep it simple.
- Don't reinvent the wheel; reuse what has already been done (eg standard dialogue boxes and conventions).
- Don't create many slightly-different ways to accomplish the same thing; provide a few simple and obvious primitives that are easy to use together.
Where this may fall down is in not understanding how users think, although many programmers have some idea of how another programmer will think and can take that into account when writing code.
-- Ed Avis ed@membled.com
You worked on Office XP, didn't you?
Spolsky encourages showing the in-progress software to users and watching them use it.
If you wait until the software is in progess before you show it to users for testing, you're too late. By the time you have front-end stuff to show people, developers have already invested a lot of time, and any changes will have to fight against the momentum of the project. I know, because I've seen it time and again, at numerous companies. I've seen this happen in small shops doing $10-50K jobs, and I've seen it on $3+ million jobs as well.
What happens if the users don't "get it?" Is it back to the drawing board? Not if developer time has already been spent, baby. Instead, management will ask the UI folks to slap a bunch of labels on items "explaining" stuff. So we'll write a bunch of labels and add them to the application, delaying the release date a bit more, only to find what we already know, which is that nobody actually reads explainatory text when using an application, so it's been a waste of time. Oh, and the text looks like ass.
The next thing you know, all of the suggestions for making the application easier to use based on the in-progress application user testing are being set aside for the next revision. During the next revision, though it's unlikely that the changes will be implemented, though, because of (a) the previous investment in legacy code and (b) "users expect it to work certain ways."
The right thing to do is to test things out with paper prototypes before writing any front-end code. There's nothing magical about paper prototypes, they can be simple sketches with the names of buttons and data examples written out. They're cheap, quick to develop, and if they don't work, you can sketch out/photocopy another. For little investment in time or money, you can get something that you know users understand. Believe me, in the long run, it's worth delaying the development team for a few days to do this.
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
What browser were you using?
How about the browser used by a person who either doesn't know what a context menu is or doesn't know that the editing commands are found in textareas' context menu in Mozilla and IE?
Will I retire or break 10K?
Seems that you are as closed minded as some of the Linux folk.
...a better Windows than Windows, IMO.
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.
The problem I generally see is that some users don't pay attention or just don't care, or just like to gripe.
Case and point: I do a lot of web-based tool work at my job. I added a paricular feature recently. I explained this feature at a conference call with the group that was to use the feature. I then explained the feature AGAIN in a summary email about the changes I was going to install the coming week. The form has online help explaining the feature and how to use it step by step, and is easy to find (unless anyone thinks "Click here for help" at the very top of the form is too obscure). So what happens a few days after I install the feature? I get a call from a person complaining "I don't know how to use this feature".
This person was at the conference call, was on the mailing list that I send my summary to, and, I assume, can read the English language. In talking with her, I confirmed that 1) she doesn't recall me saying anything about the feature at the call, 2) She doesn't remember seeing any email from me, and 3) She didn't see the "click here for help"
Sigh.
Karma: Frotzed (mostly due to the Frobozz Magic Karma Company)
So they guy who invented Clippy used to be my boss. Yes, he actually tells people this, I know, it's crazy. But he has a pretty good spiel about how Microsoft implemented it wrong, and redid the alogarithms tha tcontrol how and when it shows up. I guess if I was microsoft and I spent a million bucks on a cratonn, I wan't to see that puppy being used, goddamnit!!! I also got to see the original clay model for the "Eirnstein Agent" which was neat. He set it down on the table and the eye popped off. Telling. Sad,
I tend to get screwed a lot by stuff like Slashdot's "wait 2 minutes" limiter
Refresh the "Slow Down Cowboy!" page after a couple minutes, and the comment will be posted intact. Or use Mozilla instead; because it isn't overly eager to expire Slashdot comment pages, it doesn't eat the contents of a form after you Back up to it.
Will I retire or break 10K?
If the problem is that users are idiots, wouldn't the obvious solution be to pick up a copy of "Idiots For Dummies?"
Ergonomica Auctorita
Ergonomica Auctorita Illico!
I haven't read Spolsky's book, but from the review it sounds similar to a book I really liked, Programming as if People Mattered, by Nathaniel Borenstein. I definitely recommend it if you're interested in UI development.
Just to add another:
-Every design has trade-offs. Which design to use depends on the situation.
Ergonomica Auctorita
Ergonomica Auctorita Illico!
What, and programming isn't?
Creating a program is not a mechanical, logical process (consult Turing for details).
Also, a well-crafted computer program is not just a set of instructions for a machine, it is a creative work that documents and explains a process.
It is as creative as a mathematical proof, or a poem. Duff's device is as creative and as beautiful as Basho's frog haiku. Any of these may be analyzed from a logical perspective, but their creation remains to some degree ineffable.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
unless anyone thinks "Click here for help" at the very top of the form is too obscure
It might have been confused with an advertisement. Please read Google's top results on "banner blindness" and "box blindness."
Will I retire or break 10K?
A key to user interface design is "you should never have to tell the computer something it already knows". That's from the old Mac interface guidelines.
Never ask the user to find something the program can find. The user should have to input a data item no more than once, ever. And this doesn't mean the user has to "register" to buy from your website, even if the "marketing" people want that.
Sssh! Quiet! If a rumor like that gets around, I'll never get laid again!
Farewell! It's been a fine buncha years!
I admonish your spelling skills...it's Achilles
Not scary enough... I was thinking something more along the lines of the "facehugger pounces on you" effect from Aliens Vs. predator, combined with angry cat noises and a barf sound...
Farewell! It's been a fine buncha years!
do not do interfaces
Nope, programmers aren't good at any of these things. It involves problem solving skills. Programmers don't have any of those. It involves detecting, isolating, and correcting mistakes. Step-wise refinement. Nope, programmers can't do that.
Sarcasm aside. A lot of programmers do make horrible, unusable UIs. Some, like Alan Cooper and various people on Slashdot, argue that programmers can't learn how to make a good UI. I disagree. A good UI is a solution to a mapping problem.
The trick is making the UI a priority, properly identifying the problems, and providing for iterative engineering of a solution to the problems. Good user-interface designers are engineers in this sense. It's just that they've specialized in this human-machine domain, so they have a huge head-start on those who would otherwise have to discover everything from scratch. Programmers can learn how "regular users" think about their tasks, even if it's alien to how the programmer would think about it. Cooper says they can't, but I think he's wrong.
Pairing a programmer with a UI expert can be a fantastic thing. The UI expert can help the programmer understand how the users see the task, and the programmer can come up with innovative ways to map that mental model to the program model.
The reminder to focus on the tasks the user is trying to accomplish rather than the long feature list
:)
This is so important, but often completely missed. I have two things to say about it. First concering getting the information a programmer needs to design an appropriate interface. I have written some apps whose interface was perfectly good for the workflow that I had in my mind. Unfortunately, it turned out that I had misunderstood the user's workflow, and am now in the process of refactoring the entire application to match a more appropriate interface.
This extends to more than just interfaces, and getting a good understanding of the workflow can be hard. Often the user thinks they have to tell the programmer exactly what they want - practically specifing the interface. This inevitably leads to failure because what the user thinks they want and what they really want are not the same thing. They are not user interface designers, they are just making guesses based on what they have seen other programs do. There is usually a better solution to the problem than the one they thought of, since you have knowledge that they don't. Other times a list of features gets handed to the developer, with little information about how the features will be used. Again, huge possibility for failure because the implicit idea of how the program is going to work in your mind and in the customer's mind may be different. Now you are the one guessing at a solution, lacking knowledge that only the user has.
The big point is to get a good understanding of the problem, and then you can work together to come up with a solution. The best way I've ever seen of doing this is to tell the user to pretend that you are a new employee or intern and have them walk you through all the processes that your software will influence. Like a new employee would, talk to the old employees to get a better understanding of your (pretend) new job. Spend time watching them and look for areas of inefficiency that they don't realize because they have been doing it that way for so many years. Then you are in a position to start designing, and bouncing those designs off the users.
The second point. When designing an interface alot of programmers jump strait to the buttons, menus, dialog boxes, etc and such. But these things are the low-level implementation - not the goal itself. UI design should be more appropriately called User Interaction design, and has to do with understanding the workflow of the user, and then choosing the method to implement it.
Don't actually have anything to say about the book or review - it just got my mind going on this track, and I couldn't prevent my fingers from typing after that
This is probably one if the most important things, especially in corporate/commercial software development where you don't have a feedback system to see what users like and don't like. At several places I have worked the engineers would ignore or just give lip service to the results or ignore them completely. Frequently developers get defensive when presented with recommendations or changed requirements because they view them as a subjective attack on their work. It's not. Although really inventive UI design will always require novel thinking it's important to understand that there is a lot of existing best practices and knowledge out there and it will make your products better.
While I do I make my living at this stuff I'm all for as many people learning the best practices of UI design as possible. It means that my work is less teaching and more designing. I love engineers, without them I'd have to write my own code and nobody wants that [my old Data Structures classmates can attest to that].
One other important thing mentioned is that despite some astronomically-priced pundits' opinions to the contrary, testing doesn't need to be a monolithic process that costs tens of thousands of dollars.
For a very casual overview of usability I recommend Steve Krug's "Don't Make Me Think!". It's mostly focused on web usability but it's extremely readable and covers all the basic topics. It's also very short which makes it easier to talk your coworkers into reading.
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.
If they can't figure out an interface, they have no right to use the technology.
Vi!
I drank what? -- Socrates
Wow!
Whoever wrote that apparently feels that creativity and logic are opposites or contradictory.
In software engineering, I see logic as the medium for creative expression of ideas. They are two different things and they happily coexist, particularly in programming and mathematics and science and any number of other fields.
HCG 50a = 2MASX J11170638+5455016
11h17m06.4s +54d55m02s
I guess the target programmer here is one that is just being introduced to UI design. What I would like to see is more UI design patterns and practices in a book like this. It's one thing to design a UI that is nice to users, but to design one that is nice to the developer in the long run is more difficult. (This would apply to application development in general)
TallGreen CMS hosting
I loathe user interface design because, quite frankly, I don't think I have an artistic bone in my body.
Related snappy line:
She: I don't have an artistic bone in my body...
He: Would you like one?
--
Simon
Rush Limbaugh; as obnoxious and idiotic as I find that fat dummy is. I believe his comment was directed at the liberal media capitalizing on product endorsement and status which the athlete might generate. Black athletes have a strong fan base and the liberals have a sneaky way of getting their dirty little fingers into his/her cash and/or turn profit off of his/her skin color.
I do not like career liberals.
i've had this book for almost two years. it's good to see that the slashdot reviewers are reviewing the latest and greatest!
this is a great book though, highly recommended. easy to read and full of great tips (and ammunition against Flash designs!)
Users think they want a hammer, but if they had a hammer, they would have to know how to hold a hammer, how to swing a hammer, how to hold a nail, how to hit the nail... etc. The hammer is a beautiful example of a non-intuitive user friendly design. Most of us know how to use it simply because we've all learned how to use it.
Just imagine what would happen if you gave your end-users a hammer, a handful of nails and two peices of wood.
Other strong examples of non-intuitive user friendly design v.s. intuative non-friendly designs would be the qwerty keyboard v.s. alphabetaic keyboards, the mouse v.s. the touchscreen, vi and emacs v.s. notepad, the command line v.s. WIMP environments, etc.
Programmers aren't afraid of creating UIs. They simply recognize that creating a UI is a boring and tedious timesink that they would rather avoid given a choice. Further, in large businesses, functionality often has to take a back seat to form. It doesn't matter how easy to use it is if management doesn't think it's pretty enough.
I work in small development shop inside a large financial institution. We specialize in smaller projects that IT will never prioritize because it won't bring in at least 100 million dollars of additinal revenue. These projects still have substantial value to the business so we step in and fill the gap. Since we don't have a large number of developers, if it doesn't have to be done yesterday, we usually have one developer per project.
My current project is a database driven web application. The database and stored procedures were done in less than a week. Wrapping the database calls in server side script took another day or two. The last month has been spent working on the UI. We model the UI on paper, we go through the flows, I code it, the users test it, we redo the models, etc. I would much rather have spent that month working on something challenging. Especially when some of the most time consuming changes have been strictly cosmetic.
Software is, if it doesn't suck ass, functional. Ergo, it ain't high art. And no, what nerds consider to be unspeakably cool does not constitute high art.
--grendel drago
Laws do not persuade just because they threaten. --Seneca
http://digilander.libero.it/chiediloapippo/Enginee ring/iarchitect/qtime.htm
QuickTime is a lost cause. Apple has invested millions of dollars in sabotaging their own product. Use QuickTime at your own peril, only if you're as self destructive as Apple.
-Don
Take a look and feel free: http://www.PieMenu.com
I always thought that POET was renamed for the USian market, to make it sound less intimidating. Similar to the way Harry Potter's "philosopher's stone" (which actually has historical meaning) was dumbed down to "sourcerer's stone" to sound less intimidating to USian masses.
looking at some of my latest designs, i think i need to pick this book up ASAP ;)
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.
Sounds like Microsoft is *way* ahead of you. Observe:
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.
BSOD. Example: "What the hell? I wasn't doing anything. I was just staring at the screen. Wasn't even scrolling. Why did it crash?"
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).
BSOD. Example: "Wow, these demons are really tough. (kapow, kapow; reload) I'm running out of ammo. Better run back towa-- (fling!) Where the - Fuck, it crashed!"
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.
BSOD. For example, there are any number of things which the user can do in control panel which will immediately illicit a Very Bad Crash (tm). This causes the user to need to restore from the last save point; however, and not to be rude, I must point out that much like anything else, this does no in fact encourage users to hit control s. Because obviously two keypresses are too much effort to safeguard your last four hours of exploratory work three hours before the paper is due.
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!"
BSOD. I mean, honestly, haven't you ever gotten the impression that when one of those happens, the god damned thing is just mocking you?
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).
This turns out to be a misfeature, though I'm not sure why. Briefly, MS offered a must-have feature in the "anti-BSOD spray" OS, better known as NT 3.5. However, MS retreated from this strategy almost a decade ago. I find your work to be insightful, but I can tell that they've been there first, and discovered it's wrong.
Now, you just have to figure out why.
StoneCypher is Full of BS
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.
I'll take Pocket PC Checkers against Jackson Pollack any day. Or, how about artist that stacks rocks in a circle? What's up with that?
This is my sig.
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
Comment removed based on user account deletion
I don't know what field he thinks programers work in, but a lot of my programming experience has been WAY more creativity and design work than actual straight logic. For anything complex, especially gaming/complex systems, you are required to do a lot of creative design.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
Most of the time, users don't have a clue what makes a good interface, they don't know what they need. Getting feedback is only something that should happen after proper planning has been done. If your idea of UI design is throwing some rough idea out, and refining it with user feedback, you will end up will as poor interface. Hell, this is why most of the poor interfaces exist; they think it works.
How do you explain the sucsess of the iPod? When it first came out, a lot of people on /. said it would never sell very well. But they forgot one thing: It wasn't just first HDD MP3 player that was small and looked nice, it was the first to have a decent interface. Using and updating the iPod is so easy to do. The iPod is now the leading MP3 player, it's Apple's best selling products...all because they made it easy to use.
And I think that many developers *are* adept at designing systems that are usable
Unfortuantly most aren't (along with graphics artists to though), that's why there is so many bad UIs out there. Programmers design UIs that are too complex, because that's what they think is best, most of the time it's not.
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!"
This book looks like yet another piece of text that mixes up GUI design and information architecture. They're two very different subjects.
Just because you understand the fundamentals of information architecture does not mean you know squat about design. A good GUI need to incorporate both design principles and information architecture principles.
If you only focus on architecture you end up with an ugly UI. This is Why windows looks and feels like a donkey's behind... and OS X doesn't.
"Things are more moderner than before- bigger, and yet smaller- it's computers-- San Dimas High School football RULES!"
Sounds like people need to keep in mind the idea of "leaky abstractions".
I loved your post, and of course, you're right, but I find the BSOD vaguely unsatisfying. It's just blue. I think they should trick it out a little, you know? Jazz it up. Add some loud noises and maybe a surprising and startling display, like the goatse guy in a flash animation turning himself inside out and disappearing into a singularity.
That'd be kinda cool, wouldn't it?
User: "AAAAH! MY EYES! MY EYES!!!"
Farewell! It's been a fine buncha years!
I use to have a Nokia 3310 - it had a great UI - only three buttons to navigate - but mostly you just clicked the middle button to get to most stuff. It was a bit of an old clunker (to big) so I got a sexy new Errison T335. Terrible UI - I didn't release how spoilt I was - it was so difficult to navigate. It was so bad I changed back to my old clunker Nokia 3310. Next chance I got I swapped back to a much smaller Nokia 6510 - this one has 5 navigation buttons - not as good a UI as the 3310 but very similiar. Note: I don't work for Nokia - just my experience with mobile phones I've owned.
Its too bad if Donald Norman reverted to "Design" because the book goes deeper than just design (traditionally the relationship of function to aesthetics).
did anyone else read the title as "User Interface Design for Dummies"?
What would Brian Boitano do?
But in most cases, you're aiming at folks who aren't as technically-minded as you are. Now, all things are relative; this applies just as much to writers of compilers (whose users generally don't want to know about the details of context-free grammars, stack frames and optimisation, and just want to compile some code) as to writers of email clients or POS systems. But in each case, you must put yourself in your typical user's shoes - or find someone else who can.
That's not the end of the story, of course - there's still lots of creative work to be done, building abstractions and conceptual models for what your software does and working out how best to display them so the user will understand, working out the simplest way to handle each task the user might want to perform, and so on - but at the core of all of this is being able to see things from the user's PoV. If you can do that, then all the other decisions and choices will tend to go in the right direction.
In my experience, though, nothing beats actually being a user of your software! Not only do you get real understanding and lots of testing for free, but also a greater sense of achievement, and a real interest in making it the best!
Ceterum censeo subscriptionem esse delendam.
So, I've scanned through most of the comments stating the programmers shouldn't be allowed to do GUIs, that this or that GUI sux, etc, etc.
So, what's an example of a good GUI? I can't think of one off the top of my head. Certainly not any browser (either IE or Mozilla), and they are probably the GUI programs I use the most. Example: trying to enter text into a form like this is one of the most painful computing related experiences ever. And all the browsers do it the same way (almost).
I've tried Visual Studio. Gave up in frustration. I tried Eclipse. Gave up in a rage. Word makes me want to set the "designer" on fire. I will not touch it again, ever, if I can possibly help it. And let's just not mention Excel, as I may just spontaneously combust.
So, I use my "windowing" system either on Windows or *nix simply to run multiple shells, Emacs, and some Python interactive sessions. And a browser window or two.
So, the challenge to all the "HCI experts" scoffing at the programmer's GUI design ability is simply this - where's this great GUI we're all supposed to be imitating, or gazing at in silent awe of the HCI expert's power? Is there even *one*? I'd certainly like to see it.
I can think of some individual *widgets* that are good in a particular domain, like displaying a file hierarchy as an expandable tree. But is there an entire non-trivial GUI-based tool that could be held up as a shining beacon of excellent design?
Perhaps the whole idea of trying to model every problem domain in the universe as a collection of scroll bars, radio buttons, check boxes and tabbed dialogs is just fundamentally wrong, and will never work?
You are owned.
Oh, and btw I am not a UI person, GUI or NOT. I am however a life long user of various GUI's from the ASCII sort on through various Window Manager sets and then on to HTML based interfaces. Then of course there are the miriad assortment of custom GUI's done in various programs. So, I know what works and doesn't work for me.
What I have learned is that there really is no silver bullet of organization and functionality categorization that will actually allow for only one place of access or entry to the particular widgets feature. Not to mention that even when there is a de-facto or even a published standard in place, many use all the bad parts and fill in the rest with chaos. The ol' "File | Edit | View" trick common now is often full of nonsensical subcategories and features that either would have benifitted from having their own parent category or just belonged in another existing one.
I am therefore looking into a more database centric approach to GUI's. This could lend itself to themes (no, not colors and skins) for the user or administrator to pick ahead of time and then even allow per app customization as needed. This would mean that instead of just having a label of "Call up XYZ Config Program" you also specify meta data that it belongs too. This could be "Configuration" "XYZ" "X Rate with YZ Sampling", etc. The point is that you don't try to hammer the square peg into the round hole, but label it as all it belongs to. This multi-dimensional approach seems to be in need of Bookmarks for browswers as an example of user defined mapping and storage. You may have a section for Development Tools and subsections for C++ and Java. Then you IDE's and Debuggers. Next you have a section on Programming Tips and Algorithms along with your requisite "Code" on various web sites to use as reference or just to use. Then of course you have documentation and references, but then have a separate section for Books. Now just imagine this article here... what does it fall under? What if it was about Eclipse tricks or the Eclipse site as well? It would not be too hard to come up with a system where you checked or otherwise indicated multiple categories but that would really make a hassle out of viewing unless you actually went in and enumerated usage vs. category in some manner and optimized accordingly. (Think a less annoying method that MS uses for only showing things used recently)
Phew, makes my brain hurt just thinking about it... better enrich my neurons with some thought promoting beer!
Here is a great site that explains everything there is to know about UI's and gives real world (you use them every day) examples of "how not to"... It's dated, but it's very, very good... I recomend reading the Lotus Notes special page if you've ever used Lotus Notes - It's a Classic!!
This sig is in Spanish when you're not looking....