Re: Seeking Dialog GUI Opinions

I'm drawing heavily on Apple Human Interface Guidelines ( http://tinyurl.com/5hlpe4 ), and I was wondering if any Mac veterans out there have any comments/opinions on the most recent draft:

http://homepage.mac.com/bricolage1/QDialog.jar

Hm. Some of your examples have badly labeled buttons. The buttons should have descriptive names. By using "Yes", "No", "Cancel" the dialogs are forcing the users to read the whole text of the dialogs, which makes them inefficient.

See http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGWindows/chapter_18_section_7.html#//apple_ref/doc/uid/20000961-CJECBHJE

"Buttons for addressing the alert. Button names should correspond to the action the user performs when pressing the button."

This is also recommended by the Windows Vista guidelines, see

http://msdn.microsoft.com/en-us/library/aa511268.aspx#commitButtons

"Prefer specific responses to Yes and No buttons."

Key assets include:
1. An optional help button in the lower-left corner, as well as a mechanism to add other buttons (such as a "Reset" button) on the left side of the dialog.
2. Use of a new class: FixedWidthTextArea. With this class the width of the body text is specified, and the component adjusts its preferred height to fit the text.
3. Constants similar to JOptionPane (YES_NO_CANCEL_OPTION, WARNING_MESSAGE, etc.) to ease the transition from JOptionPane-dependent code.
4. If a cancel button is available, the escape key and 'command-period' map to it.

Nice stuff.

5. An optional "Do not show again" checkbox and a "Always apply this decision" checkbox. (I realize there are several interface guidelines that stress that these are at best questionable design choices, but my client has asked for them, so they stay.) Note: in this demo the preferences are cleared every session.

Get rid of this feature. - Dialogs which are candidates for such a checkbox, shouldn't be in the UI in the first place.

I utterly hate this option in Internet Explorer. Worst thing about them is, that the dialogs show again about after a month. So, I have to choose this option over and over again - wasting my time and my nerves.

I have to say, not supporting bad designs is some of the best "features" of the Mac UI toolkit. :)

6. Two distinct blocks of text: one bold and one in a slightly smaller font. Leopard and Vista both encourage the use of two blocks of text, although their usage is subtly different.

Questionable design decisions (comments welcome):
1. Mnemonics are not activated on Mac. Normally on a Mac using the Aqua L&F, you can specify button mnemonics, and when the option key is held down they are made visible/active.

2. Instead of mnemonics: on Macs for every button with a unique first character, if you press command+(x) then that button is clicked. So command-Y selects "Yes". I realize this is not in the Apple guidelines, but I quite like this feature in GraphicConverter, and I find it more Mac-like than providing mnemonics.

Uh. How are users supposed to figure out these shortcuts then?

3. Dialogs are undecorated when a "Cancel" button is not available. This guarantees that the user cannot use the red close button to try to dismiss the dialog if their choices are, for example: "Yes" and "No".

This looks very odd. On a Mac, dialogs always have a title bar (unless they are sheets), even if they don't have a red close button.

This way, users can still move the dialog window around, because - ever so often - they need to be able to see what's behind the dialog window in order to make a decision.

(That's my main critique to NSSheet in more recent versions of Mac OS X. In earlier versions of OS X, they were transparent enough, to allow reading what's behind them).

Best regards,

References:
	>Seeking Dialog GUI Opinions (From: email@hidden)