A small update: The Interface Hall Of Shame is a VERY good resource if you're looking for practical examples. Kudos!
User Interface Design Guide
25th October 2001
User Interface Design is an interesting field of work. It requires experience, patience and a fundamental understanding of someone else's working environment. All of these are properties which come naturally only to a selected few of us. Sure there are books out there which try to teach you all these skills, but has anyone ever developed a special ability just by reading a book?
When it comes to the quality of GUI's, you'll notice that many are easy to use and yet very advanced. However, even more Interfaces are mediocre both in design and usability. The real challenge though is to make a really bad GUI, one that makes users scream in agony and wrapping the mouse cord around their own neck - after you tied the other end securely to a large and potentially fast moving Object, that is. The perfect GUI from Hell is more than just a combination of bad habits and the results of studies on rotten fruit. It's a piece of art. Working for the right company is essential here. If you work for Microsoft, that's perfect! Everyone simply *has* to put up with your nonsense, and you get paid good money for harming others. This is similar to being in the Foreign Legion, but without having to spend weeks in the jungle, wading through waist-deep dung.
The ultimate goal here is to inflict as much pain as possible, causing the end user to scream in agony. Real Hell-UI's manage to make the user bite off a finger while at the same time projecting the cause of the "error" onto himself. These passionate events are called a "golden moment". You probably won't be around when it happens (and if you do you better already have another job at hand), but the sheer knowledge of such things happening because you made them can be a rewarding thing. After all, somehow they have to make up for all the taxes you pay, don't they?
Here are some basic rules on UI Design which, upon implementation, will brighten your life by darkening other's:
First you need not to know what a "usable" design is. You just need to know how to spell "Usability". Not convinced yet? See here:
Boss: Why does that title bar flash?
You: It's better for the end user.
Boss: But some of our betatester were so annoyed that they quit the program. Some even returned the money!
You: Who's the expert on usability here again?
The word "Usability" is your best friend in the battle for inane and stupid label texts, nonstandard buttons sizes and epilepsy-causing color schemes. Using the words "A usability study from XXX has proven that YYY is far more ergonomic than ZZZ" almost never fails to give satisfying results in your quest for inserting stupid design ideas into a product. Substitute XXX with any good-sounding name (university or grade school names work just fine, but you can also try to combine unrelated words with each other for effect), YYY with your design idea and ZZZ with the only logic alternative to your point. The future users of your product are doomed, and they don't even realize it.
The only thing worse than a GUI from Hell, is a GUI from Hell written in some arcane language, possible using a painful framework too. While JAVA may seem devilish and unbelievable flawed, it is far too nice to be used for a GUI. If you can get the project team to deploy VisualC and MFC, that's good. Even better if you can delegate the dirty work to someone else, so you don't even have to the the gooey stuff on your hands. Only masochists *enjoy* MFC, so if you happen to have such people in your team, switch to some proprietary graphics system. Demand that the framework should need at least 512 Megs of RAM and a CPU > 1GHz. If it's anywhere below, it literally smells of efficiency. Java comes to mind as being a power-hungry feature-laden piece of crap, but there's too much improvement going on there so you should look for something exotic and expensive. Preferably something that only runs on SPARCs, and costs more than a Learjet. And I mean that one with leather seats and a minibar.
What could be worse than a unusable, unstable UI? Right, a UI using some proprietary program for displaying graphics and animation! Imagine the horror once a user finds out that this or that was done in Shockwave, and inserted into the application by adding a internet explorer browser window... Better yet, interfaces which require the user to change something once in a while force him to use your tool to update the UI. In that case, Shockwave is far too easy. Try PanView, Sphinx or, if you feel bold, LabView. All of these provide a unique editing experience, and never cease to come up with inspired failure notices and meaningless export warnings. As an added bonus, the result in the program almost never matches what the user was doing in the editor, so there's additional potential there.
If you think that colored icons are a pretty neat idea, you're already on track to the UI from Hell. Add 32 bit colours, animations and other monstrousities, and your choo-choo is running on full-steam - right towards a line of end users tied to the railway. Be warned though that they may still scream and produce all kinds of annoying noises, so be sure to play the Windows Startup Sound (tm) repeatedly to screen that out. The larger your buttons are, the better. Don't use standard buttons, replace everything with custom bitmaps without clearly defined borders whatsoever. Have each button play a different animation when the mouse rolls over them and play an annoyingly loud and unpleasant sound at that event. You could also try to have the sound play at random volumes, so the user can't really adjust the volume to the "right" setting.
With today's abundance of processing power, even more stupid and bold approaches are possible. For example, imagine Michael Jackson doing the moondance on one of your buttons. When the mouse is over the button, you see close-up scenes from one of Michael's many surgeries. And that's just an example, your imagination can run wild here!
However, the real master at work does massive damage by creating icons that don't resemble anything specific. You know, icons that could stand for at least two things, without screaming "Hey I'm an icon designed by an engineer who laughs his ass off at your stupidity right now! Have a nice day!"
If the user lets the mouse linger over the icon, hoping for a tooltip hint, disappoint him by not implementing such things. Alternatively, you could have the tooltips displayed in "Windings".
Your basic rectangular window doesn't provide much room for creative and potentially painful user interfaces. So ditch the standard windows, and use any arbitrary-shaped bitmap. It shouldn't be a symmetric image, and if possible use a painful combination of colors too. If your framework doesn't allow for such esoteric features, set the window background to black and the default text color to green. If you can set the font to "Courier", that's nice too. Don't use Wingdings because that would be too apparent. Plus, there have been reports of users who can actually read this crap, so use something else.
Ah yes, my favourite. It's damn good to know that a document has been printed, right? I mean, with all these computer errors and crashes going on, you gotta be proud if something accidentally went ok. Why not share the joy with your users? *POP* - "Your document has been printed. [OK]"
Can you feel the warm glow of joy? I mean, the birth of a sheet of paper has to be celebrated somehow. But don't go to far with that, you don't have to actually check if it worked. If the printer jams, overheats and blows up violently, taking the whole accounting department with it, it's not your fault - So why bother the user? Never tell the truth: That you just "sent the document to the printer". Say that it's done in full glory, and let the user find out the rest on his own.
This kind of notification is not only vitally important for printing. Be creative: "The background color has been successfully changed. [Ok] [Cancel]", "Are you sure? [Ok]" and "msg:0000041" all qualify as high-priority message that require the user's utmost attention.
Almost no computer comes without a sound card. So why not use that weaponry against your users? If ergonomic keyboards are like a spear into the sternum, annoying sounds are like an intercontinental missile. We've already discussed the possibility of sounds associated to roll-overs, but of course it doesn't stop there. Define "important" events that are accompanied with a short, hard-to-hear sound. Then have the program play a long and loud sample randomly once a day. The user will either have to set the volume low and miss the event, or pump it up and end up as victim of your powers.
Playing entire pieces of music is a nice idea too. Lock the volume controls and play something like Wagner, Berlios, etc.
The improper use of layout is a must-have skill. I don't mean randomly placing the buttons in a circular pattern, since that is far too obvious. It's the small things that hurt. For example, if your program contains many "yes or no" dialogs, you should have the buttons change place every now and then. Define an array of similar-sounding labels like "OK", "Accept", "Save" etc. and have your program use a different label each time a dialog or form pops up. Varying button sizes are also a nice feature, one day you could have small OK buttons and large CANCEL, the other day you swap them around.
This brings us directly to our next point:
- Keyboard Shortcuts
Many users use the mandatory keyboard shortcuts, which could defeat your mechanism of swapping buttons. This is why you should randomly rotate the shortcuts too. One time it's "(S)ave", then "Sa(V)e", then "Sav(E)".
Microsoft Word has used a similar method for many years, providing different shortcuts for each language. While it was Alt-(F)ile-(S)ave in the US-version, the germans had to put up with Alt-(D)atei-S(P)eichern. And if you pressed Alt-D-S, you actually closed your document without saving it. Only a true genius could've outlined such a hideous plot on the users. The less obvious and apparent your attacks on the user's sanity are, the better.
On most systems you can move the "focus" via the TAB-key on your keyboard. The trick is to have the focus move in different directions on each form, possibly skipping a few important elements every now and then. Force the user to use the mouse by placing vital buttons in the middle of a feature-laden window, so he'd grow a beard while hammering the TAB-key.
Once you've got all the swapping buttons, rotating shortcuts and annoying sounds, it's time to work on the menu of your application. Place frequently used items directly beneath potentially destructive actions. It's probably too frisky to have the "(S)ave" item directly above "(F)ormat all harddrives without any further questioning", but then again maybe it isn't. It all depends on the type of your customers. Seriously though, the less obvious things are often more dangerous. It's hard to give good advice here, since this depends on the application you're writing. Having a "Clear all Input" item near "Save" is a classic. Let the user enter several k of text into small input boxes, then watch him accidently pressing "Clear". That's what the author calls a "golden moment".
If you're not a fan of automation yet, you should become one. Be it automated completion in text fields, or automated selection of frequently-used settings, the possibilities for inflicting pain on the end user are endless. MS realized this some time ago, and fitted their browser with an auto-complete feature for both the URL line AND all input fields. No only does everyone using your PC learn that you visited www.persiankitty.com or www.bestiality.com, they also see that you've been looking for "tentacle rape sex" and "bestiality dogs horses bulls" on google... This feature is an instant classic.
Now I know that you can switch that off, but for some odd reason it switches itself back on eventually. On other computers, the computer freezes everytime you enter something into an input box on a website, so you end up leaving it turned on. Only true experts of the human soul are capable of designing such a feature, which is why MS has Hannibal Lecter as usability consultant.
If possible, every moving action in your program should cause the screen to flicker. Java is ideal for this, since even a simple button drains more memory and CPU power than NASA had available during Apollo 11. Once you scare the user from working regularely with your program, force him to it with important-sounding messages and pop-ups. Have him drag entire dialogs, triggering a torrent of complete screen redraws that cause everyone in the room to foam out of their mouthes and spasm uncontrollably in their seats. At night, your program should be capable of substituting a stroboscope. Use different colors with each flicker if you can, but again I'd say that this rides the bull just a little too far.
- Splash Screens
Hey, it's ad space you don't have to pay for! But not only that, it's also a means of annoying people. The usage of embarrassing splashes is mostly reserved to big companies where no individual can be associated with it.But you could also have the splash message stay unneccessarily long, freezing up the whole system and causing visual artefacts when it finally goes away. Playing a sound once your program starts is a must. Play it twice if you're bold. It's the same thing Microsoft had in mind for the user when they made the windows startup sound. Use something undefineable, something which more or less exactly fails to please the ear. Granted, that last sentence was a ripoff from the Hitchhikers Guide To The Galaxy.
In 99% of all cases, whenever your boss asks you to do a splash screen for your program, he'll also demand that you put a "cool Animation" into it. I can already hear your chuckle as you start to drool at the possiblities here. Now, STOP! No I don't mean you shouldn't to Animations, quite the contrary. However, you really must keep a straight face, no matter how deep you can get your boss to dig into the idea. Then, when things are decided and you can run rampant with the splash animation, get to work. Do something bombastic, something never seen before, and never likely to again either - except a customer returns from rehab before reaching the age of 92. People don't like splash screens, so you should make absolutely sure they have to see it. schedule frequent function calls that pull the splash window to the foreground. Don't let the user resize or skip it. Notice something? Notice how many splash screens already comply with these design rules?
Things are looking good - not for the end user, mind you. Eventually, every computer will come with a smell interface, and force feedback wont be limited to knocking the user's hand anymore. The Author envisions a no-so-distant future where you can harass people with stinking error messages, and beating them unconscious remotely. I doubt it'll ever be possible to genetically modify or brainwash users just by using the right combination of color, but one can still hope.
Suggestions? Drop them here -> firstname.lastname@example.org