Beginning with "Evil DUG's Top Ten Ways to Annoy Users". Remember to reverse the slant of the helpful stuff here. The goal is to annoy the users, not let them out of our trap...
MakeTheUserRememberOrRedoThings?
- Lose the user's work
- Crashing or quiting loses all open pages, no TransparentPersistence
- Accidental deletes can't be reversed
- Incompatible data formats across versions, without a converter between formats
- Put text on the screen (e.g. in an error message) which the user can't copy to the clipboard as text (to paste it elsewhere)
- Make copy & paste not work
- Lose custom settings when upgrading versions.
- Bonus points for hiding the file that remembers the settings or putting them in binary, so I can't just copy from it.
- Lose plugins when upgrading versions. Bonus points if the plug-ns are compatible with the new version, but the application didn't re-install them for the user. Other bonus points if the current plug-ins aren't compatible. More bonus points if the user has to re-download the plugins even when they are compatible.
- Have multiple different mechanisms for "loading" code/applications. Only track changes from some of them.
- For example, VisualWorks doesn't keep track of parcels loaded the same way it keeps track of filed in or manually changed code. Good luck remembering which parcels you had loaded in your last image. And the reason why it doesn't keep track of loaded parcels is because code changes due to them would overwhelm manual code changes. And the reason why is because it doesn't aggregate code changes to the natural "one explicit user action triggered all this" granularity. Yuck.
- Make navigation impossible
- Don't provide back and forward functionality in a browser.
- Lose all forward information when the user explores an alternate path from a previous page (ie, implement history as a stack instead of as a CactusStack)
CreateExtraWorkForUsers?
- Add a lot of confirmation dialogs everywhere (instead of undo functionality)
- Make the most critical ones backwards from the rest, so that when I am in a hurry and realize that I've made a mistake, I accidentally confirm the critical operation that I wanted to cancel.
- Incompatible data formats across versions, with a converter between formats
- Extra points if it most be invoked separately by the user. Even more if it's an expensive add-on. Even more if it's only one-way (to your format).
- Deviate from established standards and conventions
- Use fancy widgets instead of native widgets for no good reason
- Don't use command-line parameters to set options
- Extra points if you're deviating from the standard you're establishing!
- for example, Smalltalk's add: doesn't return the receiver but the argument of the message
- similarly, OrderedCollections don't automatically copy over instance variables when they grow (breaking the "carefree extensibility" standard which ST users know and love)
- Have the user confirm or explicitly perform automatic operations
- "saving" a file; no TransparentPersistence
- in Smalltalk, adding a new>>^super new initialize everywhere instead of having a single such method in Object and an empty initialize there
- Make sure you have to re-install the application via the GUI-based installer on every computer I want to use it on, even if it's a simple application that shouldn't need to monkey around with system settings. Don't let me just copy the installation directory to another computer (or, god forbid, just share the installation directory over a network).
- Of course, on many systems there is no such thing as an app-specific installation directory--executables go in /usr/bin, libraries go in /usr/lib, etc. And in the Windows world; dang near everything that could be considered configuration information goes in the registry--whether it affects the OS or not. This is an example of the LimitsOfHierarchies at work, as we have two separation classification criteria for files (what application, and what type of file) which should be given equal weight, but one is given preference because the hierarchical filesystem forces a choice.
- On my Linux box, I often put applications /usr/local/<app> (e.g. perl in /usr/local/perl), then create a link from the "standard" location (/usr/local/bin/perl) to my chosen location (/usr/local/perl/bin/perl).
- Yeah, see Create More Work For Users.
- Require the user to resolve dependencies between shared libraries and other third-party software components/frameworks/tools/etc. Especially on an OS which handles the task poorly. (See DllHell, RpmHell)
IrreversibleOperations?
- Let the user create but not delete data
- No uninstaller for the application
- Permit complex actions without undo or a reversing path
- Let the user close a browser window with 10 open pages, but not unclose it
- Use confirmation dialogs instead of undo commands. If the user clicked "Okay" even for the 500th time, he must really mean it. He can fix it if he got it wrong.
- Do something irreversible based on part of the parameters given to an operation, then fail when another parameter causes a problem. Bonus points if it's simply a number that's too large for the program to handle.
DialogAndWindowHell?
- CascadingDialogBoxesAntiPattern
- ModalDialogBoxes that:
- need the user to type in information that is available elsewhere in the application. I'd like to copy and paste it, but the rest of the application is non-responsive.
- prevent the user from closing the application (other than via brute force methods like "End Task" in Windows Task Manager, or "kill -9" in Unix)
- Cannot be moved or dismissed
- Re-appear after dismissing them
- Somehow manage to get below the main application screen in the stacking order, and prevent you from minimizing the main application screen in order to deal with the modal dialog.
- More than one at a time from any application.
- Pop up one for each operation that has an error, especially if you can do 147 "operations" at once, filling the screen with error dialogs that have to be clicked away.
- Exist for no reason other than to inform the user that an operation is complete--with the exception of operations that take a very long time. (And such dialog boxes shouldn't be modal).
- Make sure your dialog box jumps out in front of the window I am typing into. Bonus points if you can do it just before I hit Enter, and your dialog OKs something destructive by default.
- Make windows that have widgets that could reasonably be stretched (such as text entries), and allow the main window to be stretched, but don't actually stretch the widgets. (In other words, the "background" of the window grows)
- Windows with scrollbars located inside other windows with scrollbars. Mainly an issue with web browsers (EditPage is one often-occurring example, if your browser doesn't size things just right).
BadFeedback?
- Provide incomprehensible, frightening, or useless error dialogs
- Display keyboard shortcuts that don't actually work
- Bad Progress Dialogs
- No progress dialogs
- Progress Dialogs that can't cancel, stop, restart, don't count properly, etc.
- Progress Dialogs that don't update periodically
- Progress Dialogs that mislead about progress
- computing % from the number of tasks done when there is a wide variation in task completion time.
- Progress Dialogs that "grow" their size when they find out that there is more work to do...
- Acceptable if it is clear that it is a possibility: a combination of computing from task complete + growing bars + clear notice that it is unbounded would be quite appropriate. An exponential decay is not.
- Icons without tooltips; especially if the graphic is nonstandard.
BadPresentation?
- Use fixed sized lists, tables, and fields
- Randomly sort lists and tables
- Sort according to bad or useless criteria
- For a tabbed web browser's page history, sort by "last time opened" instead of "first time opened (ever / in current session)" or "last time active"
- case sensitive alphabetical sorts -- (i.e. upper case Z before lower case a)
- Sort numeric fields alphabetically, so that the order is (1, 10, 11, 2, 3,... )
- You mean like http://www.c2.com/wiki/history does?
- Yes, but that's kind of excusable because they are file / directory names -- the server doesn't know that they are supposed to be numeric. I was thinking about applications that auto-number things (or require you to enter numeric data), but then in the GUI they are sorted alphabetically. That's inexcusable.
- Number lists starting at 0. Causes no problems, just annoyance.
- Spell words badly
- Use poor grammar.
- Put exclaimation points (!!!), ALL CAPS, boldface, etc. in error dialogs. The window title that says "error" gets the point across fine.
- Worrying more about cool tricks like theming/skins than about functionality.
PsychologicalWarfare?
- Be condescending
- Error messages, online help, and tech support should carefully explain how stupid they are.
- Error messages which contain numeric error codes or other arcana that would only be of interest to the programmer.
- Blame them for your bugs, e.g. crash, then lecture them for not shutting down properly.
- Heavily cross-link the help messages. After about the 6th or 7th link, the user will probably forget what the problem was.
- Take things out of the user's control
- Hide the configuration information away in a binary file (or the Windows registry).
- Use your own fancy widgets and fonts, don't leave look and feel up to the user through system settings
- Use random background pictures and provide no option to change or remove them
- make decisions for the user that contradict what they asked for, and don't tell the user.
- for example, if the user selects a folder and requests a ZIP of it, elide the folder name and put all the files in the folder in the top level of the ZIP.
- Unwanted commercialism
- Popup Ads. Even after they pay for something.
- Make the installer advertise your other products, and make the user keep clicking away the ads to get the current product installed.
- Feature gratuitious and snarmy animated caricatures of office supplies as a virtual "usher" to the help system, or similar grave insults to the users' intelligence.
- Steal the user's mouse pointer. See HandVsPointer.
- Make the mouse pointer disappear.
- Provide a non-functional critical path for common operations. For example, when the user asks to download something, make sure the next button under the mouse is Cancel.
ErgonomicsAndAccessability?
- Add extra mouse movements and button clicks
- Force switching between the keyboard and mouse.
- Include no keyboard shortcuts at all
- Complex and nonstandard mouse motions
- Use of 2nd and higher mouse buttons for anything other than what the system prescribes (i.e context-sensitive menus)
- Loud, annoying alert tones, espcially for conditions that do not require a user's attention.
- Flashing messages--or flashing anything (other than games or places where flashing is appropriate).
- Similar commands or gestures associated with radically different actions
- bonus points if one is common and the other is irreversibly destructive
- Picklist widgets for long lists that:
- Don't let you type-ahead to jump to the entry you want
- Are badly presented (see Bad Presentation)
- Do something obnoxious if the list is longer than the application window (early X apps were nasty about this).
- Numeric entry widgets, especially for potentially large quantities, which consist only of an up/down control rather than a text-entry window.
- Requiring the user enter numbers (or other codes) for quantities which aren't numbers. Many PointOfSale? systems are infamous for this. (Function key shortcuts are OK)
Do not use databases
- Oh, no, you shouldn't. You should save your data all over the place in carefully crafted ad-hoc file formats, accessed by your stupid libraries (let alone object serialization). So that if your application crashes, not only that it may loose current work, but it may not be able to restart at all, and the user can't do too much about it either.
- LotusNotes message to user after crashing, on the next attempt to start the program: "Unable to open desktop file. Notes may have terminated abnormally in an earlier session. Please log off or shutdwon the operating system nefore running Notes again." This is the amongst most insulting message I've experienced as a user.
Miscellaneous
- Solve the wrong problem. (Sorting features in order of technical risk, and infrequent releases, help this one).
- Rely on marketing to advertise your wares to their PointyHairedBosses.
- Make sure there are a lot of automatic operations, especially if they introduce gaping security holes.
- Do not match the user's workflow (especially true of custom business software, where the OnsiteCustomer should be able to make sure that it does).
- Put arbitrary limits on numbers of things, e.g. 256 columns of data in a spreadsheet.
- Bonus points if the limit is there to get you to spend $$$ to make it go away.
Note: The original set of "ways to annoy users" was selected by Ron Vutpakdi to be relevant within Landmark Graphics (for our products). So, your top ten ways may be very different.
Easiest Way To Annoy Users
Give them EXACTLY what they asked for to the letter!
This page is getting pretty big and reorganizing it only made it easier for people to add even more stuff to it. I'd like to split it up into smaller pages. Personally, I like HowToWasteUsersTime? and HowToInflictPainToUsers?.
I don't think it's that big yet. The re-organization just prompted 3 or so people to add a lot of things all at once. Maybe it has died down now.
CategoryInteractionDesign
How To Annoy Users