Huge Batch Reply: Sun

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

Sun:

>> As for defaults, default settings define how a new file is input into the
>> application. We're still in I/O land.
>
>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.

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

If I do Devil’s Advocate stuff, I’ll say so.  The worst I’ll do is say “So
what exactly belongs in the program menu” and watch people only be sure
about one thing...exit...

What do you think of that Force Quit v. Exit menu?

>this needs to be discussed on the list: we have two options for keyboard
>shortcuts. which is better?
>
>1. each menu has a keyboard shortcut, like windows and kde:
>alt-<firstletter> drops down that menu. the arrow keys and "enter" can
>be used to select the appropriate command.
>
>2. only the items _in_ the menus have shortcuts, at the programmer's
>discretion. using keyboard shortcuts won't drop down a menu, just
>execute the command, mac-style.
>
>and dan, the answer here is that if we choose to go with #1, then the
>first menu after tmfkap will have the keyboard shortcut
>alt-<firstletter>, whether it be "file," "session," or "document."
>
>if we use #2, then the title of the menu doesn't matter, because
>"ctrl-s" will always be save, "ctrl-a" will be save as, and "ctrl-w"
>will be close [window], regardless of what the menu is called, and
>regardless of whether we're saving documents, spreadsheets, graphics, or
>files.

We should use both.  EVERYTHING should be keyboardable.  Anything without a
default keyboard command should be keyboxable.

>> Why should I scream? You saved. Quitting didn't kill any unsaved
material.
>
>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.

If you HADN’T saved, quit should TRIGGER save checks.

>okay, this is my fault: i used the wrong term. i should have said quit
>_ends_ the process instead of _kills_ the process since that already
>means something else in linux-speak. the argument still stands. quit is
>separate from save, and does not inherently perform any i/o function. it
>is a command whose main job is to affect an entire process, not just a
>file.

That’s just it.  If you have unsaved files, quit should trigger SAVE CHECKS.
Period.  First level compliance issue in my head if an app doesn’t.  Third
level compliance if it does it right.

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

>> You know, this is odd, I just used Clarisworks a few hours ago, and page
>> margins were under Format->Documents. Different version?
>
>wow! you found one command, out of the example i gave, one command that
>works differently! congratulations! i bet you feel proud now; i bet you
>feel your whole viewpoint is justified.
>
>okay, too much sarcasm, i'm sorry.

Yeah you hit me with like three paragraphs of “nyeah nyeah clarisworks won
awards” and you happened to be wrong.  ;-)

>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. I haven’t found a user who wants
quit gone(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.

>but i'm not proposing an i/o-based menu, remember? i'm proposing a
>document-wide command menu. please try to separate these out and judge
>my proposal on its own basis, rather than trying to squeeze my proposal
>into the way it's done now.

I smell a Start Menu w/ everything under the sun in the first/second level
menu.

>printer configuration dialogs, in the claris works example i gave,
>indeed are document-wide settings and do belong in the document (or
>"file") menu.

Word for windows operates like you say.  Clarisworks and Word for Mac don’t.

I agree, doc wide settings belong here.

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

Kaminsky’s Law #2.

>but you _will_ understand my
>proposal on its own merits, rather than crammed into your own box or on
>the terms of what we have now. i've made it a personal goal. :)

I enjoy the discussion; it’s contributing directly to my white paper.

>> >depends. if options pertain to an entire file, then they belong in the
>> >file menu. if you're talking about options to be applied only to a
>> >selected portion of a document, then sure, "selection" or "options"
>> >would be a better place for them.
>>
>> Holy hogwash, the man and I agree. See, here's your problem sun. When you
>> gave your examples, you listed things that weren't really applicable to
the
>> entire document but rather to subsections.
>
>well, if this was unclear i apologize, but as i previously stated, some
>of these settings (like number of columns) _may_ be document-wide
>settings, depending on how it's designed.

I think I’m beginning to understand here...anything that’s output based,
say, print page margins, should go into the leftmost text menu.  Anything
that’s not related to an output device should go into some other menu, to be
standardized at GC3 level by us.

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.

>> I'm edgy on putting that kind of functionality in the prog menu, but I
>> understand why one might. In fact it's probably the most logical place,
but
>> that means separating preferences from options--not necessarily good.
>
>glad to see the concession made. if we concentrate more on structure and
>philosophy, the little hair-splitting issues will take care of
>themselves.

I can’t agree with the splitting hairs things.  This matters.

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