Slashdot Mirror

Microsoft users are an interesting lot. They have systems that they have NO control over. They have systems they have to reboot every sixteen minutes. They freely pay Bill Gates obscene amounts of money for buggy programs that they can't use when they upgrade to the next operating system. It's almost laughable. But they are united, and most don't know the first thing about Linux.

Clearly, you just don't get it. Your attitude toward users shows it. The big failures of HCI have little to do with user training. The big failures are inconsistencies within user interfaces. Take Mac OS's trash can for example. Normally one drags something into the trash can to delete it. And most of the time Apple's interface does exactly that, as the user expects. Then Apple made the usability mistake of having the trash can also be the way to eject a floppy disk. Typical users are confused and concerned with that behaviour (fearing that their floppy disk might be erased) because it absolutely violates the metaphor of a trash can. It's not because they're stupid or lazy. It's because they're actually smart enough to know what a trash can is for (and Apple Computer wasn't). Visit the Interface Hall of Shame and pick up a clue.

When it comes to open source software, developers are users. Open source software is a good example of user-centered design because the connection between users and developers is so tight. They may not be the users that usability experts usually think about, but that's a problem with usability experts, not users.

In part, open source software is a reaction to the fact that commercial designs like Windows and Macintosh have completely ignored the usability concerns of expert users. Expert users need tools that are different from casual users.

If you look around other areas, many tools for experts would not pass muster with usability experts: knives are dangerous and hard to use, motorcycles are complicated and tricky to control, violins permit users to make enormous numbers of mistakes that only a little bit of technology could prevent, cameras like the Hasselblad or Leica allow enormous amounts of user error. Thank goodness "usability experts" haven't been allowed to mess with those designs, because they are excellent designs.

Usability experts do not get involved in OSS projects

Usability experts can start whatever projects they want to. But they shouldn't be surprised if many projects simply have no interest in their advice--that isn't because people don't understand what usability engineers do, it's because they do.

And you can see many of the pathetic attempts by usability experts at making computers more intuitive at the interface hall of shame (most of the IBM stuff on that site came from what is generally considered a reputable user interface research group at IBM). From supporting family and friends, I can also tell you that neither Windows nor Apple usability have succeeded in making user interfaces that are intuitive even to their intended target audiences. Perhaps before complaining about the usability of open source software (which is much easier to support remotely), usability experts should first figure out how to do things right even for companies willing to actually invest millions of dollars.

However, projects like KDE and Gnome, whose aim is to produce an improved Windows or Mac-like desktop may well welcome the involvement of usability engineers. Any usability engineer who wants to volunteer is free to. Personally, I think that for non-programmers, paying a company like Microsoft or Apple to buy an OS is a better choice--if the market were only a bit more competitive.

You are comparing apples and oranges. It makes no sense to compare Microsoft Windows and "Linux". Linux is just a kernel. You have to compare Microsoft Windows to a specific distribution with a specific desktop. "Mandrake Linux running KDE" is as consistent as Microsoft Windows (and easier to use and more robust, IMO).

Is Windows inconsistent because there are plenty of Delphi and Windows 3.1 applications? Is Windows inconsistent because MS Office breaks many of the UI guidelines for Windows and uses a lot of widgets that are not available to regular developers? Is Macintosh OS X "inconsistent" because MS Office violates many OS X GUI guidelines? Because it runs X11 applications? Because it runs OS9 applications? Because there are Darwin-based distributions that only have X11? Does running Opera on Macintosh or Windows make those platforms inconsistent? Does the flood of poorly written, inconsistent, and ugly shareware and commercial software on Windows and Macintosh make those platforms inconsistent or bad?

Consistency isn't a technical attribute, it's about packaging and your personal choice of software. If you value consistency, pick a Linux distribution that offers it and don't use inconsistent applications. That's all the consistency you'll ever get, on Linux or any other platform.

I had the day off today so I installed Redhat 8.0 (SURPRISE!) and tried to get Mozilla 1.2 up and running with anti-aliased fonts. I wasted the whole day and I am glad to be back on Win2K (call me stupid or whatever... half the font stuff made me feel like a criminal - why isn't it *on* by default? I'll pay big bucks for that...). Linux is shooting itself in the foot with that respect. Everybody hears so much about Linux so they install it only to be disappointed to such an extreme that they'd never want to bother again (I know that I do not).

Mozilla has its own quirky GUI. Mozilla is inconsistent with the rest of the GUI on every platform, including Windows and Macintosh, why shouldn't it be inconsistent on Linux? If you run Konqueror, the KDE browser, under KDE you get font anti-aliasing plus a completely consistent GUI.

It's a historical quirk that Mozilla anti-aliasing is more difficult to configure for Mozilla on RedHat 8.0 than it is on Windows. On other distributions, it just works.

If you like Windows, stick with it, but don't whine about other platforms. You, after all, have a choice. The only people who have reason to complain are those who are forced to use platforms they don't like.

As far as user interfaces go, Big Company/Commercial applications do not mean good user interface. Take a look at the User Interface Hall of Shame. The vast majority of applications listed there are commercial products.

When Microsoft and Unix copied the Macintosh GUI, they copied the superficial APPEARANCE of the GUI and missed some of the more important aspect of the interface like:

• "Documents" need to have a TYPE that is independent of the user assigned name for the document.
  
• "Files" need to have a position in the 2D space of the desktop. We all organize our work across the 2D space of our real desk. And most of us go ballistic whenever anyone rearranges all the stuff on our real desk. So why is it OK to have our stuff on our virtual desk rearrange its position whenever new pieces are added or removed?
  
• All the parts of an "Application" (which the user views as a tool) need to come in one "bundle" to make it easy for the user to organize their tools however they wish and still have them work.
  
• "Things" in the real world have an appearance, actions don't. Translated: Icons are for things, not actions. A toolbar full of icons for actions is confusing. Icons should be reserved for "things".
  
• And many more...
  

• File "Open" and "Save" dialogs shouldn't exist. They were created to get around the problem on the original Macintosh that the user couldn't use the Finder AND another application at the same time.
  
• File "Quit" shouldn't exist. It was invented because the original Macintosh could only run one program at once and it took awhile to start/restart any program.
  
• The need to periodically save a document shouldn't exist. The system should ensure that it keeps everything "saved".
  
• Copying a document from one volume to another should ensure that that document can be opened/viewed/printed on another computer on which that volume my be opened (this means transparently copying fonts and a "viewer" for each document type invisibly in the background).
  

• All documents I have can be opened/viewed/printed without ever having to worry weather I have a copy of the "tool" that allowed someone to create that document. If I have a copy of the tool that allows editing that document type then I should be able to edit it as well.
  
• I can organize my documents on a 2D desktop with "folders" just like I organize real documents on a 2D desktop with folders on my real desk top.
  
• I never have to worry about "saving" periodically.
  
• The system automatically uses spare storage to keep past versions of documents that I edit. The system automatically deletes the oldest versions of documents when I need the space. This occurs transparently. This means I reliably have multiple-level Undo/Redo when editing any document and can "Revert" back several versions if I wish. The first version of the Macintosh file system and OS had the concept of document "versions" built in but I've never seen them used and they've since dropped into oblivion.
  
• I never have to be concerned with "Quitting" an application. Whether or not the system needs an application in RAM or not is a detail the operating system should deal with in concert with the application. The user should not have to deal with it.
  
• The "Display" allows direct manipulation of the interface via a stylus.
  
• The system is small and flat like a book and light enough so I can carry it around and use it wherever I want.
  
• The system interface supports handwriting recognition and voice recognition as first class input methods. Because this is the way people in the real world communicate.
  
• And a bunch more but it's too late for me to remember them.
  

Pretty soon we'll need a quick launch bar for the quick launch bars.

Most of the time, I think Microsoft has made "innovation" a four-letter word. That's just when I'm pissed. When I take a step back (especially when I see stuff like this), I get the impression that Microsoft's idea of innovation is visual masturbation. Sometimes I think they measure success by number of entries in the Interface Hall Of Shame.

Two points:

1. I don't see how eye candy is ever innovative without improvements in the underlying architecture such as security or ease of use. My definition of ease of use is slightly different than most however. I would define ease of use the ability to quickly and easily get what you want done, regardless of skill level. One of the things that really irks me about Windows in general (and to a certain extent OS X) is that it is targeted so much at the ignorant user, that it is nothing but frustrating to me as someone who knows a little more.

2. What's worse is that the free software world seems to emulate this behavior more and more. There is a lot of imitation in OpenSource. This is good. It is extremely important to have free tools which support POSIX standards (like awk and find). What's great is there's a lot of innovation too (emacs, gcc, the Linux kernel module architecture). There just doesn't seem to be much innovation in free software UI design. The default behavior seems to be to "make it like Windows". Microsoft UIs attempt to hide so much from their users they become unusable. KDE attempts to mimic this behavior. RedHat took this direction with 8.0 for its entire UI, and as a result I'm frustrated to the point of looking for a new distro.

(and my 2d performance is more than a bit better)

As always, what you should use depends on your needs. If X works perfectly for you, then great. As a "frame-buffer oriented network-transparent graphics API" it'd be hard to beat. As the foundation for kits like Gtk and Qt (and even PicoGui sometimes) it works well.

However, as a platform (a standard for application creation) X is sub-optimal for users and developers.

The value of a standard comes not only from what it allows you to do, but what it forbids.

Suppose I write 3 programs to perform the same tasks under different GUIs: Microsoft's, Apple's OS X Quartz/Aqua, and X11R6. A Mac user can sit down without looking at the instructions and use his familiar old mouse motions, menu commands, and keystrokes with hardly a glance at the new stuff. A Windows(tm) user has nearly the same advantages. The icons for the same feature (Save, Print) look exactly the same, regardless of the program.
Of course that's not the case for X programs. Whenever I sit down at a new X11 program, I have to spend a few minutes recalibrating the basics ("How to I copy/paste, again?")

Because X allows the developer so much freedom, it deprives the user of the ability to anticipate how a program will operate. "The program can do nearly anything" sounds like an advantage, until you try to predict what a program will actually do!

Note that a weakness of Apple and Microsoft's GUI systems is that the "forbidding" part of their standard often comes in the form of "law" instead of "code". The taboos are enforced by developers getting chastised by the GUI vendor or the public when a non-ituitive program is released.

A weak method- the lag time for feedback is long, and if the offending developer works for the GUI vendor, he might insert loopholes into the rules.). But it produces superior results to X programs, where the users lack an imposing rulebook to point to as formal justification for their complaints. Improvements may happen, but there's nothing forcing them to converge on one way of doing things.

Some common responses to this argument:
"You want a toolkit, not X"
Maybe so. If a user's desktop could only run one toolkit, she'd never see an unfamiliar interface. This has the problem of discarding pre-existing programs, but argument-by-popularity is a logical fallacy (I'm talking about what solution would be best, not cheapest short-term). Better than using a single toolkit, though, is somehow allowing the application to be written independent of toolkit, and obeying whatever HCI conventions a particular user enjoys. PicoGui tries to do this.

"No one can be sure what the best interface is. Keeping flexibility gives us power."
In theory it does, but at the expense of accessibility. Too often it means that developers who don't want to be "HCI Researchers" find themselves wrestling with UI code that's entangled their applications.
PicoGui (and other "next-generation" UI systems) attempt to resolve this by keeping the application programmer further from the UI code than is traditional. (They haven't been totally successful yet)
He can't mess with the per-pixel alignment of buttons, because that's outside of the application's control.
This is fundamentally better than the way Apple and Microsoft's traditional Human Interface manuals have worked, because enforcement of the rules is done not by humans (punishing programs that act wrongly) but by software (doing the work for you, so it's guaranteed to do it right).

• "Don't whine about what you're getting for free"
  
• "Free Software does not entitle you to a usable interface"
  
• "I can't believe some people get paid to criticize the work of others"
  
• "Usability is in the eye of the beholder. Don't listen to any of these 'Usability Experts'"
  
• "If you want to improve the interface, learn how to code and submit a patch."
  

Intuitive to some, perhaps. Personally, I found the Truespace interface to be extremely fiddly, mainly due to the proliferation of buttons and dialogs all over the place.

Seems that I'm not alone, as it has its own section (admittedly they look at v2, but most of the niggles are still there in v5/6 AFAICT) on the Interface Hall of Shame. Nuff said, really.

I eventually gave up on Truespace, after having had a chance to try out Cinema 4D. I find the interface in Cinema 4D to be much more conducive to my way of thinking and working. YMMV, of course. Not meaning to diss your choice, mind you. Suffice to say, at least I could use Truespace - something that I singularly failed to do with either Amapi 3D or Blender.

Intuitive to some, perhaps. Personally, I found the Truespace interface to be extremely fiddly, mainly due to the proliferation of buttons and dialogs all over the place.

Seems that I'm not alone, as it has its own section (admittedly they look at v2, but most of the niggles are still there in v5/6 AFAICT) on the Interface Hall of Shame. Nuff said, really.

I eventually gave up on Truespace, after having had a chance to try out Cinema 4D. I find the interface in Cinema 4D to be much more conducive to my way of thinking and working. YMMV, of course. Not meaning to diss your choice, mind you. Suffice to say, at least I could use Truespace - something that I singularly failed to do with either Amapi 3D or Blender.

I liked this page here

Some foolish Autodesk coder forgot to remove the tooltip comment:
"Click this to display an overview of the dialog box, idiot"
Forgetting this was probably a good way to get fired (as is mentioned) without a recommendation.

I've heard of a similar mistake, wherein a programmer for bank software was writing routines to do discounts, etc for customers who kept very large balances. To check the functionality of the routine, a message with some comment to the extent of "fat-cats with big walls" was printed as debug on transaction slips from the bank machine. However, the programmer forgot to remove this before the first production releases.

I'm assuming that he is also now an ex-coder (at least as far as the banks as concerned). As a warning, if you are going to put amusing and possibly insulting debug code in, make sure you write yourself lots of memos to remove it before production (or better yet, just use something not insulting).

Similarly, I remember at some point I was making a massmail system. On test messages, the header was "all is well and fine." Of course, in production one of the first messages was about a major security issue that resulted in formmail (yick) being removed from accounts, and since I forgot to remove the $subject="All is well and fine", the intended subject line was overwritten. I didn't get fired, but it did leave me red in the face. Luckily my boss and customers are understanding and have a sense of humour.

In Vernor Vinges sci-fi novel A fire upon the deep, he presents the idea of software archeology. Vinges future has software engineers spending large amounts of time digging through layers of decades-old code in a computer system like layers of dirt and rubbish in real-world archeology to find out how, or why, something works.

So far, in 2002, this problem isnt so bad. We call such electronic garbage cruft, and promise to get rid of it someday. But its not really important right now, we tell ourselves, because computers keep getting faster, and we havent quite got to the point where single programs are too large for highly coordinated teams to understand.

But what if cruft makes its way into the human-computer interface? Then you have problems, because human brains arent getting noticably faster. (At least, not in the time period were concerned with here.) So the more cruft there is in an interface, the more difficult it will be to use.

Unfortunately, over the past 20 years, Ive noticed that cruft has been appearing in computer interfaces. And few people are trying to fix it. I see two main reasons for this.

1. Microsoft and Apple dont want to make their users go through any retraining, at all, for fear of losing market share. So rather than make their interfaces less crufty, they concentrate on making everything look pretty.

2. Free Software developers have the ability to start from a relatively cruft-free base, but (as a gratuitously broad generalization) they have no imagination whatsoever. So rather than making their interfaces more usable, they concentrate on copying whatever Microsoft and Apple are doing, cruft and all.

Here are a few examples of interface cruft.

1. In the 1970s and early 80s, transferring documents from a computers memory to permanent storage (such as a floppy disk) was slow. It took many seconds, and you had to wait for the transfer to finish before you could continue your work. So, to avoid disrupting typists, software designers made this transfer a manual task. Every few minutes, you would save your work to permanent storage by entering a particular command.

   Trouble is, since the earliest days of personal computers, people have been forgetting to do this, because its not natural. They dont have to save when using a pencil, or a pen, or a paintbrush, or a typewriter, so they forget to save when theyre using a computer. So, when something bad happens, theyve often gone too long without saving, and they lose their work.

   Fortunately, technology has improved since the 1970s. We have the power, in todays computers, to pick a sensible name for a document, and to save it to a persons desktop as soon as she begins typing, just like a piece of paper in real life. We also have the ability to save changes to that document every couple of minutes (or, perhaps, every paragraph) without any user intervention.

   We have the technology. So why do we still make people save each of their documents, at least once, manually? Cruft.

2. The original Macintosh, which introduced graphical interfaces to the general public, could only run one program at a time. If you wanted to use a second program, or even return to the file manager, the first program needed to be unloaded first. To make things worse, launching programs was slow, often taking tens of seconds.

   This presented a problem. What if you had one document open in a program, and you closed that document before opening another one? If the program unloaded itself as soon as the first document was closed, the program would need to be loaded again to open the second document, and that would take too long. But if the program didnt unload itself, you couldnt launch any other program.

   So, the Macs designers made unloading a program a manual operation. If you wanted to load a second program, or go back to the file manager, you first chose a menu item called Quit to unload the first program. And if you closed all the windows in a program, it didnt unload by itself it stayed running, usually displaying nothing more than a menu bar, just in case you wanted to open another document in the same program.

   Trouble is, the Quit command has always been annoying and confusing people, because its exposing an implementation detail the lack of multitasking in the operating system. It annoys people, because occasionally they choose Quit by accident, losing their careful arrangement of windows, documents, toolboxes, and the like with an instantaneity which is totally disproportionate to how difficult it was to open and arrange them all in the first place. And it confuses people, because a program can be running without any windows being open, so while all open windows may belong to the file manager, which is now always running in the background menus and keyboard shortcuts get sent to the invisible program instead, producing unexpected behavior.

   Fortunately, technology has improved since 1984. We have the power, in todays computers, to run more than one program at once, and to load programs in less than five seconds.

   We have the technology. So why do we still punish people by including Quit or Exit menu items in programs? Cruft.

3. As I said, the original Macintosh could only run one program at a time. If you wanted to use a second program, or even return to the file manager, the first program needed to be unloaded first.

   This presented a problem when opening or saving files. The obvious way to open a document is to launch it (or drag it) from the file manager. And the obvious way to save a document in a particular folder is to drag it to that folder in the file manager. But on the Mac, if another program was already running, you couldnt get to the file manager. What to do? What to do?

   So, the Macs designers invented something called a file selection dialog, or filepicker a lobotomized file manager, for opening and saving documents when the main file manager wasnt running. If you wanted to open a document, you chose an Open menu item, and navigated your way through the filepicker to the document you wanted. Similarly, if you wanted to save a document, you chose a Save menu item, entered a name for the document, and navigated your way through the filepicker to the folder you wanted.

   Trouble is, this interface has always been awkward to use, because its not consistent with the file manager. If youre in the file manager and you want to make a new folder, you do it one way; if youre in a filepicker and you want to make a new folder, you do it another way. In the file manager, opening two folders in separate windows is easy; in a filepicker, it cant be done.

   Fortunately, technology has improved since 1984. We have the power, in todays computers, to run more than one program at once, and to run the file manager all the time. We can open documents from the file manager without quitting all other programs first, and we can save copies of documents (if necessary) by dragging them into folders in the file manager.

   We have the technology. So why do we still make people use filepickers at all? Cruft.

4. This last example is particularly nasty, because it shows how interface cruft can be piled up, layer upon layer.

   1. In Microsofts MS-DOS operating system, the canonical way of identifying a file was by its pathname: the concatenation of the drive name, the hierarchy of directories, and the filename, something like C:\WINDOWS\SYSTEM\CTL3DV2.DLL. If a program wanted to keep track of a file in a menu of recently-opened documents, for example it used the files pathname. For backward compatibility with MS-DOS, all Microsofts later operating systems, right up to Windows XP, do the same thing.

      Trouble is, this system causes a plethora of usability problems in Windows, because filenames are used by humans.

   2. What if a human renames a document in the file manager, and later on tries to open it from that menu of recently-opened documents? He gets an error message complaining that the file could not be found.

   3. What if he makes a shortcut to a file, moves the original file, and then tries to open the shortcut? He gets an error message, as Windows scurries to find a file which looks vaguely similar to the one the shortcut was supposed to be pointing at.

   4. What happens if he opens a file in a word processor, then renames it to a more sensible name in the file manager, and then saves it (automatically or otherwise) in the word processor? He gets another copy of the file with the old name, which he didnt want.

   5. What happens if a program installs itself in the wrong place, and our fearless human moves it to the right place? If hes lucky, the program will still work but hell get a steady trickle of error messages, the next time he launches each of the shortcuts to that program, and the next time he opens any document associated with the program.

   6. Fortunately, technology has improved since 1981. We have the power, in todays computers, to use filesystems which store a unique identifier for every file, separate from the pathname such as the file ID in the HFS and HFS+ filesystems, or the inode in most filesystems used with Linux and Unix. In these filesystems, shortcuts and other references to particular files can keep track of these unchanging identifiers, rather than the pathname, so none of those errors will ever happen.

      We have the technology. So why does Windows still suffer from all these problems? Cruft.

      Lest it seem like Im picking on Microsoft, Windows is not the worst offender here. GNU/Linux applications are arguably worse, because they could be avoiding all these problems (by using inodes), but their programmers so far have been too lazy. At least Windows programmers have an excuse.

   7. To see how the next bit of cruft follows from the previous one, we need to look at the mechanics of dragging and dropping. On the Macintosh, when you drag a file from one folder to another, what happens is fairly predictable.

   8. If the source and the destination are on different storage devices, the item will be copied.
   9. If the source and destination are on the same storage device, the item will be moved.
   10. If you want the item to be copied rather than moved in the latter case, you hold down the Option key.

   11. Windows has a similar scheme, for most kinds of files. But as Ive just explained, if you move a program in Windows, every shortcut to that program (and perhaps the program itself) will stop working. So as a workaround for that problem, when you drag a program from one place to another in Windows, Windows makes a shortcut to it instead of moving it and lands in the Interface Hall of Shame as a result.

       Naturally, this inconsistency makes people rather confused about exactly what will happen when they drag an item from one place to another. So, rather than fixing the root problem which led to the workaround, Microsoft invented a workaround to the workaround. If you drag an item with the right mouse button, when you drop it youll get a menu of possible actions: move, copy, make a shortcut, or cancel. That way, by spending a couple of extra seconds choosing a menu item, you can be sure of what is going to happen. Unfortunately this earns Microsoft another citation in the Interface Hall of Shame for inventing the right-click-drag, perhaps the least intuitive operation ever conceived in interface design. Say it with me: Cruft.

   12. It gets worse. Dragging a file with the right mouse button does that fancy what-do-you-want-to-do-now-menu thing. But normally, when you click the right mouse button on something, you want a shortcut menu a menu of common actions to perform on that item. But if pressing the right mouse button might mean the user is dragging a file, it might not mean you want a shortcut menu. What to do, what to do?

       So, Windows designers made a slight tweak to the way shortcut menus work. Instead of making them open when the right mouse button goes down, they made them open when the right mouse button comes up. That way, they can tell the difference between a right-click-drag (where the mouse moves) and a right-click-I-want-a-shortcut-menu (where it doesnt).

       Trouble is, that makes the behavior of shortcut menus so much worse that they end up being pretty useless as an alternative to the main menus.

   13. They take nearly twice as long to use, since you need to release the mouse button before you can see the menu, and click and release a second time to select an item.

   14. Theyre inconsistent with every other kind of menu in Windows, which opens as soon as you push down on the mouse button.

   15. Once youve pushed the right mouse button down on something which has a menu, there is no way you can get rid of the menu without releasing, clicking the other mouse button, and releasing again. This breaks the basic GUI rule that you can cancel out of something youve pushed down on by dragging away from it, and it slows you down still further.

   16. In short, Windows native shortcut menus are so horrible to use that application developers would be best advised to implement their own shortcut menus which can be used with a single click, and avoid the native shortcut menus completely. Once more, with feeling: Cruft.

   17. Meanwhile, we still have the problem that programs on Windows cant be moved around after installation, otherwise things are likely to break. Trouble is, this makes it rather difficult for people to find the programs they want. In theory you can find programs by drilling down into the Program Files folder, but theyre arranged rather uselessly (by vendor, rather than by subject) and if you try to rearrange them for quick access, stuff will break.

       So, Windows designers invented something called the Start menu, which contained a Programs submenu for providing access to programs. Instead of containing a few frequently-used programs (like Mac OSs Apple menu did, before OS X), this Programs submenu has the weighty responsibility of providing access to all the useful programs present on the computer.

       Naturally, the only practical way of doing this is by using multiple levels of submenus thereby breaking Microsofts own guidelines about how deep submenus should be.

       And naturally, rearranging items in this menu is a little bit less obvious than moving around the programs themselves. So, in Windows 98 and later, Microsoft lets you drag and drop items in the menu itself thereby again breaking the general guideline about being able to cancel a click action by dragging away from it.

       This Programs menu is the ultimate in cruft. It is an entire system for categorizing programs, on top of a Windows filesystem hierarchy which theoretically exists for exactly the same purpose. Gnome and KDE, on top of a Unix filesystem hierarchy which is even more obtuse than that of Windows, naturally copy this cruft with with great enthusiasm.

Following those examples, its necessary to make two disclaimers.

Firstly, if youve used computers for more than six months, and become dulled to the pain, you may well be objecting to one or another of the examples. Hey!, youre saying. Thats not cruft, its useful! And, no doubt, for you that is true. In human-computer interfaces, as in real life, horrible things often have minor benefits to some people. These people manage to avoid, work around, or blame on user stupidity, the large inconvenience which the cruft imposes on the majority of people.

Secondly, there are some software designers who have waged war against cruft. Word Places Yeah Write word processor abolished the need for saving documents. Microsofts Internet Explorer for Windows, while having many interface flaws, sensibly abolished the Exit menu item. The Acorns RISC OS abolished filepickers. The Mac OS uses file IDs to refer to files, avoiding all the problems I described with moving or renaming. And the ROX Desktop eschews the idea of a Start menu, in favor of using the filesystem itself to categorize programs.

However, for the most part, this effort has been piecemeal and on the fringe. So far, there has not been a mainstream computing platform which has seriously attacked the cruft that graphical interfaces have been dragging around since the early 1980s.

So far.

Discuss

The first is to select the file in the Finder, and drag it to a new location while holding down the Option and Command keys (or select Make Alias from the File menu). This creates a Mac OS alias that Cocoa, Carbon, and Classic applications can follow. However, Unix applications will ignore those links, seeing them as zero-byte files.

You can also create a link with ln or ln -s. If you use this kind of link, Unix, Cocoa, Carbon, and Classic applications will happily follow it.

I have no knowledge of the reasons for this design decision, but why isn't it just "All links are symlinks, no matter where they came from"?

Having links that the gui creates be incompatible with the command line, but having links the command line makes be compatible with the gui, just creates complication.

Apple's been on this site before... The Interface Hall of Shame

Also of interestError message hall of shame

There's this little gem from Real Media.

For those of you who care about interface, and every project should have at least one person working on it who does, the Isys Interface Hall of Shame is a great resource, and entertaining as well.

Or perhaps I should say "was", as it doesn't appear to have been updated in over 2 years.

Let's inform him on some of the "innovating" that Microsoft has done in the past ... shall we?

I'm not someone to stand up for Microsoft, but this comparison _really_ is too easy.

What Unix users tend to forget is that Microsoft actually did some things right in Windows that Unix (or rather, the X Windows toolkits) to this date doesn't do right consistently. Take cut&paste. It's a basic feature, but the sheer scope of deviation among toolkits is just revolting. Tabbing between fields, same story.

As a matter of fact, the thing that I hold against Microsoft is precisely _not_ borrowing successful concepts from other companies. My favorite: Apple for years had a highly successful magazine for Apple Developers, called (wait for it!)... "develop". If a developer asked "develop" a question illustrated by an example, it would be answered with regards to the technology, but equally important, UI goofs would be pointed out.

If you look at MSDN, you will invariably see UI questions answered with "sure, you can do that, here's the code". No matter how counterintuitive or outright stupid the proposed UI is.

Microsoft sucks at trying to sway developers to pay attention to the looks of the UI (and, matter of fact, the WIN32 API doesn't make it particularly easy to do screen layout right), but much of the groundwork for UI behavior is done right, and screwing it up takes a conscious effort. A shocking innovation? I don't think so. Done better than the average Unix tool? You betcha.

Of course, Apple has much to answer for after they set the Dung Standard for user interfaces with their glitzy but totally unusable quicktime player.

there is an interesting look at how not to design an interface at http://www.iarchitect.com/index.htm

The Interface Hall of Shame looks at the worst cases. Good for a few laughs, at least. :)

>........He wasn't saying autoCADs interface was good .. just that it was complex.
But Autocad has a very good interface. The interface is flexible (you can edit every menu in the program - even the one that pops up when you hit the 4th button on the digitizer puck - and you can create alias shortcuts for your favorite commands), it's simple (If you know the name of your command you can just type it in, rather than hunt for it in the menus)....etc. etc. etc.
And it's fairly intuitive. For 2d drafting, it's almost exactly like sitting down to a drafting board (granted, it's alot faster, but it feels the same way). I'll admit the learning curve for 3d modelling with autocad is kinda steep, and the curve for solid modelling is nearly verticle - but those are fucked up concepts in the first place.
I've been an Autocad professional since release 10, way back in the day. I've drawn the plans for parts that go on commercial airplanes that fly over your house every day...and Autocad has been there with me every day.
Even while learning the software in the first place, I could relate it to the training I'd had with pencil-paper-TSquare drafting and it made a decent amount of sense. I've never had the interface for any release of autocad (up until release 13...and the fact that it was a windows app kinda felt funny) get in the way of my productivity.
But - back on topic: The software packages he mentioned are NOT for general use. The apps he mentioned aren't MSWord, Mozilla or IE - we're talking about stuff a person would go to school to learn how to drive.... software packages a person could make a career out of.



And keep in mind:
COMPLEX != BAD
SIMPLE !=GOOD
when it comes to UIs... The UI has to match the complexity level of the software, or you'll have intelligent trained professionals being insulted by "drool proof" software. Or, you'll have a newbie lost among a maze of menus and tech terms he/she can't understand.
My Opinion - my little $0.02 to add: Menus with pictures instead of words FUCKING SUCK! Toolbars... You know - with the little icon of a floppy, and if you poke at the floppy with a mouse it saves what you are working on... But what if you don't want to save it to the floppy? WAUGH! Why not just put a drop down menu with the word "SAVE" in a box?
Go here - read:
User Interface Hall of Shame

Look at what you shouldn't do, it is funnier.

http://www.iarchitect.com/mshame.htm

Quicktime's Entry into the Interface Hall of Shame is all I have to say to that one.

And God help you if you actually need to use the installer you built with InstallShield. I've seen everything from "Admin permission not given" errors on Win98 boxes with no admins, to failure to uninstall, to outrageously slow performance. Just getting the InstallShield development environment installed and working on my PC took four installs. How crappy is your installer if it can't even install itself?!?

Oh, we don't disagree that this is what they have done. What you're apparently not grasping, however, is that this is precisely what they've been telling developers NOT to do all along. And, IMOP, they've been right all along. But they can't have it both ways. They criticise, for instance, winamp, and rightly so - but then they build the same mistakes they point out in winamp into QT.

This is what their designers call a 'consumer interface' and the major problems are two. The thinking behind such interfaces, of course, is that since they are copied from common interfaces outside the computer world, the average person will recognise them and apply their knowledge seamlessly. But this doesn't always happen - the consumer may just as likely NOT recognise the similarities with the meatspace equivelants, since they are symbolic, not actual, and will obviously not be able to transfer the UI knowledge built from the otherwise consistent Mac interface to them, since they don't share that interface either. Furthermore, the interface that copies from meatspace inevitably is limited artificially, since it copies from an interface built in part in response to limitations that don't apply to the computer.

Of course, QT 4 was the epitome of these mistakes, and the current version has retracted many of them - it does now have a menu bar, and the stupid thumbwheel has been replaced with a slider bar, for instance. Several of the most glaring and unforgiveable errors in the QT 4 design have been quietly retracted, and that's for the good, but if you read this critique of the QT 4 interface with QT6 up to compare with, obviously some of the criticisms are still very valid.

It's a good thing, of course, that the worst of the problems have been fixed, I was just pointing out, and I think it needs to be said, that Apple is still being quite hypocritical in this case - they are still not practicing what they preach. Every designer thinks they know a better way, and Apple needs to maximise their credibility when they tell them to repress their urges in that regard and make their interfaces standard and consistent - when Apples own interfaces are less than perfect in that regard it just sends a signal to the designers that it's fine to be less than perfect themselves. Which, I would think, is the last signal Apple should really be sending them.

if your new custom [widget] is well designed for its specific use, rather than merely cobbled together from generic components then any initial time-wasting will be saved

I disagree. I generally find that custom widgets charm developers, and annoy users.

Lets take a look at existing custom widgets. The big annoying ones are bitmap ones (on Windows, often using the standard button as an underly widget). These look different, add nothing to the application, amake the program bigger (esp. to download), slower, look less professional, and seem to frequently be written by interns or something, judging by the quality of them.

There are custom tab widgets. They usually aren't any better than normal tab widgets, especially the annoying reshuffling multi-row tab widgets.

There are animated widgets. Animated widgets are just plain annoying to a lot of people.

There are dials. Every custom widget library seems like it has to come with a dial widget. Dial widgets are about the most difficult interface to work with on a computer, given your input devices (keyboard, mouse).

A lot of examples of what custom widgets do and how bad they are can be found at the excellent Interface Hall of Shame.

There are a *very* few custom widgets that I've seen over the past few years that I think are honestly good and deserve being adopted. I haven't seen a single Windows widget that I like, and in all my years of poking around at human-computer-interaction, I've seen exactly three widgets on the Mac that were a good idea (all of which were pretty much uniformly adopted by the Mac developer community).

A) The slider. The MacOS never had a slider control. When MS copied the Mac's interface elements, this is one of the things they did right -- added a slider. Traditionally, MacOS developers have used scroll bars to fill in the gap, but a fair number of people have introduced a Windows-style slider.

B) The Mercutio MDEF -- this is a menu widget that supports more complex keybindings. The original Mac menu widget only supported Command-A, not Command-A separate from Command-Shift-A. This has been a fairly useful invention (and the UI was done right -- there was a shift symbol added, not just a capital "A" shown in the menu).

C) Windoids. These are the little palettes that vanish when you switch to other apps. They don't look like standard windows, they disappear on their own, but they're so useful that everyone uses them now.

There are also a few, high-level and very custom widgets that don't really appear to the user as widgets, and make reasonable sense. A calendar widget, or something along the lines of GnomeCanvas.

Really nice idea I never thought of. Too bad I won't be writeing any OS X apps anytime soon. Are there more documents like this on UI design that arent' just about OS X, but more general?

Try the Interface hall of fame and hall of shame at Isys Information Architects

You might be interested at a look at the User Interface Hall Of Shame then - it's full of examples of developers perverting normal controls to use them for other things, or coming up with their own widgets to replace `normal` controls.

Even Apple aren't immune. (Though to be fair that was quicktime 4 which is quite old).

You might be interested at a look at the User Interface Hall Of Shame then - it's full of examples of developers perverting normal controls to use them for other things, or coming up with their own widgets to replace `normal` controls.

Even Apple aren't immune. (Though to be fair that was quicktime 4 which is quite old).

If Lotus spent so much time thinking about Notes' design, why did they get it so horribly, horribly wrong?

Have these guys never heard of The Interface Hall of Shame? You should NEVER EVER utilize color in an interface where color correction is required. The UI hinders the user's ability to faithfully adjust colors.

I also wouldn't go as far as saying this application will give Premiere a run for its money because Premiere benefits GREATLY from its relationship with other Adobe applications. I can edit my work in Premiere then import the entire project, tracks, effects and all, into After Effects for post production work and final rendering. Not to mention the ability to import native Photoshop and Illustrator files without any special work arounds.

I also didn't see anything in the feature list which suggested this application is capable of editing web enabled video (QT, Real and/or WMV)

If the user is typing something really important in an IE text field, and then all of a sudden the text field loses focus and they hit the backspace button (thinking they're doing a backspace in a text field) guess what happens? They go back to a previous page and in many cases the text field they have been typing in get's completely blanked out when this happens. We UI designers would typically call this an "unexpected action". The user expected hitting backspace by itself would do a backspace in the text, and instead it brought them to a previous page. And wiped out all the valuable work they had done in the process.

Other examples of microsoft incompetance include window-in-window MDI, multi-row tabs, and their latest shennanigan, the adaptive menus that constantly change position on a user (which screws up the users motor muscle memory for where the menu selections are). All these "features" have been harshly criticized by many in the HCI community.

For further reading, check out the Interface Hall of Shame, of which Microsoft is the most frequent inductee.
To see Microsoft usability get slammed by one of the most prominent members of the UI design community, check out AskTog.com

Microsoft is so successful in the UI biz despite their poor usability for precisely the same reason they are so successful in the server biz despite their poor security: they've got a monopoly, a proprietary file format, and the ears, hearts and minds of every pointy-haired boss and every clueless IT manager in America.

It is soo stupid. You might think that they would at least correct some of their really obvious botches [Iarchitect.com] from the earlier version(s).

But not Apple.

I remember a web-site that covered the worst software UI's. I cant remember (or find) the site. It covered Quicktime, some IBM software and others.

The Interface Hall of Shame, most likely.

Also, there is a great place for the bad UI design at The Interface Hall Of Shame.

And Gecko violates Windows user interface conventions,

Check out the many entries in the Interface Hall of Shame that include Microsoft.

If it makes it easier to use, I'm all for it.

Before I install anything Quicktime related again, Apple is going to have to win me back with a much better interface and functionality. I used to enjoy Quicktime, back when you could fullscreen videos without registering, back when the controls were usable and ergonomic, back when there wasn't a constant nag screen, back when there wasn't some overpaid designer's faux brushed metal skin cluttering up the window.

To anyone who's installed the new beta: Have these issues been fixed at all? Since OSX, Apple has been getting things right again, and I'd love to see them make Quicktime function like it did in the past. As it is now, I even choose (gack!) RealMedia before Quicktime.

I wonder what the Interface Hall of Shame would make of this one.
It's a real world model designed to function as a poorly designed virtual model, or so it seems. There doesn't seem to be any real advantage to hitting three or four buttons to do something when I can just hit {VCR}{1}{2}{ENTER} to do the same thing on any other universal. If you REALLY want this functionality, perhap you should use your Palm Pilot instead?

X11 is the equivalent of GDI or Quartz; it doesn't have to enforce GUI semantics. If you want to enforce a "coherent" desktop on top of it, you can impose whatever draconian measures you like. KDE looks quite coherent and standardized to me, for example.

It's a myth, in any case, that Windows or MacOS are any more coherent than, say, KDE. Take a look here for an extensive critique. And you think that the appearance or window management behavior can't be changed on Windows? Think again: Stardock, Litestep, Microsoft PowerToys.

but isn't the fact that video drivers are implemented in userland an architectural problem to begin with?

The video drivers are in the kernel. The drawing and acceleration is in the display server. The toolkit is in the application. It's fast and it's robust. It's what NeXTStep and MacOSX do as well. Where is the "architectural" problem?

Plus, the resources mechanism is absolutely byzantine and needs to be be razed,

Neither Gnome nor KDE use the X11 resource mechanism. They use something much more like Windows. That's actually a shame because the X11 resource mechanism is better.

as well the complex distinctions between server and client (wait, who's the server, who's the client, who has the toolkit?, who's running the window manager? what the fsck is going on?).

Windows, MacOS, and NeXTStep make the same distinction as X11: they have a low-level graphics and windowing component that runs in a display server, and they have a high level toolkit part that runs in a display client.

Altogether, it looks to me like you have a rather outdated notion of what Windows, MacOS, and X11 are. Windows and MacOS have pretty much become like X11 architecturally; they simply lack the well-defined and efficient X11 protocol to support that architecture. On the other hand, X11 toolkits (for better or worse) have become much more like Windows and MacOS toolkits. All three of them have gotten direct rendering and 3D acceleration.

X11-based UIs aren't perfect, but on the whole, they are no worse than the commercial stuff. And whatever problems GUIs like Gnome and KDE have aren't the responsibility of X11, which is merely a windowing and graphics library (roughly like Quartz).

X11-based UIs aren't perfect, but on the whole, they are no worse than the commercial stuff. And whatever problems GUIs like Gnome and KDE have aren't the responsibility of X11, which is merely a windowing and graphics library (roughly like Quartz).

In one particular instance, the Japanese market seemed far more demanding of functionality which dealt with quality issues. I am trying to find good books or other resources which address this issue. Are there any out there? What other areas of computing are impacted by cultural considerations? Should I consider these differences when building UIs, for example?"

<sarcasm>
I don't believe it. According to Jakob Nielsen's "exhaustive" usability studies of 4 Japanese senior citizens and 16 Israeli children, there are no cultural differences regarding usability.
</sarcasm>

In a more serious vein, one place to start might be the Interface Hall of Shame which as a section on "globalization" issues including some tips and recommendations. (Ironically, the site uses frames which means that I can't provide a direct link to the i18n section.)

Another possible source is Microsoft. For better or for worse, they spend a lot of usability and I wouldn't be surprised if that includes i18n.

Gnome Xine will hopefully be a vast improvement and have the sense to bear at least some resemblence to quicktime/microsoft mediaplayer/realplayer.

And while we're at it, let's go ahead and copy the blue screens of death, crashes, and security holes since windows users are so used to those and we're trying to give them an environment as familiar as possible.

There are two different standards for linux software: a standard for technical/kernel stuff, and a standard for interface design. The double standard for linux development: Microsoft's bad technical designs are eschewed, while their horrendous UI designs are embraced. This is largely due to the fact that the linux development community has enough technical saavy to avoid repeating microsoft's dumb technical decisions, but they are so incredibly ignorant of UI design theory that they cheat off the most popular kid in class, who also happens to be the stupidest kid in class(which you can see for yourself at the Interface Hall of Shame)

It would not surpise me if in the next year we'll start to see linux interfaces with window-in-window MDI, multi-row tabs, and talking paperclips.

... try some intentional stupidity. The Interface Hall of Shame

I could list it all here, but it's much more efficient to just point people at:

http://www.iarchitect.com/lotus.htm

(Which is a site that everyone should read before doing UI stuff.)

Sample of one of the "best" bits:

Judging from the number of visitors who have mentioned it, the process of copying messages in Notes is perhaps its worst interface "feature". Apparently, when mail messages are copied from one folder to another, the message itself is not copied; Notes creates a "reference" to the message. Unbeknownst to the user, if you delete the reference, Notes will in turn delete the message itself. Similarly, deleting the message will cause all references to it to also be deleted.

I'm interested in other horrorshow sites myself. I work (mostly) second-level support and I see a lot of confused users. I use the User Interface Hall of Shame to show people that it just might not be their fault if something is confusing. It seems to help the (few) users who actually check it out.

The guys at work had a chuckle at the iarchitect.com User Interface Hall of Shame. If companies like Microsoft weren't featured it wouldn't be half the fun!

Everyone enjoys a scape goat; I noticed that a lot of university professors also reference this site in their online GUI course notes!

Anyone know of any other good "chambers of GUI horrors".

Torturé par la fenêtre.

It is particularly ironic for people from IBM to comment on free software usability. IBM's usability designers have often produced complete junk. Take a look at the interface hall of shame, for example.

Free software UIs are the way they are because the people who use them like them that way, not because of some hypothetical problems with the open source development process. The open source projects with the worst UIs (from the point of view of many open source users) tend to be the ones that try to duplicate Windows or have "professional" UI designers involved in them.

If "ordinary users" find Windows easy to use, great! Let them pay for it. Open source efforts have no obligation to cater to preferences that their contributors and participants don't share.