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 3:15 PM
Subject: Re: RGSG


>yes, but new users are not taught to think of applications as places
>where data is stored, nor are they taught to think of the term "file" as
>an executable binary involving user interaction. although semantically
>incorrect it may be, a "file" and an "application" are quite separate in
>a new user's mind. hell, i still make that differentiation, and i've
>been using computers for ages.


OK, so look at the file menu as I/O central for the application.  It's a way
to get files in and out.  Makes PERFECT sense.

>> "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?"
>
>if a user has a need to deal with individual files as the computer sees
>them, chances are the menu should retain the "file" menu. for instance,
>in my daw example: the "session" menu would contain all the normal
>choices: open, save, save as, close, etc. but the user wouldn't really
>have a need to go back into "file" mode, considering all the scraps of
>audio data would be kept together as one big project.

Let me get this straight, you're saying that the session menu should be
switchable back to the file context?  Huh?

>i just thought of a good way to sum this up: if both the user and the
>computer are knowledgeable of the same subject (in this instance,
>digital recording) and can speak the same language, using the same
>vocabulary to refer to the same concrete objects, why force them into a
>metaphor? it needlessly complicates the interface.


Because it's a CONSISTENT metaphor.  Why make programs harder and harder and
harder to learn?  File is file.

>> 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.
>
>hmm. not a bad idea.


Cool.  I like it the more I think about it.

>> Do some research, see if you get different results than I did.  I know
*I*
>> was surprised not to see Exit.
>
>there isn't anybody who lives in my building who isn't already
>accustomed to win95, so it doesn't matter what i show them on my linux
>box... it's wrong already, simply because it isn't win95. that's why i
>encouraged you to find some new computer users if possible.


So maybe we should presume GNOME isn't going to have access to pure new
users, for the most part.  Maybe we should presume whatever GNOME does is
gonna have to be sufficiently better than the present way.

>> 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.
>
>i don't understand what you're arguing here. is this supposed to
>convince me that quit belongs under the file menu?
>
>you're right, of course, in that quitting is a good way to close all
>documents. but to say it backwards ("to close all documents, quit.") is
>wrong, because there will be some cases when you want to open other
>documents instead.
>
>the argument works in one direction, but not the reverse.


I don't argue AGAINST Close All.  I'm just saying many users, *myself
included*, use quit as a good way to say "I'm done with all this stuff".

Quit is not a kill process, and I would scream bloody murder if it was.

>> 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?
>
>if a application is indepth enough to provide those features, they'll
>probably be found in a "font" or "paragraph" menu elsewhere on the
>menubar or something. "document" would be left for more generalized
>specifications: aspect, borders, page numbering, paper size, columns per
>page, etc.


See this, folks?  What was once a nice, semi-predictable menu(left most text
menu is where I can do all my input output stuff) now becomes a frothy huge
mess of "document?  betcha page numbering would be nice, and columns per
page, hell lets just mix the entire file and options menu, thank you
document!"  I phear this.

>> 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)?
>
>if a person pointed to a box in real life and told me that inside it was
>a graphics file, i would envision a file _folder_ with a _collection_ of
>artwork or graphic designs. same with "document file." neither are
>applicable in this case. what's an "office file?" wouldn't "document,"
>"spreadsheet," "database," "presentation," or "report" more accurately
>describe what each is? and "project file" is simply too ambiguous. i'm
>serious, you know: say what you mean, mean what you say. there are
>concrete terms available for all of these things, and no excuses for not
>using them.


It's obvious you didn't mean this at all.

You really want to mix the File menu and the Options menu.

Well, what do the rest of you think here in gnome-gui?  Good idea?  All I
was arguing for was modifying defaults for new files...not this.

>> Main is catch all.  Program is catch all.  File is VERY specific:  Input
>> Output Belongs Here.  (Note--document defaults are a form of input.)
>
>so is your "file->quit" command considered data input our output? ;)
><gotcha>


Output.  Output all file states to the hard drive and get the heck out.

>> 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.
>
>this i agree with, although sometimes i disagree with implementation
>suggestions offered on this list.


So what do you think of keyboxes, screenplays, and SDI's?

>> Hurm.  Cut/Copy/Paste could get shoved into the gnomeprint, worse comes
to
>> worse.
>
>i disagree. the only items that should go into tmfkap are commands which
>influence the whole application.


I'm beginning to agree.

>> 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.
>
>if you haven't noticed, i think we have this in common. :)


Hundreds of messages to respond to every day...