this got bounced... second try... pardon if it's a repeat

[sun <as387 yfn ysu edu>]

Dan Kaminsky wrote:

> >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.
> 
> Agreed, though I prefer Exit to Quit. Close (file), Close All (Files), and
> Exit (Application File and all children files).

under linux, we think of applications as processes, not files, and deal
with them separately.

on a macintosh, we think of application programs, desk accessories,
extensions, and documents, and deal with them separately.

on windows, we think of programs and files or documents, and deal with
them separately.

it's pretty universally accepted (at least to those i teach, and most of
the ones i've learned from) that a _file_ is for storing data and an
_application_ is for doing something _with_ that data. (except for the
obvious exceptions like system monitors and stuff that don't actually
deal with data stored in files, but we still think of applications as
being separate from data files).

> >okay. starting again. witness the basic menubar. (see the enclosed
> >"mockup.gif")
> 
> Couple comments:
> 
> So what happens to a project app?  The moment an app lets you conglomerate
> numerous files, does Open get shoved over to The Foot?

no; then the "file" menu disappears (because we no longer think of the
basic unit as a file) and a "project" menu reappears in its place,
containing the same sorts of entries: open, save, etc.

> Let me tell you *WHAT I THINK* a user is going to do as soon as they see
> this app.
> 1)  Where's the help?

irrelevant, since i didn't really take the help into account when i made
that mockup. i'm of the opinion that help should be in the menu bar
itself. you'll note that although it may be one click harder to find, it
_still_ makes logical sense right where it is. "where shall i look for
help with the program? hmm. maybe in the program menu. <click> ah'll be
damned. help with the program."

> 2)  Huh?  What happened to quit?  Why can't I get out of here by pressing
> quit?  Huh?

disagree. quit is still in the last choice in the menu on the left.

> 3)  [After finding Options]  Where are preferences?  Why aren't options near
> preferences?  Why do I ALWAYS have to look around so damn much?

again, irrelevant as the point of those mockups wasn't to show the
proper vocabulary or syntax or placement of that one command, but to
show you the basic menu structure. the
preferences/options/configuration/whatever for the whole application
_do_ belong in tmfkap, though. document defaults belong under "file."

> Quick note--the foot looks nice, and SHOULD be there, but shouldn't have
> those options.  Well, OK, it should have a "Quit Application" button just
> like the File menu--that's one piece of redundancy I'll accept.

"quit" doesn't belong under the file menu. look at the mockup... i took
it out on purpose, because quitting one file doesn't make logical sense.

> >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.
> 
> Because it's so hard to draw the line.  Listen to all the people talking
> about projects being on this magical plane above files.

again, if the application deals with projects instead of files, the menu
bar should reflect that. games will have a "game" menu instead of a
"file" menu, as many do now. the only difference, really, between what
i'm proposing is that i've renamed your catch-all "file" menu to
"tmfkap" and labeled it with a foot, then moved the non-application-wide
choices to menus where they're better suited: "save" to the "file" if
your program deals with files, "session" if your daw deals with
sessions, "document" if you're using a page-layout program, etc.

> Your mockups are
> quite helpful; thank you for doing them.  Unfortunately, they illustrate
> exactly what I thought they would:  Key settings are being hidden from the
> user.

on the contrary i've only rearranged a little. they're just as
discoverable as they were before, and will make more sense to new
computer users. you'll have to do a little relearning, as will the
hordes coming over from windows and mac, but it'll make more logical
sense. maybe some will even miss it when they have to go back to win or
mac.

in your testing, see if you can scrape up a few non-computer-users.
these are the ones i've taught for the last few years, and these are the
ones i've been keeping in mind most.

> >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).
> 
> Hurm.  Valid point.

_thank you_. i was getting a bit frustrated for a bit. :)

> Suppose an application *ONLY* allows copying.  What to
> do with Edit?  Well, Control C should always work, but we could also tack
> the GIMP solution--edit in the root menu--on as our standard Edit location,
> in addition to wherever it wanted to hang out on the menu bar itself.

> I accept that all apps MIGHT not need an edit menu *only* because for some
> apps it really *would* be a tremendous waste of space.  You have a point.
> 
> Maybe the second menu of any system should always contain the edit commands
> at the top?

i'm glad to see the concession made, and i think all the ideas you've
presented (root menu, ctrl-c, and top of the 2nd menu [or in my mockups,
3rd menu]) have arguable validity to them.
--
"They that can give up essential liberty to obtain a little temporary
safety
deserve neither liberty nor safety." --Benjamin Franklin