Mockups

[sun <as387 yfn ysu edu>]

i sent this in response to something on the list earlier today, but i'm
not sure if the attachments made it through the listserver intact. i
don't think so. anyway, here's the letter and the attachments are now on
the web at http://www.sonetech.com/~bry/mockup.gif,
http://www.sonetech.com/~bry/mockup2.gif, and
http://www.sonetech.com/~bry/mockup3.gif

Dan Kaminsky wrote:

> Well, we can't have file->close in one menu and application->quit in
> another, if only because microsoft screwed up so much and made "close" refer
> to "close window", though they were thinking the user would think ALL IE4
> windows would close if exit was selected.

i thought we agreed we weren't going to let past mistakes of microsoft
(or kde or anybody else) dictate what would and wouldn't go into the
style guide, that we were going to borrow the best from all of these and
do what's intuitive in spite of prior mistakes, etc. etc. etc.?

i'm not sure how else to word this, maybe somebody else a little more
articulate can help me out:

closing all the files in an application is _not_ the same as quitting
the application. you _can_ have an application (a process) running
without having any documents or files open by that application. this is
a pretty basic difference here; we shouldn't have to do any convincing
that these two menu commands should be kept _separate_. "close" and
"quit" very clearly mean very different things.

gosh, why am i having such a hard time with this? i've taught a lot of
people how to use computers... i've never run into this one before.

> So, since we establish we can't really have both an app menu and a file
> menu, we have to pick.

this is, in fact, _exactly_ what i've been talking about all along, and
the fact that you think we can't tells me i haven't been doing my job.

okay. starting again. witness the basic menubar. (see the enclosed
"mockup.gif")

the first menu, which i have called the "application menu," which has
previously been called the "prog menu" and which shall heretofore be
known by me as "the menu formerly known as prog" (we love you, tom) or
"tmfkap" is labeled with a foot icon. the jury is still out on this one
it seems; i happen to like the foot icon, many do not. here it is in
full color for the first time; now let's get some feedback on it.

anyway. the purpose of this menu is to contain choices which pertain to
the _entire_ application, not just individual documents or parts of the
contents of the application. witness the enclosed "mockup2.gif".

the purpose of your dear "file" menu (see the enclosed "mockup3.gif",
which follows tmfkap, is _only_ to deal with individual files,
documents, whatever, within the application. it _shall not_ contain
global choices which affect the whole application, such as "quit."

do i need to explain the difference between "tmfkap" and "file" again? i
fear i cannot do so more clearly than the enclosed pictures.

> Application->Open...  does this open a new
> application?  Or a new file?  Application->Save...  does this save the app's
> state, or the state of a file?  Application->Import...   Does this import
> another application?  Or a file inside.  Yes, I agree, application->quit
> makes sense, though you're still closing all files.  But, then, most users I
> see nowadays want to click the X in the corner to deal with it--in essence,
> we have an application *bar* nowadays.

as you can see by the enclosed mockups, "open" and "save" don't belong
in tmfkap, for the very reason you named. similarly, "quit" doesn't
belong in "file" either. i still don't understand why i'm having such a
hard time with this.

> Any app with text requires cut, copy, and paste.  Any app with plain old
> graphics requires at LEAST copy(copy the clock app and it gives you either a
> graphic of the time or the time spelled out).  It's really inapprpriate to
> change the edit standard here.

so you've said, and so i've agreed with. now disregard all programs with
editable text. it's late, i'm getting frustrated, and i refuse to draw a
picture of an application, say a log monitor program, with "copy" in the
"entry" menu along with "monitor" and "highlight," because there aren't
any other sensible choices for an "edit" menu in such a program. (you
can't paste or delete log entries from a log monitor program).

i've already agreed with you on applications that deal with variable
content. please don't provoke controversy where there is none. please
look where i'm pointing, instead, and concede that sometimes it may be a
bad idea to require an "edit" menu, because not all apps are designed
the same.
--
"They that can give up essential liberty to obtain a little temporary
safety
deserve neither liberty nor safety." --Benjamin Franklin