Slashdot Mirror
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. "
← Back to Stories (view on slashdot.org)
You can thank the slavish emulation of Motif's excreble file selector for the behavior of GTK's selector. KDE's file selector is just excellent, albeit a big *big* by default (which I love, laptop users hate). If it had a true file browser widget with true file objects (like Windows) then it would be perfect. Mmmm, I love being able to drag-n-drop files out of the file selector.
Windows' file picker would be nearly perfect if it didn't scroll HORIZONTALLY. Whose lame idea was that?
I've finally had it: until slashdot gets article moderation, I am not coming back.
Yeah, I really hate that too. Happened with Win'95 and the Display Properties dialog when running at the system standard 640X480 resolution, e.g. in Safe Mode. You could workaround with some slightly esoteric knowledge, but I'm pretty sure that wasn't too helpful to a typical customer.
I suspect a lot of the problem is that developers and testers both avoid running the software in the worst resolutions as much as they can.
I don't really care for scrollbars all that much, I'd rather see it broken up into subsidiary dialogs available on buttons from the main.
*seizes ranking Mac geek cred, points to stack 'o Inside Macintosh, but doesn't need it for this* ;P :)
The reason people are getting upset is because you didn't phrase it correctly. The only time 'OK' isn't the default button is when the action is seriously destructive. You know, "This action will format the hard drive your system is currently installed on/will edit the swapfile you're currently paging out of/will close the program and throw away the work you've been doing for the last eight hours. Are you sure? (CANCEL/ok)"
THAT is when you make cancel the default- when the action is _stupid_ but one that somebody might possibly want to do, maybe.
As to when you get a dialog box at all (I understand some versions of Word hit you with an OK dialog when you DELETE TEXT, which is insane), one of the major purposes is when the program is going to need more info before doing what it's going to do. Those dialog boxes have other controls in them and might be modeless, or modal like an old print dialog- the rule is to add an ellipsis "..." to the menu item. This tells the person working the program that if they hit that menu item, it won't take effect immediately- either more information is needed, or there will be an opportunity to back out if the action is horribly wrong.
This is not arbitrary, folks. There are some pretty major assumptions going on in these rules, and they are very much the reasons that you can give complete lusers Macs and have them not hurt themselves. There is no reason not to give Linux comparably sensible UI, and have it, too, be more approachable than Windows for your average noncomputer person. The point is, this is not done by putting a 'confirm' dialog on absolutely everything, it's done by figuring out "What's really destructive?" and having that default to cancel, by figuring out "What's most likely to make people go whoa-Whoa-WHOA-STOP-THAT?" or just get locked into a course of ACTION that they didn't expect or intend, and put "..." on the menuitems and "Are you sure? (cancel/OK)" in a dialog for that particular thing. And leave it off all the normal boring stuff! Geez. Never learn Mac human interface guidelines from Windows OK?
Seriously, Linux can have this and it'll be fine. Just do it right...
This is because of a design bug in the MessageBox Windows API function, it only allows for "Ok", "Cancel", "Yes" and "No" buttons and only in some combinations. If you want to use comprehensive dialogs, you would have to write a dialog yourself (create the DLG template, the dialog callback function,...) which is enough work to scare away lazy programmers.
In MacOS (and NeXTstep), it's a HI requirement that buttons have meaningfull names (like: 'Save', 'Don't Save' and 'Cancel'). Also, "harmful" actions (like 'Don't Save') have to be clearly separated from "harmless" actions ('Save' and 'Cancel'). NeXT takes it a bit to the extreme where sometimes very long titles are used.
Then, Unix has its own symbology... hmpf
Guess what. I use Linux/Unix almost exclusively and find "OK" and "Cancel" confusing. If I'm doing a monster download and I bring up a dialog box that says "cancel", does it close the dialog or cancel the download?
Think twice before answering that. Windows still clearly shows its single-threaded/single-user origins in countless ways and a lot of dialogs are modal - there *is* no distinction between closing a dialog and cancelling an operation.
In contrast, Linux/Unix is multi-user and it's not uncommon for the user to run multiple downloads (as a simple example), each with their own status dialogs. I might want to dismiss some dialog boxes without canceling the underlying operation.
This observation brings up a number of secondary issues. E.g., a lot of Windows applications think nothing of popping themselves to the top of the stack and grabbing pointer/keyboard focus. Under Linux/Unix, that's an incredible gaffe that close to a fireable offense.
(It's only acceptable in cases where it's acceptable to walk up to someone talking on the phone, slap the handset away from their head and start talking to them. The building's on fire, or a gunman muttering your name just shot his way past the front door. Nothing less.)
I'm not gonna argue that Windows applications shouldn't continue to use "OK and "Cancel", since that's what people are used to. But don't presume to lecture us on our symbology unless and until you demonstrate that you understand how the Linux/Unix environment is very different from what people are used to under Windows.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Who the heck keeps moderating up the posts that say "This is old news"? How is that "informative"?
Some of us haven't been here as long as you have, Mr. Coward, and find the site interesting.
--
Win dain a lotica, en vai tu ri silota
Another interesting, and tangentally on-topic site, is a graphical history of GUIs.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
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.
You're confusing two issues: good versus bad design, and command-line versus GUI implementation. I've come across simple, intuitive, easy-to-use command-line apps which don't need the clutter of graphics; conversely, the hall-of-shame contains GUI-based applications, not command-line ones, which rather invalidates your argument.
From my perspective, time is made more productive by typing, not navigating-and-clicking, and by automating and scripting text-based commands, not even more navigating-and-clicking.
I agree, except for the vertical switch configuration. In the United States at least, it's almost always the opposite - down is "off," and up is "on."
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
That's counter intuitive.
Test for mechanical UI's have shown that most people expect the 'positive' pole of a modal device (positive == 'on' 'yes' 'OK' 'save' 'accept' etc) to be down for vertical switches and right for horizontal switches. (and 'in' for switches on the Z plane )
Thus, to switch a power socket on you press the switch down.
Accordingly, for Computer UI's the modal dialogue should have the OK on the right and the cancel on the left.
In my youth I was into radio controlled model airplanes, and read an article on radio transmitter interface design (a pretty complex interface for a plane, which has to be operated by two thumbs and two fingers, while your eyes are mostly looking at the plane, not the device), which highlighted these notions among others. I wish I'd kept the article - there was obviously a lot of thought around the area of physical interface design, that computer people would do well to read up on.
-----
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!
Strong data typing is for those with weak minds.
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...
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). .... *CRUNCH*)
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
-"stop...."
> That's counter intuitive.
Interesting article. But the reason such dialogues
pop up at all is not to let the user find the
"OK"/"Accept" button as fast as possible, but
to make him/her *think* about what the program
is going to do.
Do you *really* want to format C:? Or wasn't it
your Temp data partition D: you wanted to format?
That's why the "Cancel" button should also
have the default focus (for "Enter"). The program
asks something important and the user is con-
fronted with "Cancel" and has to read the text
the program is presenting.
.sig: SEGV
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 +++
You're right on that one. That's why there's a link to it at developer.kde.org.
My favourite is the AutoCAD tooltip...
No, aargh! That is the Macintosh mindset! I want to be able to expect that pressing Enter actually does what I just asked to do, not the least "harmful" action as decided by someone else. BTW, my idea as to why OK/Cancel are placed as they are (i.e., OK to the left, Cancel to the right) is because in Western languages, we read in that direction, and OK is the choice we're typically looking for.
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
Speaking as one of the older geeks here...
I can remember something almost identical to the above being said twenty years ago, by a well respected software guru who believed it. At the time, I believed him.
I'm old enough to remember when discussions on Slashdot were well informed.
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.
... or bad ?
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
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.
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:
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).
-Raphaël
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.
--
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:
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:
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.
(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.
Crusade against lame software! votezone.com
...they could have fixed some of the mistakes in the time they now spent on whining.
Not everyone can code.
The cake is a pie
Aargh, the geek mindset. If you want a GUI go with the mac mindset...if you want geek, stick with your CLI. Then again, the Mac mindset gets me pretty bothered at times as well. The average user types with one hand and mouses with the other. I personally would be very happy with the focus on cancel, but unlike macs have the ability to change the focus of the widget to OK with the tab, as is the case on windows. The problem is ya can't select system widgets (or at least as a standard) on the mac. But back to HI stuff...what works for us, may not work for others. Computers were designed so people can get work done in the most efficient ways possible. 10-20-30 years from now, their will be no need for people like us (slashdotters in general) and all those visual programming languages we all hate will be our equivelent of Assembly later on.
Again, remember folks we are not the ones that ya need to design GUIs for and should not be used as any benchmarking. Read books on the subject (Apple's User Interface Guidlines is a start...not sure if its even mentioned in the article as I didn't read it). I've spent the last 5 years doing little but creating testing systems for humans...part of this is making sure the interface is obvious to the student and making sure one forgets he/she is in a computing environment. I nearly got violent about a year back when the university decided to use a committee to 'help me' design these things.
Few people understand Human Interface theory, even less implement it. If the KDE boys are really that interested in making things more usable, they need to designate one person the HI leader and anything they say goes...no frigin committees nothing. Make sure this person is studied in both the arts and sciences behind this technology. Yeah, and send him/her to a few courses dealing wih the Americans with Disabilities Act (or what ever is prevelant in yer country) because once Linux hits the desktop in any significant way, yer gonna want this stuff in there. Companies always forget about the disabled as its not very profitable for them (ie., hasn't apple the company with the largest corporate presence in this area dropped to maybe 10 people over the last few Jobs years...) Why should Linux...
blah
clif