Re: RGSG

[sun <as387 yfn ysu edu>]

Dan Kaminsky wrote:

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

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.

> "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. if an audio
engineer decides that one drum riff should have gone into a project he
was working the night before, he can use "import sample" and "export
sample" to move that one riff from project to project, but there's no
need to make the audio engineer think like a computer ("file" simply
doesn't fit the studio metaphor) when it's too easy for the computer to
think on his terms.

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.

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

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

i'm basing my opinions on what i know of new users from experience
teaching them. all past experiences; i'm having a hard time testing new
and current stuff.

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

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

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

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

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

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

> 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. :)
--
"They that can give up essential liberty to obtain a little temporary
safety
deserve neither liberty nor safety." --Benjamin Franklin