menu bar proposal (attn: dan k)

[sun <as387 yfn ysu edu>]

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:

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:

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.

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.

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

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

Dan "Effugas" Kaminsky wrote:

> >point is, i don't want to limit the file menu to i/o because sometimes
> >there _will_ be some things that need to be changed there that don't
> >specifically deal with i/o. we need to quit splitting hairs on issues
> >like whether or not * is i/o-related because that's not what should
> >dictate its placement: the _scope_ of the command is. application-wide?
> >stick it in tmfkap. document-wide? stick it in "document" (or "file" or
> >whatever).
> 
> There?s very little that?s definitely app wide, and there?s very little that
> doesn?t fit into the document menu in a document editing application...font?
> margins?  Minimum tab lengths?  EVERYTHING is relevant to the menu that
> describes the application.

read it again, sam:

"...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 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. :)

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

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

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

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

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

> >then run them through my scientific procedure and ask them if they would
> >classify "quit" as a process-level command or a file-level command.
> >
> >again, get back with me once you have compiled your results.

> If I ask them the first question before asking them the second question, I?
> ll get significantly different answers than if I just ask the second
> question.
> So how should I do it?   Does it say anything that the user will probably
> change his opinion once told about a condition in which he could lose all of
> his work?

simply don't ask the first question, because again, it's irrelevant.

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

> I haven?t found a user who wants
> quit gone

soren howard found some good candidates:

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

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

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

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

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

> I think I?m beginning to understand here...

i quite think you're _not_:

> anything that?s output based,
> say, print page margins, should go into the leftmost text menu.

please quote the part of the proposal above that refers to commands
dealing with input or output.

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

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

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.

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

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

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.

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

--
"They that can give up essential liberty to obtain a little temporary
safety
deserve neither liberty nor safety." --Benjamin Franklin