Re: RGSG

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: sun <as387@yfn.ysu.edu>
To: Dan Kaminsky <effugas@best.com>; gnome-gui-list@gnome.org
<gnome-gui-list@gnome.org>
Date: Monday, August 03, 1998 12:31 PM
Subject: Re: RGSG


>>[Exit Application File and Close All Children Files]

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


Don't try to pull this exception out of nowhere :-)    Applications *do not*
possess information.  *FILES* possess information.  If an application shows
the user data, that's a file that exists in memory and is being continually
updated.  If I can conceptualize it being saved into a file, it's a file.

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


"What happened to the file menu?  Oh, ok, leftmost menu always contains that
stuff,  I'm recieving much more feedback from the interface now that I see
project instead of file...but where do I go if I just want to deal with a
single file?  I mean, before, File was all encompassing, but is there a way
to switch back to File mode from Project mode?"

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


Actually, I agree.  Much menu space could be recovered by placing help stuff
inside of the gnomeprint.  Unfortunately, this *will* confuse the *HECK* out
of users.  This is an expert level mod.

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


Do some research, see if you get different results than I did.  I know *I*
was surprised not to see Exit.

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


And I was telling you what a USER will respond with.  That's all.

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


Quitting an application is a means by which users say "I don't want to deal
with this data anymore."  Think about that.  The application is just a tool
to modify data.  If a user is quitting an application, they don't want to
modify that data in that manner anymore.

Follow the mind.

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


So Office would have a "Office" menu, LyX would have a "Document" menu, GIMP
would have a "Graphics" menu, etc. etc. etc.

Kaminsky's Second Law, once again..."Everything that is consistent between
applications should be consistently accessible between applications."

File is no catch all menu.  Document, eh?  So does that deal with everything
a document could have?  Do we put Spacing and Font and Tracking and Kerning
in the leftmost menu?  Or, did you really mean Document File?  And Graphics
File?  And Office File?  How about Project File?  Game File(since the game
menu usually changes preferences for the "new game", and loads existing
games)?

Main is catch all.  Program is catch all.  File is VERY specific:  Input
Output Belongs Here.  (Note--document defaults are a form of input.)

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


Well, IBM's research said that users inevitably scan from left to right, but
they didn't deal with icons so I can't really say.

I am *slightly* amenable to valid replacements for File, as long as they are
consistent between applications.  However, I've really NOT yet seen anything
that didn't just ask for "File" to be implied right after it, except for
Main, and if that's not a catchall what is?

I think alot about new users.  Keyboxs, screenplays, and self-documenting
interfaces in general are *all* about new users.  A user should become an
accidental expert.

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


Hurm.  Cut/Copy/Paste could get shoved into the gnomeprint, worse comes to
worse.  Copy itself makes a good deal of sense to belong there, because it's
something sometimes the application wouldn't have anything to do
with(copy->copy screenshot).

Whoa, I have an idea.  you can shrink a window down to its gnomeprint, and
that gnomeprint will contain the contents of the menuing system.  Or, the
gnomeprint would just pick up the contents of the Active Window.  (Note, I'm
saying both gnomeprints.  I somewhat like the idea of the root gnomeprint
and the window gnomeprint containing nearly identical contents.)

By the way, sun, I'll argue something to death if I feel I'm right, but the
moment it becomes clear that I'm not, I have no problem admitting it and
moving on.  You make a very valid point about low-space GNOME apps not
having *room* for an edit menu, so I accept the point.  I'm not going to
argue something unless I can clearly justify it.

That's how progress is made, no?  Don't screw your principles, but allow
change to occur when it's appropriate.