Re: menu bar proposal (attn: dan k)

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

-----Original Message-----
From: sun <as387@yfn.ysu.edu>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Cc: Dan "Effugas" Kaminsky <effugas@best.com>
Date: Wednesday, August 05, 1998 1:08 PM
Subject: menu bar proposal (attn: dan k)


>throughout this post (and others) you have repeatedly misunderstood the
>very basic premise upon which i have submitted my proposal for the gnome
>menu, so i shall try to restate it clearly and concisely here and then
>address your misunderstandings based on their relation to the proposal.
>here it goes:


Please understand there are other proposals that contain elements that yours
does not.

>given a program, "gnome-edit," a program designed to edit text in
>several different documents at the same time, involving great depth of
>user configurability and possessing powerful text editing tools like
>search and replace, advanced spell-checking, and thesauri, among simpler
>but widely accepted commands like clipboard operation and simple file
>manipulation:


Sounds good.

>the application shall feature a menu bar at the top of the window which
>contains the following:
>
>1.) a gnome footprint menu (hereafter referred to as "tmfkap")
>containing all menu choices which do not affect any one individual
>document being edited at any given time; rather, commands which affect
>the entire application.


That would place page setup separate from print, as page setup deals with
all documents but print sends out the active document.  While page setup
*is* a preference, I think it is fair to say that it's one that belongs
closely coupled with Print.

>2.) a menu whose title shall reflect the basic unit of operation which
>the user is familiar with, in this case, "document," which shall contain
>commands which influence each entire document separately, or all
>documents collectively if such a command does not also influence the
>application itself, its look, or the way it works.


So, instead of a File menu which limits options to I/O stuff(with the
arguable exit menu exception...note, you don't go here, others do, accept
that fact), you have a single, catch all menu that can contain anything.  It
can be scientifically proven with a high degree of confidence that the File
menu is the single most memorized menu in all of computing.  In other words,
if you ask a user, "What entries would be contained by a file menu" vs.
"What entries would be contained by a format menu?",  the user will remember
many more entries of the file menu than of the program menu.  This is due to
the high correlation of file menu contents between every application the
user chooses to load.

That being said, it is also fair to say that the entries that are memorized
in the file menu--generally new, open, save, close, print, and exit, though
variants may also be reported--each play key and critical roles in the
operations of most if not all applications.  Indeed, it is mainly these
commands and cut/copy/paste that unify the interfaces of most graphical user
interface applications.  The importance of these commands to quick memory
access thus demands the interface separate them and present them in a
consistent interface, possibly with other menu entries *related to the I/O
functions listed*.  Such consistency will increase memory retention of the
application command structure.  Allowing total freedom to the application
programmer without even the guide of the style sheet has multiple risks.
First, without substantial argumentation included in the style sheet, it is
very probable that the Renamed Menu Recommendation be ignored, but since it
will be sometimes followed, application consistency will be minimal and
GNOME will have the negative reputation as being the only interface that
doesn't stick with the standard File menu.

I have begun conducting research expiditions; they will occur both on IRC
and in real life.  A new relevant rebuttal has been offered:

<AnguzHawk> i mean if you are gonna write this program then you must hate
tech support people and would be willing to pay them alot
<Effugas> Hawk we're writing the style guide
<AnguzHawk> because since things are at a standard now people wont know how
to use your program
<AnguzHawk> so they will call and bitch
<AnguzHawk> they wont know how to quit so they will call and bitch
<Effugas> Hawk good point
<AnguzHawk> if you want to know why anything is done a certain way with a
computer go work tech support for 2 years and listen to people bitch
<AnguzHawk> you will know why all apps have the same interface
<Effugas> Hawk have you worked tech support?
<AnguzHawk> cause people are stupid and dont want to have to learn something
new
<AnguzHawk> 2 years of hell I did

    Since, psychologically, vendors do not want this tech support nightmare,
they will not support GNOME, and this project will fail.

>3.) other menu choices organized according to the author's judgement (or
>otherwise specified by the style guide), as long as the menu choices
>contained therein are not suitable for inclusion in the specified menus
>(1) or (2).


The (2) exception is a new one.

>4.) a help menu, which shall contain easy access to the application's
>documentation and any active assistance that exists.


Agreed.

>"...containing all menu choices which do not affect any one individual
>document being edited at any given time..."
>
>therefore, font, margins, and minimum tab lengths don't belong here.


I do believe I was saying that the *DOCUMENT* menu was going to get
overloaded.  The menuprint just becomes a toy store ;-)

So lesse, according to what you say above...

>which shall contain
>commands which influence each entire document separately

Font:  If the application changes font in a uniform manner, but does not
change indentation patterns in a uniform manner(very possible for an IDE),
we see the former file menu saddled with a preference--print/display font.


>> >i will say no more on this topic. quite a few on the list have gotten
>> >this so far; i am agreeing with tom that you are only trolling now for
>> >"devil's advocate" sake.
>
>okay, okay, so i'm back saying more on the subject. i have no
>self-control; if challenged, i guess i feel obliged to respond. :)


Ditto.

>> What do you think of that Force Quit v. Exit menu?
>
>needlessly complicated. one menu choice has worked well for doing this
>in the past; i have yet to see a good justification for splitting
>separate behaviors of the same command into different commands. if you
>have any, go ahead and state them.


Sure.  It's better than having two identical options in two different menus,
it pleases both users and purists, and it provides a clean way to kill a
broken process--something no other GUI offers.  (Like the macintosh without
a reset button, most GUIs assume applications never crash.)

>> >this needs to be discussed on the list: we have two options for keyboard
>> >shortcuts. which is better?
>> We should use both.  EVERYTHING should be keyboardable.  Anything without
a
>> default keyboard command should be keyboxable.
>
>after seeing other arguments about this on the list, i agree.


Then how can you support a system that takes the most commonly used
commands(new, open, etc.) and shoves them under a different menu heading
each time?  _D_ocument, _G_raphics, _S_ession...

>> >hai, so desu. and so i have successfully proven that quitting and saving
>> >are separate functions of the program, regardless of whether one has the
>> >ability to redirect you to the other.
>>
>> Uh, no...I was saying that if have saved, you don?t need to save again
>> before quitting.
>
>so i proved that the two are separate functions of the program,
>regardless of whether one has the ability to redirect you to the other.


Huh?  Exit = Savecheck then kill.  Kill and savecheck are two different
things.  Combine them, with savecheck coming first, and you have Exit.
Force quit doesn't care about saving.  If Exit doesn't work fast enough, the
app dies.  It's not Exit = Savecheck + Exit.   Exit = Savecheck + Kill.

>> If you HADN?T saved, quit should TRIGGER save checks.
>> That?s just it.  If you have unsaved files, quit should trigger SAVE
CHECKS.
>
>okay, so we agree. that one command invokes a second command in a
>separate category (category 2 in the proposition above) does not thereby
>move a category 1 command into category 2, because, as i've already
>proven, the category 1 command does not _always_ invoke the category 2
>command. to make that move to category 2 in some instances but not
>others would be inconsistent.


No.  I phrased it wrong.  The above is correct.

>> >> I will ask my test subjects this question: "If you press quit, and the
>> >> application has unsaved files in memory, should it ask you if it
should
>> save
>> >> them or should it destroy your work?" Oh boy I wonder what the
response
>> >> will be ;-)
>
>please quote the part of my proposal above which states "quit" should
>exit the application without doing save checks. then this argument will
>become relevant. i eagerly await your response.


The original response was to you saying Quit/Exit = Kill.  It was a
terminology error on your part, not mine.  YOU were the first person who
said Kill.

>> >look, the point is, we're splitting hairs with this one and you aren't
>> >looking at the general structure i'm proposing
>
>> You?re trying to pull quit out of file.
>
>based on the proposal above, you tell me where quit should go. tell me
>why. and remember to base your decision on the proposal above. oh, by
>the way, the proposal above should be used as the basis for your
>decision. did i mention you should use the proposal above in choosing
>where "quit" should reside? and you may want to refer to the proposal
>above while making your choice.


What part of "I disagree with your proposal" don't you understand?

>> I haven?t found a user who wants
>> quit gone
>
>soren howard found some good candidates:


So there are a few.  We'll get ripped on in the press, and a large enough
portion of the users out there will agree that we'll look like total idiots.

>> My little brother (seventh grade) and sister (fifth grade) were looking
>> over my shoulder yesterday when I was looking at the "GNOME-foot mock
>> screenshots" and both said "Hey cool.  What's the foot do?"  Had they
been
>> using the computer, they would have clicked it and immediately figured
out
>> that it was the way to quit the program.
>
>i received a personal email from two others who liked my proposal
>mockups, whom i will call "nwanua" and "greg" because those are their
>first names and i won't violate their privacy by giving their email
>addresses on the list.
>
>without doing a bit of research or testing but merely doing some
>reorganizing based on what i've observed from new users trying to figure
>out windows, macs, and ataris, and i got three positive responses. and
>the only person's approval or understanding i was seeking was yours. so,
>if you're trying to discourage me from pursuing my proposal with the
>sentence above, it failed. :)


Fair, I've found more users who don't agree...to quote another...

<Drk`Angel> I think you're looking for a way to leave your mark on an app,
and are therefore randomly changing standard UI elements for no good reason.

>> (I have found MANY users who want a standard location for
>> Preferences), I haven?t found a user who can?t find quit(I can find many
who
>> can?t find preferences), and I haven?t found a user who likes the idea of
>> having quit moved on them(different for preferences).  So I?m looking at
a
>> poorly justified, unneccesary, and unwanted ?improvement? in the
interface.
>> Like Chris said, customer is always right.
>
>fair enough. hopefully once we weed out all those other ideas and
>proposals that have cluttered the pureness of the proposal at the top of
>this email, we'll be able to judge it on its own basis, not on the basis
>of confusion or misunderstanding. ready to start again?


Like I said, there are other proposals out there.  Yours is an improvement.

>> I smell a Start Menu w/ everything under the sun in the first/second
level
>> menu.
>
>sniff out the proposal above and tell me what you smell then. i have a
>feeling it's going to be a scent you've not detected yet, no thanks to
>misunderstandings and mix-ups regarding the proposal above. as you can
>see, neither of the first two menus are _allowed_ to be used for
>"everything under the sun."


Like I said, I am unclear on the concept of the document menu being allowed
to modify settings that apply to everything only...I mean, is this a good
idea?  Do we want to sort by what things can modify or do we want to sort by
what things DO?  Think about this:  If you want to change the font of every
document open, it belongs in the menuprint.  If you want to change the font
of the present window, that entry is in the document.  And if you want to
change the font of a portion of the present window, I presume that's in
format.

So, if the app offers all three functionalities...

>> >i mentioned things like the number of columns because some basic word
>> >processors may offer this as a single, document-wide setting. adobe
>> >pagemaker, otoh, would _not_ put this setting in the document menu
>> >because you can set a different number of columns on each page. it's not
>> >a document-wide setting, therefore it shouldn't go into a document-based
>> >menu.
>> >
>> >too easy.
>>
>> So now users get a major inconsistency, no?  If the app supports
different
>> columns per page, it goes into the format menu.  If the app doesn?t
support
>> different columns per page, it goes into the ?document? menu.
>
>but now my proposal changes everything, doesn't it? see, now users will
>quit thinking of document creation on the computer's terms, and will
>think more along these lines: "you know... i want to put a third column
>here, but i don't want it to be on all the other pages, because it's
>only this one that gets a special sidebar. the menu choices i have for
>this are '[foot],' 'document,' and 'page.' hmm. bet it's 'page.'"


Wouldn't it be better just to have a format menu that lets you check a box
"I want this to apply to this page" v. "I want this to apply to the entire
document"?  I mean, you're talking about merging I/O with Format, with
Format getting global context when joined with the I/O'ers.  So the items
wouldn't even line up side to side.

>> Kaminsky?s Law #2.
>
>i hereby give you permission to stop quoting this in your emails, since
>nobody gives it any credibility anyway (no arguments have been given to
>support it). there, i just saved you a bunch of future typing. :)


Well, two pages of psychological perspective were typed out, did you miss
them?  I'd be happy to send them to you.  They were pretty good, and your
argument makes sense if you didn't read the psych basis.

>> Anything
>> that?s not related to an output device should go into some other menu, to
be
>> standardized at GC3 level by us.
>
>please quote the part of the proposal above that refers to commands
>dealing with input or output.


Gee I can't disagree with your proposal?

>> Any less causes inconsistency between apps with more functionality and
apps
>> with less...this discourages apps to upgrade functionality, since users
have
>> to learn new menu positions.
>
>are you sure? microsoft thinks giving the _user_ the ability to
>rearrange their menus is a _feature_, not a bug, and judging by recent
>discussion here, it would seem many other gnome-gui-listers agree.


Defaults?  By default, menus should be as similar as possible.

>besides, if a user starts using their computer with a basic
>understanding of the above proposal in mind, they'll know exactly where
>to go for any menu command, without having to hunt.
>
>> I can?t agree with the splitting hairs things.  This matters.
>
>okay, well, hopefully i've clarified my proposition so that hairs can be
>split in an informed, consistent manner. pick a command, then run it
>through the proposal above and tell me where it goes.


Clarified?  Changed.

>> Whether there should be a floppy drive or not in the iMac is
>> irrelevant...haven?t found a single user who agrees with the
>> decision...
>
>crud. i just emptied my "evangelist" mailbox (okay, i confess, i
>subscribe to evangelist. what can i say; i'm a well-rounded computer
>user who considers lots of opinions). i can't quote verbatim the
>messages from college is departments who have declared imac the computer
>of choice for dorm lans and lab use.
>
>i don't agree with the decision, either, for the record. but i'm not the
>imac's target audience, and i'm man enough to stand up and say so
>instead of condemning it for everyone on the basis of my own desires.
>(this is not intended to be an insult at your manhood, as i haven't seen
>you do this, but the argument _really_ wears thin after you hear it a
>hundred times, as i have.)


If you ever come to town, I will buy you dinner if the lack of a floppy
drive doesn't piss EVERYONE off at dorms across the country.  I'm serious.
This is really really really going to infuriate many techs to the point
where they will be forced to have a public cache of floppy drives cuz apple
was too cheap to build em in.

>> whether or not theoretically the new ?Microsoft Natural Keyboard?
>> layout is theoretically better, everybody is complaining LOUDLY about the
>> new arrow key layout...these are things that the opposition just gave up
on.
>>
>> I?ll give up on a point when the point is wrong.  That?s my job.
>
>i'll give up if i'm wrong too. however, i want to be proven wrong before
>i give up. :)


Cool.

>switching gears to another post:
>
>> > Okay. I've asked a number of other people. And results were not
>> >as encouraging. Here's a sample conversion:
>> >
>> > Me: How would you quit this application?
>> > LR: I'd click FILE.
>
>try it again, with a different person, and ask the person "why." if the
>person answers anything similar to, "because that's where i'm used to
>finding it," we can discard the results from that test. let me know if
>you still have any test subjects after doing so, and if so, post their
>dialogs instead.


So we should ignore the user's past experience, always?  Hurm?  ALWAYS?
Pretty gnomecentric, dontcha think?

>> > < I show the mockup with the tool tip >
>> > Me: Does that help at all?
>> > LR: What's GNOME?
>
>haven't seen that one, but the tool tip is a good idea. making the tool
>tip read "GNOME" was a bad idea. try it again with the test subjects
>you've culled out above, and this time make the tool tip read
>"application." let me know what you find.
>
>> Boy, my girlfriend is pissed off at y?all who want to get rid of the File
>> menu :-D  She doesn?t understand AT ALL...and yes, I explained.
>
>but you didn't understand yourself, so i'm not surprised. have her read
>the proposal at the top of this post, then explain where "quit" would go
>according to that proposal, and see if she's still pissed off.


Sure.  She will be.