Re: Help menu: Findings and thoughts
- From: "Ben FrantzDale" <frantb rpi edu>
- To: <merchan baton phys lsu edu>, <gnome-gui-list gnome org>
- Subject: Re: Help menu: Findings and thoughts
- Date: Wed, 26 Apr 2000 10:54:13 -0400
----- Original Message -----
From: Gregory Merchan <merchan@baton.phys.lsu.edu>
To: <gnome-gui-list@gnome.org>
Sent: Wednesday, April 26, 2000 6:59 AM
Subject: Help menu: Findings and thoughts
> After much searching with Google and through paper books, I have been
unable to
> find any rationale for the justification of the help menu. I have not yet
done a
> search through the bibliographic references provided in the books and
articles
> that I've seen; it will probably be a while before I can do that.
>
> As noted by Alan Shutko and sungod, a good reason to right justify the
help
> menu on the Mac menu bar is that it is near one of the five magic points
(which are
> under the cursor and the four corners). These are special points because
of
> Fitts' Law. Since most X window mangers create a bar above windows, and
often the
> close button is near the top right corner, Fitts' law would demand that a
right
> justified menu item (for left to right languages) be considered at a
> disadvantage. Overshooting the item and hitting close would be most
unfortunate. However, if
> GNOME ever emulates the universal menubar of the Mac, then placing an
important
> item in the top right corner of the screen (assuming no connected desktop
area
> beyond it) would be advantageous. The sensitive area of the menu bar would
have
> to be increased to span the complete height as well.
Fitts' law does little good when you have menus in a window rather than on
the top of the screen. (You don't get the advantage of being able to slam
your mouse to the top right in a window.) Also, help menus arn't used very
often so if it takes more than a fraction of a second for the user to figure
out why the help menu is hiding in the other corner then all advantages of
Fitts' law are gone.
--Ben
> It has occurred to me that "Information" may be a superior label for the
Help
> menu. It is a larger word than "help" in at least the romance languages
and so
> creates a larger target area. Since "About" is usually placed in this menu
and
> some other items are more 'educational' them helpful, the label
"Information" would
> also be more descriptive.
>
> A final question. Has anyone looked at the trade-off between a menu bar
vs. a
> pop-up menu? The menu bar provides few (if any) advantages by Fitts' Law
and a
> button3 pop-up menu would be at a magic point. It would be a 'hidden
feature', but
> one that would be quickly learned if used by all apps; it could be
'unhidden'
> by providing an info dialog in the initial run of the app. An immediately
> apparent problem would be the lengthening of context sensitive menus and
that the
> contents of the menu would change. The GIMP and Dia already have this to
some extent,
> though they retain the menubar.
>
> Well, back to learning how to code or sleeping, whichever comes first . .
z
> Greg Merchan
>
> _______________________________________________
> gnome-gui-list mailing list
> gnome-gui-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-gui-list
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]