Re: Menus

[sungod <as387 yfn ysu edu>]

Khimenko Victor wrote:
> 7-Nov-98 14:47 you wrote:
> > i've even seen this principle in action: i had to teach a few of my more
> > brick-like coworkers how to use word, and many of them were confused
> > when all documents were closed, since most of the menus disappeared. i
> > can vouch authoritatively that making menus and menu choices appear and
> > disappear depending on context is inconsistent and confusing. let's work
> > on alternate approaches to graying out, instead, shall we? that one's
> > pretty well confirmed.
> 
> IMO when menus are apper and disapper depending on context is [usually]
> consistent in M$ Office:

nope, i'm just talking about word documents within word. that may be why
you misunderstood my example.

> when you are editing Word Document you have
> menus needed to work with word document;

not if you close all documents. the screen looks surprisingly close to
an open-but-blank document, except most of the menus are gone. this was
a source of confusion to a few of my pupils.

> when you edit M$ Excel Table you
> have menus needed for editing of M$ Excel Table (even if this table is
> embedded in Word Document!); when you edit embedded Diagram or Equation you
> have menu suited for this task.

[skipping this because none of it has to do with my example]

> And when there are no documents to edit you
> does not have any of that menus/toolbars -- only generic ones. How this would
> with graying approach I'm could not understood.

the apple style guide defines this clearly. have you read that part yet?

> All menus for all possible
> embeddable objects 

incorrect, and this is the source of your confusion. yes, we need to
deal with embeddable objects, and yes, we need to dictate how baboon
objects play with each other on the desktop playing field, but no,
that's not the topic we're currently discussing.

this is actually quite a lot more indepth than you make it here
anyway... imagine someone using a gwp object to edit lyrics within a
digital audio workstation program. it's even _more_ confusing to get rid
of all the daw menus and replace them with gwp menus just because the
user clicked in an area containing text instead of digital audio data.
this needs to be dealt with, and gracefully, but that's not the point of
the discussion. what we're talking about is things like graying out
"paste" when there's nothing in the clipboard to be pasted.

the argument for graying out "paste" is that it presents a much more
_stable_ appearance to the user, and makes it more intuitive. let me
give an example:

a brand-new computer user fires up gwp for the first time. he clicks
through some of the menus, and under "edit," sees absolutely nothing.
this is bad design for obvious reasons.

the user types a few words, and suddenly there is an "undo" choice in
the edit menu, but of course the user doesn't know that and isn't likely
to discover it since he thinks there's nothing in the edit menu.

if the user selects some text in his document, "cut" and "copy" appear
in the edit menu, but even if the user _did_ discover "undo" earlier, he
still won't know about "cut" and "copy" because they weren't there
before. even if he does find them, their exact functions won't be very
clear since (in the absence of any data in the clipboard) there won't be
a "paste" available.

now pretend "undo," "redo," "cut," "copy," and "paste" are grayed out
under "edit" when he flips through the menus the first time. yes,
they'll all be grayed out, as will the menu name itself, but the mac os
has proven to us that this is not a problem: the "perceived stability"
(as the apple human interface guidelines call it) and "discoverability"
(as i call it) are still both intact, and even if he isn't sure exactly
how to "paste" data yet, he knows where to go to find out when he thinks
he finally has some data in the clipboard.

> with more then 90% of items grayed, perhaps. Are you joking ?
> Is THIS more usable approach ???

nope. this is the result of your misunderstanding the topic at hand.
this is exactly _not_ what we're talking about. i think if you read the
apple human interface guidelines we can avoid confusion like this in the
future... anyway, the gnome style guide is supposed to be based on it so
you should read it regardless.
-- 
 ______(sungod)_____________________________________
| To ensure privacy and data integrity this message |
| has been encrypted by using dual rounds of ROT-13 |
 --------------------------(as387@yfn.ysu.edu)------