Re: [HIG] REVIEW of Mini-HIG draft - Section 2

[Calum Benson <calum benson sun com>]

> 11. Menu Principles > Popup Menus
>
>     *   Sometimes it may not be practical to duplicate every item from a
>         shortcut menu in the main menus; this is acceptable as long as
>         the keyboad accessibility conditions described above are met
>         <http://bugzilla.mozilla.org/show_bug.cgi?id=34357>.

Knowing the sort of real world issues that can arise, I vaguely agree,
although I'm not overly convinced by the examples in this particular bug
report ("Copy Image Location", "Add Bookmark for Link" and "Show Only
This Frame" could quite easily be accommodated in any reasonable web
browser's menu structure).  

But how  do you propose the user discovers this popup-menu-only
functionality?  Popup menus are still considered an "expert" feature and
there are still a large number of users out there who don't know popup
menus exist (see Sun's usability report for some examples of this). 
Making the menu keyboard accessible doesn't help this issue.


>     *   As keys for keyboard shortcuts go, the F1 to F12 keys are the
>         worst, since they have no mnemonic value at all 

This, just for the record, is the very same argument I've had from a
couple of non-native English speakers arguing that we *should* make more
use of F-keys for standard keyboard shortcuts-- because
Ctrl+some-meaningless-letter makes even less sense to them than some
neutral shortcut like F5.

(It's not quite as simple as saying that people should just translate
keyboard shortcuts when translating the GUI, unfortunately, as this not
only has knock-on effects in documentation, but completely screws people
who occasionally use two or three different language versions of the
same software...)

>     This layout is very reminiscent of the 1980s -- when applications
>     were more important than documents, when documents had to be
>     manually saved frequently to avoid being lost, when the Internet
>     was practically unheard of, and when the climax of the life cycle
>     of a document was to be printed on a printer. 

This sounds exactly like the way I use GNOME in the office, actually...
and even more like the way I use my Mac at home  :)


>     I think it's highly unsuited to a modern computing system 
>     where multiple applications are open at once and where computers are usually
>     connected to the Internet.

I'd definitely like to see some proof of that last assertion.... you
might be right, at least in the case of computers running GNOME, but I'd
be surprised if it was globally true.

>     Select None
>
>     I have never seen an application in which such a menu item is
>     either necessary or desirable. When editing text, any of the arrow
>     keys should clear the selection; when multiple files are selected in
>     a file manager, or multiple objects selected in a drawing program,
>     Escape should clear the selection. In neither case does the action
>     need to be listed in the menus, just as other basic shortcuts such
>     as Control+Left/+Right and Page Up/Page Down are not listed in the
>     menus.

I can only re-iterate what I said on #hig the other night-- in graphics
applications, a selection isn't so much a transient thing as an object
in its own right, which can often persist even between sessions, and can
be given names, and individually saved and loaded independently of the
graphics files themselves.  Graphics apps are also inherently modal, so
Esc is commonly used for getting you out of the current mode, and
overloading it to mean "or clear the current selection in some
circumstances" sounds a bit dubious to me.

I agree it's of no use in a text editor, although I have to admit I'd
never think of pressing Esc to clear the selection in a file manager.

This doesn't apply to a "Select None" menu item, but what if my dialog
box has a simple multi-selection list control (which doesn't usually
have a background to click on to clear the selection), and OK and Cancel
buttons?  When the list had focus, I'd certainly be scared to press Esc
for fear of closing the dialog in that case-- I'd want to have something
a bit more positive like Ctrl+Shift+A.

> 25. Search Help
>
>     This is a mistake. Users will only choose to search a set of
>     documents *after* they discover that the top-level navigation
>     provided for the documents is inadequate. 

I can only speak from my own personal experience of usability tests
here, but this hasn't been the case in any I've been involved with-- in
those, searching has always been by far the primary means of interacting
with online Help, especially for help with the more common type of
task-based problems, which context-sensitive help is rarely any use
for.  

Rather than plough through a contents page hoping to find exactly the
right "How do I do X" entry, most users wanted to hit search straight
away, and some got annoyed when they couldn't get straight at it from
the Help menu.  Which is why I suggested adding this menu item here.

I haven't been involved in any online help testing for a while, but
since many users are now used to websites, where various usability tests
show that people will head for the search box straight away rather than
browse the content if they have the option, I'd be surprised if fast
access to online Help searching wasn't even more of a requirement now
than it used to be.

> 26. Mini-HIG > `Menus and Toolbars' > `Toolbars' > Controlling Display
>     and Appearance of Toolbars':
>
>     It is probably a bad idea to have the radio items in the submenu if
>     toolbar customization is supported. The user's choice of text,
>     icons, or both will often depend on how many buttons he has included
>     in his customized toolbar, so it is most convenient to change the
>     icons/text/both setting in the customization window itself.

Hmm, fair point, although if I subsequently wanted to change my mind I'd
be a bit annoyed at having to open a dialog box to do it.  Actually, the
best (additional) place to do this would probably be on a right-click
menu on the toolbar itself, but I guess GtkToolbar doesn't support
this... dunno about the Evo toolbars.

> 28. Mini-HIG > `Menus and Toolbars' > `Toolbars' > `Default Toolbar
>     Layout - Office Applications':
>
>     `Replace' is discussed in point 23 above. As for `Help', if your
>     main toolbar needs a `Help' button, your interface is probably too
>     difficult for a `Help' button to be much use.

I don't see why a help toolbar button is any more of an admission of
failure than a help menu, personally, but I'm happy to lose whatever we
can from the main toolbar...

> 29. Mini-HIG > `Menus and Toolbars' > `Toolbars' > `Default Toolbar
>     Layout - Browser Applications':
>
>     Now, sometimes when you need `Stop', it's at a random point when a
>     page is loading, so it doesn't particularly matter where in the
>     toolbar the button is. All that is important is that it must *not*
>     be near the right end of the toolbar (as recommended in the
>     mini-HIG), because there it would disappear when the window was
>     sized to a narrow width.

Well, it wouldn't if GNOME toolbars gave you the option of any sort of
sensible wrapping rather than cropping... and I've never wanted a web
browser window that's narrower than the toolbar anyway because it
becomes impossible to read anything  :o)  But I take the point...

>     Obviously some applications (those accessing information from local
>     storage) do not need `Stop', while other applications do not need
>     `Reload', so this might not be the sort of thing you can make
>     guidelines for in the first place (especially if you don't offer the
>     reasoning behind them).

Well, I don't see that this is any different from any of the other
menu/toolbar items we're discussing that apps may or may not need.

Cheeri,
Calum.

---
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems