- LongListsSmell - Don't make users read a bunch of junk to find something. Let them search for substrings or something if needed. (Somewhat related to big menu issue below.)
- Greyed-out options - Often it is hard to know why they are greyed out. An alternative is to allow selecting/clicking grey options to get an error message telling you why it is greyed out.
- A better alternative is to show the reason as a tool tip or status bar text. It is much worse to give the user the expectation that their command will be accepted when you know the whole time it won't be.
- One-click mayhem - Example: Microsoft Windows Explorer making it too easy to accidently drag an entire folder into another one without confirmation.
- Would this be so bad if you had confidence that the 'cancel' and 'undo' options worked flawlessly every time? Why is moving a folder a more fearsome operation than moving a sentence to a different place in a document? Should those moves be confirmed also?
- Many times I and other users have dragged folders into other folders without even knowing that such an action took place. It is easy to do if your timing of moving the mouse and lifting your mouse finger are a fraction of a second off. "Undo" is of little use unless you know there is something that has to be undone. This is a fairly common source of help-desk calls. As far as the comparison to word-processing, I move text far more often than I move folders. Perhaps a "don't warn for X minites" option could be available. Or, simply a user preference somewhere with the default to warn. If you are doing a massive cleanup one day and don't want a warning dialog, then one can turn it off. The warn dialog should perhaps mention that such an option(s) is availabe.
- Maybe "confirmation" in this case could come through some other mechanism than a modal message box. It sounds like the problem is that the interface is responding to subtle movements when you are trying to communicate with coarse movements at the time. Maybe the interface could delay highlighting the drop target until the drag operation has already been going on for some amount of time, say 200 milliseconds. The time could be adjusted manually by the user, or automatically, based on your recent usage. Most interfaces already use small delays like this to differentiate ambiguous commands. For example, the difference between a double click and two single clicks is determined this way.
- Micro-second-based interface feedback systems are difficult to program and often don't work well over networks such as remote desktopping or slow/bogged-down machines.
- Should we do away with the double-click, then? The remote desktop problem you mention can be solved quite simply by having the client add timestamps to user input events. And the payoff for fixing this problem sounds well worth the extra programming effort.
- Perhaps. D.C. drives beginners crazy. Windows Explorer would be fine with single-click, for example (if used to it). But usually double clicking just runs something, not moves or deletes stuff. I guess I am really saying that mistiming by itself should not result in permanent changes. If you miss the double-click threashold, you just have to do it again, thats all. Small differences in timing should only cause small or zero DiscontinuitySpikes. If the Launch Nuke button is red, the Order Coffee button should not be a similar Ruby color, for example. Maybe we need to reword this principle to something like, "small differences in user action should only result in small differences in results", or the like.
- Hysteresis - the path from A to B differs from the path from B to A. Example: In Gnome's file selector dialog, clicking a folder expands that folder. But you can't click any [^] up button to go back to the parent. [Unless I am mistaken], you must select the parent from an irritating list of folders, mounted on the bottom of the file selector.
- I think you have it backwards. You want to click a special toolbar button to go up, but select from a list to go down. What you want is different paths from A->B and B->A, by your description. I'm not defending Gnome's design here -- the file picker doesn't sound too great either way. But you should stray from making broad generalizations like this. It's not always bad when the path from A->B is different than the path from B->A.
- CascadingDialogBoxesAntiPattern
- Ignoring Screen Resolution - A user with high resolution should be able to see more of the screen items. Controls such as lists and textboxes should be resizable and expandable to the maximum resolution. The old Windows file dialog boxes had this problem. Also, You should not split a step into 2 screens (thus wasting time/clicks) that can both easily fit on one screen. Screen consolidation is a virtue.
- I have lost count of the number of times that I find the screen of a user - even a power user - set to a low resolution because "if I make the pixels smaller I can't read the fonts". I have to show them how to change the DotsPerInch?, so all the fonts get larger (and smoother) at once.
- I have not found a Windows setting that does this and works in all/most situations. Some apps have their own internal font system, for example. They don't care what the OS has set. (Cross-platform apps often do this to avoid having to write/maintain/support code for multiple OS's.)
- Too Many Menus/options - Some apps have so much stuff that it is difficult to find anything in the menu system. If you have that many options, then perhaps another approach such be taken, such as an option browser that uses some kind of table and/or tree search. In other words, treat options as meta-data and provide query-like and/or Google-like search capabilities, perhaps with the option of marking the ones that are high priority or on the tool bar. Menus should perhaps still be provided, but offer the options browser as an alternative. (GooglifyDeepMenus)
Meta issue: I don't like the convention of an extra nesting level per reply. It gets difficult to count the levels beyond a few, and does not fit in browser window well. In short, it does not scale. I prefer alternating italics, non-italics. Example:
- Issue X
- Is too
- Is not
- Is too, my mother says so.
- But you don't have a mother
- But I programmed my own.
See my thoughts on this at NestedThreadMode.
- SL: Except, that text-only browsers do not display italics differently form non-italics. Adding short signatures at the beginning of the quote, so it reads like a screenplay, would improve thread readability, with a minimum of expense to overall readability. Thus:
- XR: Issue X
- GT: Is too
- XR: Is not
- GT: Is too, my mother says so.
- XR: But you don't have a mother
- GT: But I programmed my own.
See also: ControversialMicrosoftPhilosophies
AugustZeroSix
CategoryUserInterface, CategoryCriticism
User Interface Smells