Human Interface Design Hall of Shame

dayeight writes "I'm taking a class on human interface design at Bennington College, and started doing some out of class research, and found this site to the most entertaining by far. "

Comments

Re:Already posted in July 1998, more links...

[Trepidity]

Another interesting, and tangentally on-topic site, is a graphical history of GUIs.

It's not that great.

[Azul]

I saw this some months ago. I found it rather superficial. First, it just covers applications that use the Windows widgets (well, perhaps MacOS too? I don't remember). As everybody knows, there are a LOT of different widget sets in the Unix world, where every program used to have it's own before Gnome/KDE. Also, some of the examples there are criticized as interface problems but are just plain bugs. For example, see the Netscape's Spelling Checking `interface problem' (a spell checker that suggest the word where it is reporting mispelled) or the `Error: The operation completed succesfully' window which we just know it's cause by a bug that thinks there was an error when there wasn't and then prints strerror o sys_errlist or whatever the equivalent of that in Windows is. Are those interface-design problems? (I pointed this to the author and he said he things so). Finally, I believe it has way too many examples but I'd like more analyzis. Some papers on interface design would be best. It just shows me many things I should't do (most are obvious) but does not tell me how to design a really good interface. I found Jakob Nielsen's and specially Neal Stephenson's essay on interfaces far more enlightening. Alejo.

Re:The worst human interface

[deefer]

Yeah, but it's amazing when you interface the male/female units together... No crimping tools required (unless you like that sort of thing...).
But mind out for viruses, use safety equipment when working with unfamiliar units, and always be aware you may create a child process! :)

The moral of the story...

[David E. Smith]

... is that designing a good user interface is hard.

A talented programmer can work wonders behind the proverbial scenes. A good algorithm can make a program a joy to use, in some senses (namely, in the "hey, this thing is fast" sense). And given a good set of widgets and a fun toy to hook them together (things like Delphi), a skin can be wrapped around that neat algorithm quickly and you have something that can be termed a useful product.

But is it a good product? Is it a usable product? Not necessarily.

I can, and have, thrown together quickie UI's in Delphi. For testing purposes, and prototyping, it works just fine. Heck, half the time the buttons are still labeled "Button 1" and similar, because I know what they do.

Would I take a program like that and give it to anyone else? Hell no.

Entirely too many programmers think that because something is intuitive to them, it will automatically be intuitive to the rest of the world. It's a sin most of us have fallen victim to, and it's something we need to do something about. The very existence of classes on UI means that there may be hope...

This matters...

[Bothari]

I'm quite happy that this site has made it to /.'s attention. It has been around for quite a while (I first saw it 3 years ago!) and it points out some of the basic rules in interface design (ID).
Might be just me but if Linux Apps are missing something nowdays it's ID.
For those that complain about "the good old days" of strictly command-line apps and how we don't need "no steenkin interface" I'd like to point out a simple fact: Most apps are there to get *work* done, not to make you spend all your productive time *learning* how to use them.
It's no use making an app no matter how well coded/fast/brilliant it might be, if no-one bothers to use it....
No, I can't spell!
-"Run to that wall until I tell you to stop"
(tagadum,tagadum,tagadum .... *CRUNCH*)
-"stop...."

Just out of interest

[Homicide]

How many of us can hold our hands up, and claim never to have put an amusing error message in a program, while writing it, and forget to take it out/change it to something 'understandable'

+++ Out of cheese error +++ Redo from start +++

I've often wondered ...

[Zoltar]

What group of people are the best at deciding what is a "good" UI and a "bad" UI ? Should the test be a bunch of non-computer people, or a group of long-time seen it all computer type people. I work for a small software company and I can talk to two people in a span of 5 minutes with completely different opinions of our interface. I think (other than the basic commmon sense stuff) that what is "easy" or "intuitive" can vary from person to person depending on the type of person.


For instance... we have big giant in your face butt ugly buttons on our UI, designed to be stupid simple for the average schmoe who doesn't give a crap about computers, but just wants to get the job done. So I guess we have designed the software for a non-computer type person, in a non-traditional way. I'm sure the UI purists would go into a coma if they saw it... but does that make it wrong ... or bad ?

I get a lot of comments from customers about how easy our stuff is, so I guess we have accomplished what we set out to do, yet many of our dealers have said they would like something that has a more *traditional windows look.* It seems that your better off being lemmings rather than trying to go your own way sometimes.

Already posted in July 1998, more links...

[Raphael]

A link to that very interesting site was posted in July 1998, so this is not really new for those who have been on /. for more than a year.

Several interesting links were posted among the replies to that story. I will re-post a few of them here, so that you do not have to browse through the old messages:

• useit.com: Jakob Nielsen's Website.
• Usable Web: Guide to Web usability resources
• MacKiDo/Interface: What is user interface, and what is superior (and why).
• User Interface Engineering

Follow these links if you are interested in user interfaces (mostly for GUI). There is no lack of good advice on the net. This makes me wonder why we still see so many bad user interfaces in the latest programs (even in GNOME and KDE).

Hall of Shame, Open source developers can learn

[linuxci]

This site has been mentioned a few times before on Slashdot but the more they can mention it the better as it's useful for developers of software that uses GUI's to see the mistakes made by others.

MS has taken a bit of a hammering here and they deserve the criticism but so do many other companies that produce software less intuitive than MS's (e.g. why is the Options menu for IE4 under view for Windows, Edit for Mac and in IE5 it's under tools).

For the new user the number of applications with different toolkits under Linux can mean inconsistency for the user although the developer has more flexibility. As well as different toolkits producing a different look and feel you have different developers who have different ideas about the options on a menu where buttons should be located, etc. The free software world can learn a lot of lessons from the mistakes of MS and others if they want to be intuitive to the average user.

As I've used PC's for a while (DOS, Win3.1 then Linux) I've grown used to the inconsistencies of different applications and it's never really bothered me, however with many new users this will be an important factor especially if they're used to the Macintosh way of doing things.
--

"Intuitive"; Alan Cooper; Interface paradigms

[Clairvaux]

Ha! One of those interesting confluences.

I just now happened to be engaged in my semi-annual receive-ye-wisdom-from-the-Master-Alan-Cooper ritual. This ritual involves critically examining my most recent 6-month interval of design experience in relation to his book on design: About Face: The Essentials of UI Design.

First, a comment about the term "intuitiveness." AC discusses this term at some length and makes points about it that I agree with strongly.

A few choice excerpts starting from p. 57:

"No rational thought is evident in the process [of intuition.] ... In the computer industry, and particularly in the user interface design community, the word intuitive is often used to mean easy-to-use or easy-to-understand. I'm a big fan of easy-to-use, but it doesn't promote our craft to attribute its success to metaphysics.
...
Instinct is a hard-wired response that involves no conscious thought. Intuition is one step above instinct because, although it requires no conscious thought, it is based on a web of knowledge learned consciously.
...
Intuition is a middle ground between having consciously learned something and knowing something instinctively. If we have learned that things glowing red can burn us, we tend to classify all red-glowing things as potentially dangerous until proven otherwise."

I often see people in our industry confuse the terms "ease-of-use," "intuitiveness," and "instinctiveness." The last Marketing VP I worked with was fond of saying that the nipple is most intuitive interface there is. This is just flat out WRONG. The nipple is an instinctive interface -- we're born with the knowledge of how to use it. Well, some of us anyway.

Intuition, on the other hand, is a non-rational, often non-conscious process of transferring other, learned knowledge to a new set of circumstances. Definitely not true of a nipple.

Now that I've beat the "intuitive" issue into a bloody pulp, I can address David's conclusion. He said:

Entirely too many programmers think that because something is intuitive to them, it will automatically be intuitive to the rest of the world.

I respectfully disagree with the first premise. I don't think the typical programmer gives much thought to the interface or interaction elements of their work at all. How many developers do you know who give thought whatsoever to concepts like "affordances," "visual fugue," or "visual motif?" Primitives vs. idioms? Restricting the interaction space?

AC has a superbly articulated explanation for this.

"The technology paradigm of user interface design is simple and incredibly widespread in the computer industry. The technology paradigm merely means that the interface is expressed in terms of its construction--of how it was built.
...
The overwhelming majority of software programs today are Metabolist in that they show us, without any hint of shame, precisely how they are built. There is one button per function, one function per module of code, and the commands and processes precisely echo the internal data structures and algorithms.
...
Engineers want to know how things work, so the technology paradigm is very satisfying to them. Engineers prefer to see the gears and levers and valves because it helps them understand what is going on inside the machine ... but most users don't have either the time or desire. They'd much rather be successful than be knowledgeable, a state that is often hard for engineers to understand."

(Emphasis added)

I'll add a comment to this. Many engineers fall victim to this technology paradigm, but many engineers are also (justly) proud of their efficient/clean/structured/extensible/blazingly fast design of the ENGINE. Perhaps they unconsciously resist anything that hides, conceals, or otherwise covers the beauty of their design.

Well the fact of the matter is, very few people examine the engine or transmission or suspension when buying or driving a car. In fact few people even care. Drivers are typically interested in getting where they want to go in reasonable comfort without mechanical malfunctions, running out of fuel, or having to understand the disc-brake mechanism. That's why the DESIGNERS of cars are different people than the ENGINEERS .. perhaps our industry too will someday embrace this distinction. Until then, we engineers have sole responsibility for the utility of our creations. We still mostly have to wear the interaction-designer-hat and should take the time to learn from people who spend time really thinking about these problems, like AC, and iarchitect.com.