Re: RGSG - contents of Program menu

["Dan \"Effugas\" Kaminsky" <effugas best com>]

-----Original Message-----
From: John R Sheets <dusk@smsi-roman.com>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Wednesday, August 05, 1998 10:46 AM
Subject: Re: RGSG - contents of Program menu


>Dan Effugas Kaminsky wrote:
>>
>> As I've been saying, I'm *OK* with Preferences going with the
>> menuprint/Program menu.  But preferences are by their nature rarely
>> accessed, meaning we take the most prime real estate on the entire menu
bar
>> and fill it with...toys?!
>
>Okay, I think you're going on a different set of assumptions than
>Tom is.  You are identifying "Preferences" with settings that are
>rarely accessed.  As near as I can tell, Tom (or at least I do)
>sees "Preferences", or whatever settings menu item ends up in the
>foot menu, to be application-wide settings, regardless of how
>common/rare they are.


I was going off of Bowie's definition, seemed logical.  Options are things
you actively change, preferences are kinda behind the scenes things.
Regardless, Preferences in all of its glory can be in the menuprint, fine by
me!

>Would you disagree that settings that affect the application as a
>whole (e.g. "Show Toolbar Text") should be placed in the foot
>menu?


Nope.  I just don't think "Show Toolbar Text" deserves precedence over
"Open..."

>Also, regardless of what IBM's research was about the leftmost
>menus being the most commonly accessed, we appear to be moving
>away from that, into a more object-oriented menu standard, based
>more on scope than on frequency of use.

Whoa, slow down there.

Main Entry: us.able
Variant(s): also use.able /'yü-z&-b&l/
Function: adjective
Date: 14th century
1: capable of being used
2: convenient and practicable for use
- us.abil.i.ty /"yü-z&-'bi-l&-tE/ noun
- us.able.ness /'yü-z&-b&l-n&s/ noun
- us.ably /-blE/ adverb

"Frequency of use, object oriented".

Buzzwords are nice.  They're also useless.  Java has twelve or fifteen
buzzwords that Sun crows about.  You know what users care about?  Do you
think users know about the Sandbox?  Do you think users know what Object
Oriented means, besides some kind of new sexual orientation that they don't
EVEN want to know about?

No.

Java = Loads Slow.  Java = Crash Browser.  Java = Frustration Enabled.

I'm being nice, I'm not flaming you, I'm just saying real clearly:  I don't
care if we base the menu order or titles on the amount of hairs that fall
out of Tom Vogt's head each time he recieves four dozen emails/comments from
me, I CARE ABOUT USABILITY.  If a psychological case can be made for Vogtian
Scalpology, and research backs it up, wonderful.

>  Application-scope menu
>items go in the first menu.

Does this improve usability?  Lets think as the user:

"OK, lets begin...uhm, so the first thing I can do is leave...what now...ok,
I can change the way this program works?  I haven't even started using this
program...screenplay?  huh?"

Lets replace this menu with a I/O menu named File.

"I think I've heard of this...hurm, ok, I opened up a word processor, and
want to open something up, oh, the second thing here is open, ok, now I want
to save, look, it's right there, hurm, can I work on another thing right
now?  new, cool, wow, this is logical"

Now lets replace this menu with a generalistic menu named Documents

"that other program had a graphics menu, where can I open new files in this
application, oh, some location, what the heck does all this stuff do, I
can't find print, oh there it is, it's at the bottom because font is above
it?  damn, the more stuff in this list the harder it is for me to look
around..."

>  File/document/object-manipulating
>menu items go in the second menu.

Oh, that's all.  Isn't that, oh, a large amount of items in, say, ANY DECENT
WORD PROCESSOR?

  The following menus should
>either describe further objects (e.g. a layout program that
>handles text document-editing differently than image-editing,
>leading to both "Document" and "Image" menus), or other large
>categories of functionality (e.g. "Format", "View", even "Print"
>if the print functionality is very advanced & complex).  IBM's
>research is important, but I don't think we should base our menu
>structure solely on frequency of use.


So we should have a REALLY WIDE menu bar with *TWO* menus, and to prevent
things from getting too long we should folderize by category.

Uhm, dude?  I have no problem with windows shrinking into the root menu, or
even the program menu under "hidden menu items, but PLEASE tell me how, in
general, having only two menus is going to increase usability.

>Please try to get your assumptions down straight before spending
>so much time arguing a point.  That in itself will be more useful
>toward reducing the incredible amount of noise this list has been
>producing lately.


IRC?

Dude, think in terms of usability, not programming elegance.