Some Good Examples of Bad UI
Posted February 8th, 2004 @ 04:31pm by Erik J. Barzeski
I consider myself to be an advanced computer user, and certainly an advanced Mac user. Here now are two lovely pieces of UI that have recently earned the title "the most annoying thing I've seen today." Perhaps I saw both at 7am, but regardless, they're what I feel are good examples of bad UI.
Since when has the cancel button ever been the blue, pulsing one on the left? Since when has it ever ignored the escape key? If I choose to reset Safari from the menu by mistake, I sure as hell don't want to hear a beep when I hit the escape key! At the very least simply make neither button the default button. Jee whiz!
Next we've got iChat. I never use it, but doggone it if it didn't take me a few seconds to figure out that the genius behind the "Show as Text/Show as Balloons" functionality has essentially tried to create a radio button in a menu.
Checkmarks should turn on and off when you select items, not toggle between two different items (or, worse still, three items just below and above!). What's even funnier, the "checkmarks in menus" thing is done properly in the first section with "Show Buddy Pictures" (et al).
Horrid. Just horrid.
Donate Life
Posted 08 Feb 2004 at 4:40pm #
I can understand not making reset the default in this case since it's destructive. But escape really should work. I run into that in Xcode too ("are you sure you want to undo?").
The checkmark thing, yeah. Mmalc keeps talking about "UI consistency creep" -- with GarageBand being a favorite example.
- Scott
Posted 08 Feb 2004 at 5:04pm #
If you want to see even worse GUI look at the advanced preferences in Safari.
They used two radio buttons instead of one tab:
(_) Highlight links as you press the Tab key
(•) Do not highlight links as you press the Tab Key
Posted 08 Feb 2004 at 5:53pm #
Mark:
Agreed. It should just be a checkbox "Highlight links..."
As for the Reset Safari window, most people NEVER want to do that, and when they do, they explicitly want it to occur. By having the Cancel button be the active button, any deliberate hits of the Return key will just cancel the window, instead of resetting Safari.
Not a perfect implementation, but I call it necessary.
Posted 08 Feb 2004 at 6:15pm #
Those two examples are nothing compared to the iPhoto keywords dialog. Check out my rant.
Posted 08 Feb 2004 at 8:36pm #
I'm not sure I understand your feelings about the radio-button behavior in menus.
The use of exclusive-or options (radio buttons) in a menu may seem atypical. I agree that they aren't common, but I'll give you three examples where they've existed beyond just in iChat...
1. Mac OS X - Most icons in the system tray
Clock's Analog/Digital setting; Battery Icon/Percent/Time; Input methods (if enabled). And many more have this behavior.
2. The Finder Label menu
Admittedly the implementation in Panther is sui generis. But Apple used this radio button like behavior in Mac OS 6-9 as well. Sometime along the way they pulled the labels themselves off into their own hanging sub-menu, but you've never been able to select two labels ("Project 1" and "In Progress") even though it would make logical sense to have this ability.
3. MacWrite
This goes back to the days of the original mac interface. The famous screenshot you'd see in Apple's original brochures that demonstrated MacWrite's ability to handle different fonts/sizes/styles. The top of that menu had the styles (bold and italic were selected I think). The middle section had 9,10,12,14,18,24 pt sizes (12 was selected I think). and the bottom had a small collection of 6 or 9 fonts (don't recall which was selected here).
So are you saying that not having a separate visual indicator (like AWT or Swing does) is a bad thing? Or that the exclusive-or behavior in a radio button menu is a bad thing? Or that this is an inconsistency in the mac gui?
Posted 08 Feb 2004 at 9:57pm #
The old Mac GUI used a little black diamond as the indicator for "radio button" menu items. What happened to that?
Posted 09 Feb 2004 at 11:28am #
In case you're curious there's a document that is supposed to be used both internally and externally to apple to help engineers (and designers) make these choices. I have to admit that sometimes i disagree with the guidelines, but i have to feel pretty strongly before i'll do something contradictory with them. With that said,
The safari dialog: default (pulsing blue) buttons should only be the lowest right hand button -- in the case of a dialog warning about possible data loss or harmful operations we recommend that no buttons be default. Escape normally maps to cancel, it's not a strict recommendation but NSAlert gives it to you for free so most developers don't override it.
iChat Menus: this touches on a rule that i disagree with often, but have chosen to stick with guidelines because it's an area where consistency is a pretty good thing. Basically, iChat has completely ignored the rules here though. There are three recommendations: 1) have explicit menu items for each option, even if they are mutually exclusive 2) if you don't have space, use the Show/Hide menu items which change their text when choosen and always display what will happen if selected 3) Don't use "show" or "hide" while using the mutually exclusive checkmark method.
As you can see, they followed 1 but didn't really follow the other two. There are six groupings of items in that menu and they alternate between being mutually exclusive items and toggle items. The toggle items should go between "show" and "hide" while the mutually exclusive items should continue to use the checkmark but change the text, simply dropping the Verbs.
BTW: to chris's comment about the diamond, that is reserved for use in the window menu to indicate minimized windows, although it's hard to find an app that actually uses them as recommended. I personally think they should have matched menus with the other UI and chosen to use checkmarks for toggles (like checkboxes) and round dots for mutually exclusive options (like a radio button). But alas, they did not use this convention.
Posted 09 Feb 2004 at 2:04pm #
The blue pulsing merely indicates the default option (hit return), which in MOST cases is OK (the right button by Apple HIG).
However, the default for this is Cancel, a more cautious approach. This makes sense to me. However, hitting ESC shouldn't beep as it's the Apple HIG for Cancel.
Posted 09 Feb 2004 at 2:44pm #
I guess I wanted to mention something as well. With the advent of option-tabbing in safari for links, How do I insert a tab (a \t) in text fields? It used to be that pressing option-tab would insert a tab character. This is similar to typing option-enter in areas where typing enter would normally submit a form or close a dialog, etc. Now, it tabs to the next link. It seems that sometimes it enters a tab and goes to the next link, and sometimes it just goes to the next link. Ugh...wish there was a way to fix that!
Posted 09 Feb 2004 at 6:22pm #
> Since when has the cancel button ever been the
> blue, pulsing one on the left?
This has long been the standard button layout for confirmation dialogs for irrevocable destructive actions. The most common example is the "Are you sure you want to replace this file?" dialog you see when you try to overwrite a file in a Save dialog.
The problem is this: in a regular dialog with two buttons, Cancel and Action, there are two UI conventions at play:
1. The default button is always in the bottom-right corner. The Cancel button is always the left-most button.
2. The Action button is the default button, and thus can be invoked using the Return key. The Cancel button can be invoked using the Escape key.
Now, in the special case where Action is irrevocable and destructive, it's generally a good idea not to make it the default button in the confirmation dialog. But once you break the second of the aforementioned conventions by making Cancel the default, you *must* also break the first convention -- as the "cancel" button, it belongs on the left, but as the default button, it belongs on the right.
I think that the Cancel-on-the-left convention is more important than the default-button-on-the-right convention, and thus Safari's button layout is correct.
The only other option I can think of is having *no* default button for a dialog like this. You'd need to explicitly click the Action button, but you could use Escape to invoke Cancel.
> Since when has it ever ignored the escape key?
This should be considered a bug. When "Cancel" is the default button, it should respond to both Return *and* Escape. (As it does in the "Are you sure you want to replace this file?" dialog.)
Posted 09 Feb 2004 at 6:34pm #
Agree with the Safari rant 100%... but a checkmark has been used as radio button functionality for ages in almost every application... in the Font menu.
Posted 22 Apr 2004 at 12:52am #
Bad UI?
Brad implemented deleting subscriptions in the subscriptions window today. A sheet slides down, prompting you for confirmation. He put the "Cancel" button on the right and made it default (i.e. blue) and the Delete button on the left. This reminded...