Re: RGSG

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: Tom Vogt <tom@lemuria.org>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Monday, August 03, 1998 10:21 PM
Subject: Re: RGSG


>Dan Kaminsky <effugas@best.com> wrote:
>> 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.
>
>from the perspectiv of a know-nothing user,  you  are talking voodoo up
>there.
>which  is the best reason I can think of to NOT  do it your way.


Hang on, you're the one who is separating file level stuff from app level
stuff, what's the big whoop from separating apps from inherent files?  Don't
apps make NEW info and OPEN old info and save MORE new info and print info
and basically do work on info?

Someone in here said that's how they already think, and I went ahead and
trashed a whole line of reasoning of mine because they were quite
persuasive.

>
>> Quitting an application is a means by which users say "I don't want to
deal
>> with this data anymore."
>or "gotta go catch that train".
>
>fact is,  when a user exits a program, he can have a dozen reasons, only
>part of them to be found anywhere in  a file-centric pov.


"I don't want to deal with this anymore"

For whatever reason, they're done with the data.

Now, if it happens to be that they didn't save the data, the app better make
SURE that the new files shouldn't be saved.

>> 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."
>
>"accessible" is the keyword here. it doesn't say "consistently NAMED", does
>it?
>besides, arguing with "laws" one created oneself is not exactly very
>convincing.:)
>(vogt's third law: the leftmost menu shalt be called "Prog") :)


Self-made laws are fair if they are logical and can be argued.  However,
just because I made the law doesn't mean I'm always right.  Fact is, I get
my justification from the law from psychology, which means any defenses of
it must be psychological.  That being said, psychologically the name of an
object links to prior experienced context of that said object.  If the last
ten rocks that you have experienced have smacked you in the head, you're
going to fear rocks.  However, if the last ten times you had sex were pretty
good, you're going to gravitate towards sex.  Similarly, naming has a strong
impact on the usability of a new application.  While psychologically a
standardized location(i.e. all file stuff goes in the leftmost-for-english
text menu entry) can be somewhat effective, the doubt experience from a user
wondering if their new application isn't making sense or is going to ask
them to do something they weren't able("but I don't want to program"
"session management?  where's file?") will be serious and unpredictable.  By
the same token, by naming all menu items of nearly identical meaning(though
not identical contents) the same, the memory segments that deal with
understanding computer functionality are accessed at a greater rate with a
far larger amount of certitude and far less doubt due to the central nature
of language in human communication--and lets not forget, we are attempting
to make the computer communicate with the user.  One might argue that
additional context is provided to the brain by specializing the "I/O"
category with a name such as "Document"(for word processor I/O),
"Graphic"(for graphical I/O), and "Session"(for session-based I/O).  In
addition to causing unknown contextual side effects previously mentioned(a
user who had a bad experience with session management could fear entering
the session menu, not realizing s/he already knows how to manage the menu),
the productivity increase from telling a person in a sound app that the I/O
command set happens to refer to sound is minimal--redundancy can aid in
perception, but the gain here does *not* outweigh the substantial cost in
user confusion.

The previous was an attempt to corrolate Kaminsky's Second Law of UI Design
with the statement that nearly identical menu entires should have identical
names.  It should be noted that this law does not prescribe the phrase
"File" be used, though the strong amount of usage of the File phrase over
the past 15+ years of GUI design makes it among the best of candidates to
fill the role of placeholder for "Input/Output Menu Subsystem".

>
>> 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?
>
>you've not been following. the original proposal, made more than two weeks
>ago, was to put an ADDITIONAL menu in front of file, but KEEP file. I can't
>remember that this proposal has changed in this point since then.


YOU haven't been following the discussion.  There are a number of people
here who say File is *bad*, and that its functionality should either be
absorbed into Program or replaced with something like "Document" or "Sound"
or whatnot.  Hell, I was the first one to pipe up with "Gnomeprint makes
great branding, we should have it!"

>
>> 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.
>
>you're thinking about them, but you're not thinking LIKE them.


I think the above Psychological Rant gives me the right to say I can think
like anybody I damn well please.

Note--agan, I *was* wrong about users thinking apps are files.  I changed my
opinion when I was called on that.  If you think I have a tangible error in
my psychological evaluation of all classes of users, I'm open to hear it.