Re: Menus

["Khimenko Victor" <gnome-gui khim sch57 msk ru>]

8-Nov-98 12:46 you wrote:
> 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.

No, I'm not misunderstood your example. I simple want to extend it to compound
documents (monsters like current MS Word is not way to go; we'll need compound
documents for A LOT OF things in the future).

>> 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.

Not exactly. All buttons on toolbar for editiong Word Documents are gone as well.
And this was done this (consistent) way in MS Office 95. MS Office 97 all menus
are there but items are grayed. Plus MDI was mistake in first place -- when all
documents are closed then no need to keep program around...

> this was a source of confusion to a few of my pupils.

Yes, since they perceptions was already perverted by "application" paradigm.
Plus, of course this #$%$&$%# MDI stuff.

>> 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?

Not. Where I'm could download apple style guide ?

>> 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.

It was topic I AM DISCUSSING: why after closing last document you still have
SOMETHING on screen ? Why all this application stuff ? Why you need application
at all if there are no document to edit ?

> 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.

Why user need daw menus when he(she) edit text, not digital audio data ? And
if daw menus will not disapper and then I'll try to edit picture inserted in
equation inserted in graph from spreadshit inside of text document inserted in
daw (original lyric :-) -- how menu menus from all six programms there are will
be shown ?

> 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.

It was initially about items grayed out by sysadmin.

> 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:

[example skipped]

Yes, I'm understood the point. But here is other point: it's Ok to have grayed
menus which could be activated after some INTERNAL change (not easily visible
on screen: it's not visible on screen if there are exist commands to undo and/or
text in clipboard) but it's not Ok to have menus which could not be activated
without changing of screen significally (like menus from daw when you edit text)
or at all (like menus deactivated by sysadmin).

>> 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.

I'm REALLY hope that gnome style guide will be not based on apple human
interface guidelines nor on windows style guide or some other style guide.
You could use Mac OS or Windows if this is what you really want. Of course
some ideas from apple style guide will be borrowed as well as some ideas from
Windows style guide but GNOME style guide should be self-describing thing and
not just modification of apple style guide for *nix ...