Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
It's funny.  Laugh.

Human Interface Design Hall of Shame 127

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. "
This discussion has been archived. No new comments can be posted.

Human Interface Design Hall of Shame

Comments Filter:
  • That's not the only moral. The other thing they try to say is that have professionals look at your GUI, 'cuz when you let your developers on the loose you can get something like this.

    I worked for a GUI team in a rather large organisation and I found out that it's rather difficult to design a good gui. It takes several hours of talking to users of the future product.

    To get some sort of standard they made a Styleguide. We (I'm a developer too) have that GUI handy whenever we need to make windows.

    It's fun to see that M$ doesn't always follow their own styleguide (For instance, look at powerpoint, which is a complete UI disaster)
  • how dare you compare VI to emacs. with VI you can get some real work done it has just the right power for the job.

    emacs, is like that show "home inprovment" yea is fun to watch tim, but you know that he never gets alot of work done. tim calls "more power, more power... " does the job get any easyer? no and tim damages something in the end.

    pico, hmmm well guess you have to start somewhere... try VI unless you have a werd keyboad layout then uh never mind...

    #include "standard_disclaimer.h"
  • ...this has been required reading. I want to make 'em think about what works and what doesn't in conveying the needed information to the user in an appropriate and efficient manner.

    And I like to use it as a trump-card example whenever I'm convincing the proj manager to let me design the interface. (Most PLs are smart enough to let a TW do work that lightens the coders' load anyhow, plus we TWs are typically less busy at the early phases of the project.)

  • Yeah... quick RL test here.. the light switch I'm sitting next to is up, and the light is on.

    The ones in the bathroom are down, and the lights are off.

    Is my house not intuitive? Oh well.

    I would say, however, that most people push *in* to turn things on: monitor, speakers, phones, etc.
  • You are right, in my estimation, about the need for a common user interface. I, for instance, walk around the lab at work using a whole bunch of keyboards on different equipment. I look at those split "natural" keyboards, and the Dvorak layout, and think "maybe it would be better" but then think about how many keyboards would have to change in my life (and my employer would NOT buy me new keyboards for the Sun, the embedded systems I debug and test on, my main Windows machine, my Main OS/2 machine, etc.), and I just have to accept that things are the way they are.... because that's the way they are.

    There is a tendency for mavericks, people-who-run-with-scissors, etc. to be attracted to OSes like Linux. It allows them to be different, and to set up a User Interface that is radically different from the norm. This is a dangerous trend, however, if Linux is expected to ever go mainstream. We should "celebrate difference" where it's appropriate. But we shouldn't proliferate difference wherever possible.

  • As has actually been suggested, I can confirm that down is "on" here in the UK, and most of europe. The US use "down" and it confuses the hell out of me when I travel! So maybe button positioning etc. should be part of a localisation config? Or better still use controls which do not fall into these gray (grey?) areas....I remember reading that this is the exact reason there is no "lightswitch" control in windows.

  • Doh!! Must use "preview" more often. The US of course use up as "on", we use down as "on". I think the rest of that post makes sense.
  • 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.

    Indeed. Maybe that's why X Window interfaces weren't brought up in any substancial way. When the whole building is on fire, you don't point at smoke coming out of the wastebasket.
  • 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?

  • 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*
    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? ;P :)
    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.
  • Lotus Notes 4.x certainly deserves several assholes ripped for it's UI, but their "hall of shame" article doesn't pull it off very well. (Notes 5 is much better, but still has a share of problems.)

    Much of their criticism is not aimed at any built-in 'features' of Notes, but instead at a poorly designed custom mail application that is only used at one corporation. All of their complaints about misplaced and confusing buttons don't apply to Notes itself. It's like saying that VisualBasic or KDevelop has a crappy interface because people build programs with crappy interfaces with using the tool. (Their excuse is something along the lines of "Our criticism is valid because our company installed it that way!")

    In general, while I like the idea of the site, their site, the snotty attitude of the authors are pretty off-putting. What exactly is the point of ripping on a bunch of small time VB apps or some bizarre IBM CD playing program that no one uses? Also, they hold special hatred for "mouseover" buttons as are found in Netscape and IE -- I've seen quite a few stupid users, but never one that was so stupid that they couldn't figure out where their back button is!
  • 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.
  • But the ideal interface for a particular individual should be phsychologically determined.

    I like winamp and 3d-ftp because you can change the interface to suit your own particular aesthetic preferences. If you took that one step further, and enabled applications and more likely OSes to figure out how the user will most efficiently use the appication, OS etc. and then reconfigure the information presentation and editing facilities to conform to the user rather than the other way round the unwashed masses (and even our) frustration with UIs would be greatly reduced. Add in a bunch of aesthetic preferences, and you would have apps that are operationally and visually tailored to the user.

    Actually designing and coding such a freak OS is another matter entirely but reality sucks.

  • Another interesting, and tangentally on-topic site, is a graphical history [] of GUIs.
  • Yep, Win95's UI is pretty excremental. But there's the "Eat $h1t -- 5 billion flies can't be wrong" aspect to consider. What are 100 million users already familiar with, even though it's not the most efficient and well-thought-out design?

  • by Azul ( 12241 ) on Monday October 11, 1999 @03:57AM (#1624328) Homepage
    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.
  • Take a course in Human Computer Interface design and see if you still feel that way.
  • I just spent a good half hour browsing through some sections of that site, giggling to all the silly dialogs that programmers put in (Notepad's "Out Of Memory" error brings back horrid memories). But what I'm wondering, where's the "Keyboard not found, press F1 to continue..." error? :)

    Of course that isn't to say Linux programs aren't guilty of those things either. A big gripe I have with Netscape and GIMP (and I think other GTK progs too - not too sure) is when I'm saving a file - whenever I click on a directory in the file selector, the filename in the Save As dialog gets overwritten with the directory name. This means I either manually type in the directory name or cut out the file name and paste it in afterwards. In Windows it doesn't do this and it's one of the few things about Windows I like :)

  • A couple of IBM web sites I've hit have a similar dialog with every country on the planet in a drop down dialog. And since the USA's near the middle alphabetically, you usually have to get three or four rows of dialog box up before I get to my country.

    I sent this in to the iarchetect guys and they said they didn't have a web page hall of shame because there are other sites on the web devoted to web design.

  • Keyboard error press F1 to continue
  • i think the tags OK and Cancel are stupid half of the time. if there is a window about some open document i have not saved when i am about to close an editor, i don't want to read it. all these messages are the same anyway. except that you have to read them to know if it is "OK" safe the document before quiting or "OK" to quit without saving. i think the buttons should be "Save" and "Quit" or something longer perhaps. the same goes for the format-are-you-sure-thing. "Warning...blablabla....are you sure ?" button1 "format it" , button2 "dont format it" and yes, when it is as important as a format, lets default the "dont"-button.
  • For security reasons. It prevents the casual eavesdropper (say, on an extension phone) from continuing your transaction after you've hung up.
  • Its interesting to note that the only linux reference (i could find) on the site is preceded with an apology....

    i remember the first time i did a 'cpio --help' i just sat there and laughed at the output. :)
  • I'm in the same situation...and I'm glad to see they trashed the menu groupings. Personally, I think Lotus should have kept "Misc" menu, instead of renaming it "Action." :)

  • vi is a bit of a pain on dvorak. But otherwise vi is what I use for _everything_ (right down to my essays for school, i format them later :) )
  • 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 write my essays in HTML. That way I know some stupid wordprocessor isn't going to rearrange stuff and change the formatting where I don't want it to.
    If it needs to be double-spaced, indented, etc., I use a style sheet.
  • The appropriate judge is the target audience. It's nice if it can also be standard. It's worth effort to cause it to be standard. But that's not what's really important.
  • 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."
  • But the whole building is not on fire! Granted, some of the interfaces do suck in a big way (Netscape comes to mind). Granted, it would be better to have a mediocre widget set in every program than some extremely great and some extremely bad. But there used to be some XWindows programs with really *AWESOME* interfaces. So no, some (most) parts in XWindows tend to suck a lot, but there are really great interfaces out there. They should be in their hall of fame. Btw, all of this is becoming a little irrelevant since GNOME/KDE, which are getting all standarized now. Alejo.
  • The interface of a mechanical toggle switch which moves is quite different from a flat (mechanical or virtual) switch which is pressed, though.

    The reason toggle switches are right or down to turn on is probably because in most languages are written left to right or top to bottom. (There are some languages which go right to left, but I'd be surprised if there are any that go bottom to top!) So we're culturally biased to associate these directions with "increase" or "progress" (as in numerical sequences.) Horizontal linear volume sliders always increase left to right, for example. And thus the right-for-on switch.

    But the buttons on a dialog box don't move like toggle switches, so they don't have to accomodate the directional bias. Instead, they are righfully arranged in order of preference. Most of the time when you get an OK/Cancel dialog, you select OK. And it only makes sense that the most likely choice is presented first.
  • by Azul ( 12241 )

    Sorry, that was meant to be Jakob Nielsen's essays [] (specially The AntiMac Interface []) and Neal Stephenson's In the Beginning was the Command Line [] far more enlightening..

    I find Jakob highly overrated (but still far better than this interface hall of shame). I consider Stephenson's essay an absolute must-read.


  • Agreed except for the part about formatting them later -- once I discovered \LaTeX, I wrote and formatted in the same process. As the other poster mentions, HTML is good for this too -- probably better -- but TimBL was still busy inventing it when I learned \LaTeX.
  • # (* on most of the systems I use) is the equivalent of sending a FIN. (Then you get to hear the voice politely say "goodbye" and hang up: FIN-ACK (: ). If you just hang up the system has to let the port time out and then close it. Sending the FIN has an efficiency advantage for the system (don't have wasted ports waiting to timeout) as well as the security advantage for you that the other poster suggested.
  • It is easy to tell which thing "OK" would do and which thing "Cancel" would do. When you see one of these boxes, it is reminding you of a consequence of the action you just commanded the computer to take. "OK" acknowledges and accepts the consequence. "Cancel" interrupts the action.

    Windows gives the interactive user so much control that you can cancel a system shutdown because of an unsaved file. I think Linux would do well to support this model if it wants the desktop market.

  • The best guide for UI design I ever learned was from an educational psychologist who explained it this way:

    For any of us at any given time, a task is either associative or cognitive. Associative tasks are basically stimulus/response patterns while cognitive ones require some symbol manipulation (eg internal dialog.) At any time you can have an almost unlimited number of associative tasks going but only one cognitive one. Thus when you're driving along a familiar route in good weather and light traffic you can have an interesting discussion going with your passenger(s) but bad weather, an unfamiliar neighborhood, or the kid running out into the street suddenly leaves you no attention for talk beyond mindless "unh hunh, sure-- shut up!"

    That's why pilots (for instance) drill relentlessly on procedures. In an air emergency you've already got way too many things going on requiring thought for you to waste any on trivia like turn mechanics. (The movie Apollo 13 alluded to this rather nicely.)

    How this relates to UI design is simple: the UI is there to let you get other things done, not to be an end in itself. Someone writing should be thinking about the words, not about "now where is the control for ..."

    Of course, as NASA has proven, any task can be made automatic with enough training. It's a learning-curve sort of thing, with one of the big rules being that you don't surprise the user. If dragging a file from one folder to another moves the file in one case it had danged well better not copy it in another. Far better if, having learned to move things by dragging, dragging ALWAYS moved them.
  • Also, some of the examples there are criticized as interface problems but are just plain bugs...Are those interface-design problems?

    Hell, yeah! Anything, I repeat, anything that the user sees is considered part of the UI. That includes those annoying error messages.

    Alan Cooper, you know, the UI guru and father of VB, hates message boxes with a passion. So, if there's a useless one, you're commiting some kind of sacrilidge. I have to agree with him; hell, even most of the ones ppl think are needed are not required at all. The programmers just have to find a clever way of showing what went wrong, as opposed to taking the easy way out.

  • Well - somebody up there could have designed our genitals better...or is it just me?

    First post? My first!!!
  • by Anonymous Coward
    Need to say more? In requesters, I expect the
    "Cancel" gadget to be on the right and "OK"
    on the left, because it's more secure (in most
    cases you have to move your mouse to click
    on OK).
    Well, this is something but inconsistent as
    I see more and more software coming up.
    Then, Unix has its own symbology: "Apply" and
    "Dismiss". hmpf.

    Or: "Save/Use/Cancel". Isn't that more intuitive
    for preferences than "OK/Apply/Dismiss"?
  • 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.
  • by deefer ( 82630 ) on Monday October 11, 1999 @12:58AM (#1624360) Homepage
    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! :)
  • We used to use a text editor called PMate (Programmers' Mate?) for DOS 3.1 about 6-7 years ago...
    It was the dogs bollocks. It basically had regex way before any other PC text editor even dreamt of it; you could substitute hex values on the fly...
    It was a Real Programmers tool; the only help file you had was a six sheet manual of each command, and each command looked like a burst of modem noise. I can still halfway remember some of the commands; to quit and discard changes it was something like Escape-Escape-Q-Escape-Escape-X.
    Aaaah, those were the days!! And no bloody paperclip mincing around on the bottom of your screen, either!!! It would surely seperate the hackers from the scriptkiddies today, anyway! :)
    Anybody else remember this?
  • I'm missing examples of interactive CLI tools
    that also ask you stupid questions sometimes.

    Starts with "Install here [type "yes" or a different
    path]" and ends with programs needing you
    to type 'y' or 'n' on a German keyboard,
    where 'y' and 'z' are swapped and pressing
    'y' just doesn't make the program do anything..
    Explain this to a newbie.

    My all-time favorite is still the "Do you really
    want to quit?" Requester after you close an app-
    lication's window..
  • by David E. Smith ( 4570 ) on Monday October 11, 1999 @01:24AM (#1624363)
    ... 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...

  • by Bothari ( 34939 ) <[tp.obacten] [ta] [ohlavracg]> on Monday October 11, 1999 @01:04AM (#1624364)
    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*)
  • Ok, a lot of the stuff is hilarious, but that is not point at all. This is excellent advice for programmers, anyone doing GUI apps should definetly check the site out. HUGE amount of common and not-so-common errors is listed on the site. This goes straight to my programming bookmarks.
  • > 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.
  • by Homicide ( 25337 ) on Monday October 11, 1999 @01:27AM (#1624367) Homepage
    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 +++
  • by semis ( 14252 )
    Where are the X apps?

    I'de like to see this person review some Gnome or KDE apps - in depth constructive criticism like this would help make our favorite DE's even better!

  • You're right on that one. That's why there's a link to it at [].

    My favourite is the AutoCAD tooltip...
  • The site is interesting and humorous in some parts, but many of their criticisms are petty. They have some good points, but like, thier continuous cynical and hyper-critical attitude wears a bit thin.
  • 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.
  • Although it deals mostly with interfaces on physical things rather than on computer screens, and is notably dated in places (first published in the late eighties, and it shows), Donald Norman`s book The Design of Everyday Things [] has a lot of very intelligent things to say in this regard. It talks about how people percieve interfaces and how they react to them. One of his big concerns is intuitiveness - people should be able to work out how to do something just by looking at it - and how designers have great problems understanding that people might find their products hard to use, simply because they`re so used to them. He deals with all this in a light-hearted manner with loads of good examples. Well worth a read, even if you`re not designing interfaces.
  • "Specify the mount point of the root directory" it sez...
    Hmm...."/root" types I....
    "The mount point for the root directory is not specified" it sez...

    Repeated 3 times until I figured out that all it wanted was "/"...

    2 or 3 lines of text would have simplified this no end, & why does it even ask? You can't call it "tulips" instead of "/".....
  • I noticed the following, from the well-deserved Notes Criticisms:

    Unfortunately, to learn to use Notes the shipping clerk, the secretary, and the vice-president of finance all have to develop a programmer's vocabulary. Computer applications are supposed to shield the user from such terminology.

    This sounds a little too general. I believe the statement is more correct when made in reference to proprietary vocabulary/terminology. What does the rest of /. think about it?

  • While the Windows UI may be pretty bad, everyone and their dog is famillar with it. If KDE and Gnome really ARE going to take over the desktop, they need to conform to the de facto standard.

    The need for QWERTY keyboards is past, it has been for at -least- 20 years. But here we are, with 99.99% of (US) keyboards conforming to the standard. Why? Because everyone who will use a PC, or a typewriter, or word processor is -trained- to that standard. Any 90% of the PC using world is -trained- to the windows GUI standard.

    If Linux is ever to succeed outside the server, embedded, or technogeek markets, it's interface will become MORE like MS's, not less.

  • Indeed... I use KDE on a Toshiba Libretto with an 800x400 screen. One of the things which drives me nuts is that when KDE dialogs (such as the KDE Control Center) are bigger than the physical screen, there is just no way you can position them so that controls in the lower part of the dialog are visible. You are reduced to tabbing blindly in the hope of finding the right control...

    Why on *earth* can they not grow scroll-bars when they're too big for the screen?

  • Maybe you're using the wrong window manager. Try Enlightenment [] -- I use it, and I almost never touch my mouse.

  • The problem is not a website problem. It's because the dropdown menu widget is un-comfortable to use as there is more than one screen tall of entries...

    The problem occurs when you have hundreds of countries in a dropdown list, because un-professional web designers donnot test often under linux.

    I've already seen black dropdown menus with black text on it... because on Win platforms the dropdown widget has always a white background, so nobody knows that the background color of these "modifiable lists" is the container's background color; that implies that sometimes it's unreadable...

    I think too that the possibility to type the first letter to scroll the list is pretty neat too...

    I hate MOTIF dropdown widget, but do the QT and GTK ones behave???
  • 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

    How can that be, when just about ever switch I've ever seen has "up" for "on"???

    Do you have sources for this?

  • Speaking as one of the older geeks here...

    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.

    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.

  • To which I say: DAMN STRAIGHT!

    This is what slashdot is about. Thank you to whoever moderated this, as I set my threshold to 5 and hardly ever see anything truly useful.

    Buddy, go buy yourself a beer.
    That was good.

  • YES...thank you, many excellent points, and now i would like to attempt (run away, quickly) to add another level to this...

    one of the common themes that seem to be present in the items of the hall of shame is that often, the manner in which mistakes are made suggests that they are being made by ARTISTS (for lack of a better term) rather than DESIGNERS. where as a designer is responsible for creating an interface "in the users' best interest", the artists are responsible for making the interface most initially appealing to the eye. the artists know a great deal about that which is appealing to look at but are generally not trained to look at how the interface will be used.

    since the majority of people (or should i say "the average users") tend to look at things like screenshots first, and since the first impression often has the most weight (again, on average), the artists opinions are given more weight than the designer. the end result of course is an interface that looks pleasing and may even forcefully grab your attention, but after using it for some time, may prove to be lacking in usability.

    this all basically relates to advertising and, subsequently, sales.

    really, it all comes down to money. companies want to sell the most software, so they put the most effort into making things *appear* to be useful, when in fact they ignore and sometimes blatently contradict, basic rules of interface design. but this trick works of course, because how many people actually return a piece of software after they've installed it, used it, and become acustomed to it? very few in the grand scheme of things.

    hey neat, i got <> to work...


    Keyboard not found.
  • by Zoltar ( 24850 ) on Monday October 11, 1999 @05:47AM (#1624384)
    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.

  • An electrician friend of mine once told me that switches should be wired such that up was on. The rational for this was that should the catch fail, gravity would cause the switch to disengage.
  • Perfectly accurate. The end-user shouldn't need, and shouldn't be exposed to, the technical jargon.

    Actually, let me go a bit farther. The program designed for the non-technical end-user should be designed in such a way that even if the user were to be fluent in technical jargon, they would gain no benefit. Whatever can be done should be easily doable without reference to the internals. Only debugging or enhancing the tools should require a knowledge of the internals. And by preference the debug messages should be "sensible". If you can't make the message sensible, design it so that the user can copy it and paste it into his e-mail. (If it's a commercial package, design it to, at the user's option, fire a context specific diagnostic dump off to tech support [And I would like the DUMP to say something like "Error 37 encountered in gen/module/peanuts/"Ralph", "Waldo", "Emerson") at line 27: expected a string less than 15 chars long. received ]).
  • You can also get real work done with emacs, and faster than you can with vi - if, and only if, you're willing to work at a slower rate for a month or two as you learn the ins and outs of emacs.

    It's also a question of environment - don't even try to use emacs over a slow link. I became a master or vi-ness when I had a 2400-baud modem link to a VAX on campus - forget about emacs. But when I was sitting in front of a Sun 3 every day, it was worth it to learn emacs - its customability and X support will reward the patient seeker.

  • / is the root directory. Everything branches out from the root.

    All are off of the root directory.. :-)
    I'm not sure why Disk Drake would offer you to change your / ... unless it meant root partition.
  • The message board I run on my site ( would probably be considered a user interface nightmare by most yardsticks. The main message index looks like a spreadsheet - it's a vast, imposing green-and-black grid full of numbers in sequence. The order is counterintuitive, new messages are on the left, new threads are at the top, but on the message display pages themselves, the threads are listed newest ones at bottom.

    But yet I constantly hear from people how much they love it, it's so easy to use.

    I get away with this sick design because I know who my audience is. These are knowledgeable computer professionals, who aren't afraid of a short learning curve, and who prefer having the most information presented to them in the most efficient way possible. This interface frustrates the hell out of the inexperienced, but is absolutely ideal for its audience.

    The final authority on any user interface is, always, the user.
  • A friend of mine was slightly bored one day adding some error messages to a VB printer server. He made some of the messages amusing. "Orange Marmalade? No, Paper Jam!" is arguably the most famous.

    The support desk don't mind, though they would have preferred knowing about it before the first puzzled user called. I've also met someone who encountered it in the field and reportedly was literally ROFL :-). My friend has since moved onto another area, but the maintainers of it see no reason to remove the message.

  • "most people expect the 'positive' pole of a modal device (positive == 'on' 'yes' 'OK' 'save' 'accept' etc) to be down for vertical switches"

    Say What?!?

    WTF has "on" ever been "down"? All the light switches I've encountered have been "up"... as well as blenders, starters, stereos and other electrical stuff I recall toggling on.

    Mebbe you're British?

  • AC discusses this term at some length and makes...

    Sorry, but I don't read AC's (Anonymous Coward) production, their to much of it.

    (note: for those that think I am nut I completely understood that he was talking about Alan Cooper, this is just a (bad?) joke ;)
  • They do have a lot of good points,
    but what i meant to say is that some of the things they attack are actually not disturbing at all.
    For instance, they complain that IE4 notifies you each time a download is complete. they say that microsoft 'didnt realize trhis was a problem when it was realeased' and you have to 'download a15mb fix that includes a way to turn that off'.

    Um, actually i think the notification is useful. I wish netscape did that. While they should have originally included a option to disable that, it isnt a big deal, or an oversight by them really.
  • If you are using a German Keyboard, you shouldn't be typing "Y" anyway. You should be typing "J".
  • Why are gui programers so fixated on dialog boxes? For example, almost all browsers rudely interupt what I am doing by poping a dialog box up about not finding something. Do they think I would not notice if they page was replaced by a nice message? ( Perhaps ie does this. I've only used it once. ) Most one responce error conditions could result in a little red error message on the message bar. Only fatal and vital questions should be put in dialog boxes.
  • You've hit upon a major issue. Once you've moved past the point of designing the interface for the programmer, then what? You have to design for "the user". But who's that? There's lots of different kinds of users out there, and no one interface will be optimal for all of them.

    For great coverage of how to deal with this, see Alan Cooper's latest, "The Inmates are Running the Asylum". Killer book, maybe not quite as good as "About Face" (and some of it is even a rehash), but his technique of using "personas" looks great. Check it out.
  • While you make a valid point, I think it makes sense to make the unrelated note that free software will never in itself provide the masses with good UI. Quality UI isn't free, and isn't a product of anarchy.

    The overriding spirit of free software is very close to the UNIX minimalist philosophy: 'make everything as effecient and functional as possible.'

    Compare this to the Apple Design philosophy, which is more like: 'do whatever it takes to make the user comfortable, including sacrificing speed or functionality.'

    (And of course, there's the worthless compromise of Windows: 'be somewhat easy to use and somewhat functional, provide for many features, but maximize profitability. Show no concern for size.')

    Free software projects churn out great functional software, but can't in themselves provide the kind of rich, out-of-the-box pleasantness you get with high profit, well designed Apple stuff (not that all Apple stuff is awesome, but the best of it is really great). Or look at NeXT--great interface, not free. Software UI needs strong central design leadership and that requires funding. The anarchy and distributed design of free software that works so well to fix technical flaws doesn't produce a good UI. Free software projects value functionality over looks. The free window managers, a product of decentralized design, sure don't make for a consistant, intuitive experience throughout.

    Strong central design creates great stuff. Compare European transit systems to the liberal chaos of (SF, CA) Bay Area public transit. When one group is in control of an area's public transit, it works well. In the Bay Area, you have two handfuls of agencies all trying to do things the way they like. You can't transverse the transit systems without a lot of frustration.
  • I disagree with you on two main points. First, I don't think that site is necessarily windows-centric because that represents a majority opinion, but rather that windows 95/NT tends to be the most flagrant violator of ease-of-use principles. I wouldn't be suprised if more than half the people posting to that site were mac users forced to tolerate crappy windows interfaces. Native windows users tend to ignore/accept bad interface design, because they have never used a more intuitive GUI or because they just say "that's the way computers/Microsoft are. Second, I think designing a program to be easy *is* easy. It would take the most novice, inexperienced mac programmer about 10 minutes to think up an easy application interface that is universally consistent and avoids the many pitfalls listed on the site. If programmers for that platform can do it, programmers for other platforms should be able to do it as well.
  • The reason for the bracket shortcuts is that those are the same shortcuts that macs use for forward-backwards...sort of. Except instead of pressing ctl (at far end of keyboard, damn uncomfy), macs use the command key (located where the alt key would be on PC's). Try pressing alt [ or alt ]. Doesn't that feel good? Unfortunately, Mozilla did something akin to microsoft, copying a good idea from MacOS and then changing something enough that the idea is no longer so good. Steve Jobs (quoting Picasso) once said "Good artists create, great artists steal." It's okay to be a great artist, just remember to be a good thief.
  • There is scientific evidence that shows, for example, that 8 items on a menu is less acceptable to humans than 7. If you choose to ignore the evidence, e.g. by inserting 18 items in the "Table" menu of your word processing package, you risk alienating your user base. That doesn't mean they'll not use your package, it means they'll not enjoy using it and moan to everyone about how awful it is.

    You see there is too much subjectivity in user interface (UI) design. I have worked with many talented engineers who think they know what makes a good UI. But they do not. What they produce is often ugly and non-intuitive. And project managers either don't take UI design seriously or inject their own brand of subjective nonsense into the equation. I have seen some hilarious ideas of how menu structures should look.

    Most modern computer user interfaces are a mixture of good and bad design. Pecking around my NT desktop at the moment shows the balance tipping toward the seriously awful.

    The interface between computer and human is the most complex in any system. People have been killed because of poor user interface design (the Therac 25 disaster). We need to study good and bad design and pay more attention to the evidence of UI studies to ensure that we can make best use of computers in the future.
  • When I first saw it I said - WTF???
    I'm glad they talk about it... it really deserves Bad GUI Design of the Year. How many of us had to endure it while watching our Phantom Menace trailes back in spring? Raise your hand!

    It's almost as bad as e-forms, where a clueless programmer takes a paper form and paints it verbatim on a gui.

  • And should gravity fail, the switch would remain in position so you could make your way about the ceiling.
  • by Raphael ( 18701 ) on Monday October 11, 1999 @01:52AM (#1624404) Homepage Journal

    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).

  • by linuxci ( 3530 ) on Monday October 11, 1999 @01:55AM (#1624405)
    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.
  • Sort of off topic:

    Once on one of those automated electronic phone calls, I had reached the end.

    The very polite voice on the end said "To end this call, press hash or simply hang up the phone."

    Well, WHY THE HELL HAVE THE PRESS HASH OPTION!?!? If you are going to have to hang up the phone anyway WHAT'S THE POINT OF PUSHING HASH!
  • I've spent a long time in this site, and I (re)discovered lots of funny annoyances in Windows mainly and in the mac world too..

    But something that really sucks (and that's not mentionned in the website) is dropdown menus under X, especially with lots of entries.

    As an example, point your favorite Linux browser (you don't have much choice, netscape) and go to a commercial website. You want to pay/register/subscribe something and you have to choose your country in the countrylist : instead of typing "FR" and I'm ok, I have to go in the list to look for "France". Better, I cannot type "F" to scroll to the "F" section.

    Have a look at the RATP site here [] and try to get the map for the "Gare du Nord" neighborhood... pretty funny isn'it???

    Worse, if you noticed it, the dropdown menus are wasting lots of space on the right side of the screen, and finaly you are stucked because you have to click on "More..." and the new choices you get are overlapping the old ones, so if you try to get a choice above the "More..." choice, you're stuck.

    This really sucks, but nobody cares : everyone is browses the web with Win/MSIE, after all...
  • ..or EMACS for that matter.

    Yes, I'm a proud pico user. (Hey - I'm a programmer, I write a perl script to do anything pico can't do)

  • I thought the idea was, to show the world how Linux is BETTER than Windows, rather than emulate Windows' famously flawed user interface pixel-for-pixel.
  • by Clairvaux ( 98631 ) on Monday October 11, 1999 @02:56AM (#1624414) Homepage
    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

  • by Anonymous Coward
    It is a good site but it's obvious that the majority of the items are things they come across frequently, and since they're obviously an MS shop that means MS software gets the brunt on their crticism.

    If they took a good dive into the UNIX world they could literally increase their stockpile 100 fold just by running an install. Programs like vi could fill absolute volumes.

    Software engineering is a great field and I love it, but there is one thing that I've learned very, very clearly: If developing a program to do X requires Y time, developing it to be intuitive and logical will require 4Y after all design and planning comes into play (not only is it 4Y, but there is a logic and empathy requirement that many programmers don't have...hence lots of really crappy interfaces even when the programmer tries hard). Writing a command line utility that takes 15,000 flags and options, some dependant on others some stand-alone, is EASY compared to doing the same function in a logical and usable UI.

  • Actually, having the 'fallback' or 'default' response to a prompt fold back to the option safest for the system (and most frustrating for the user) is ye olde UNIX tradition. On ancient unices that I have run, you can just close your eyes and hit control-d a few times and be assured that you'll be logged out of the system. Or as the case may be (if you're at a command prompt) a single control-d and you're often out of the system sitting at a login: prompt.
  • If I am not mistaken (please correct me if I am) the convention for wall-mounted light switches is 'up' for on in the United States, and 'down' for on in many other countries.
  • The first company I ever worked for accidently shipped a version of our software with an error message that read "Stupid user error".
  • by Anonymous Coward
    "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. "

    50,000 computer shops all "going their own way" (rather than begin "lemmings")...that is a true nightmare. Especially given that the UI choices of developers are often horrific for the end user (One of my co-workers insists upon individualizing his projects. They end up being complete turds with awkward, unusable interfaces).

    A software program is a tool to achieve an end, it isn't a way of life. I had to replace a deadbolt the other day and I admired the standardization in the field: Most of the components follow very similar guidelines. I didn't need to buy a new door or drill any new holes. That's the beauty of standardization. I'm sure there's a wiseass out there that is sure, without any proof, that they could design the deadbolt installation mechanism better, but unless they have qualified proof that they have a better thanks. Just being different doesn't make it better.
  • ...they could have fixed some of the mistakes in the time they now spent on whining.

    Not everyone can code.
  • Just out of question -- you mean that to turn on a light by flipping the switch up is counter-intuitive? Or to open a door with the handle on the left? Or to lift the handle on a minivan trunk? Maybe I'm just reverse programmed here :) (That's waht my wife, in Psych. studies seems to believe at least)
  • 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 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...



Some people carve careers, others chisel them.