Re: RGSG

[sun <as387 yfn ysu edu>]

Dan Kaminsky wrote:
> 
> -----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.

okay, this is good. "file" contains file-level input and output. agreed.

quit is not a file i/o option though. quit deals with the process, not
the file. i will prove this later in this email.

"file" doesn't necessarily deal _only_ with inputs/outputs, either.
document settings would fit under "file" but don't deal with input or
output.

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

no. i'm saying the "session" menu should take over the job of the file
menu, since the user and the application no longer think of the data as
individual files but on a larger scale.

example:
+-------+
|File   |
+-------+
|New    |  <- means "create new file"
|Open   |  <- means "open a pre-existing file"
|Save   |  <- means "save current data into a file"
|etc... |
+-------+

+-------+
|Session|
+-------+
|New    |  <- means "create new session"
|Open   |  <- means "open a pre-existing session"
|Save   |  <- means "save current data into a session"
|etc... |
+-------+

the difference, of course, is that the former would make no sense for an
audio engineer. he doesn't deal in "files" and his daily work doesn't
break down well into individual units like that, since he works with
_collections_ of units (or "sessions") instead. the latter would be
better suited to this type of work. same math to calculate distance,
different unit of measure.

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

please present an argument that proves using concrete terms makes the
interface harder to learn.

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

i don't think we're going to get it past the rest of the group, though.
yes, it makes logical sense, but it _is_ a good idea to present help to
new users immediately, on-screen, without requiring any mouse clicks or
keystrokes to be discovered.

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

oh, well, in that case, forget i posted anything to this list. let's all
go use kde instead. :P

> Maybe we should presume whatever GNOME does is
> gonna have to be sufficiently better than the present way.

if i didn't believe that was its goal, i wouldn't be here. :)


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

okay, that's fair, and i can see why you'd say that. but again, the
reverse still simply isn't true. "i'm done with all this stuff" does not
immediately mean "kill the program," because you might want to use other
stuff under the program after you're "done with all _this_ stuff."

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

start screaming, buddy, because here's where i prove you wrong.
scientific proof you can use on your own desktop. ready?

1. run the gimp.
2. create a new picture.
3. scribble some stuff in the picture.
4. go into a console or xterm and type "ps aux | grep gimp"

see? gimp is a currently running process.

5. right-click in your newly scribbled picture to bring up a menu.
6. choose "save" from the "file" menu, give your picture a name, and
save it to your hard drive.
7. right-click in the picture again, and this time choose "close" from
the file menu.
8. go to a console or xterm and type "ps aux | grep gimp"

we still have a process running, right? okay, we just closed a data
file, said "i'm done with all this stuff," and got rid of it. however,
the process is still running. this is a good thing, because guess what:

9. woops, you changed your mind and want to make some changes to that
picture. or you want to start a new picture. or you want to open a
different picture. doesn't matter. click on "file" in the toolbar and
choose "new" or "open" as appropriate.
10. select your document (if you chose "open") and make some changes to
it.
11. right-click in the picture and select "save."
12. go into a console or xterm and type "ps aux | grep gimp" and make a
note of the output.
13. go to the "file" menu and choose "quit."
14. go into a console or xterm and type "ps aux | grep gimp"

how did the output from step 14 differ from the output from step 12?

what's the matter, dan? i can't hear your bloody murder yet.

15. woops, you changed your mind again. go to the file menu...

oh, wait. you can't. because you killed the process.

i'm getting _very_ frustrated here, dan. i've taken you up as a "pet
project" for the day because although everybody else who has opined on
the subject can see what i'm getting at, you seem to stand alone.
however, i'm quite sure you're perfectly capable of logical, rational
thought so i'm sure you'll get it somewhere.

run a few of your test subjects through this procedure. ask _them_ what
the hell quit does. when you've compiled your scientific results, get
back to me.

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

if you're trying to make me mad, i hope you enjoy whatever weird
satisfaction you get from succeeding. i have in front of me right now a
macintosh laptop running claris works, famed for its simple and
intuitive user interface. in the "file" menu i picked "page setup" and
am presented with a dialog box with paper sizes, orientations, and other
document-wide settings.

see this, folks? what was once a nice, highly-acclaimed program in use
by thousands of schools and colleges, still winning awards with its user
interface, has hereby been declared a frothy huge mess in which, hell,
we just mixed the entire file and options menu, thank you file!

fear this, dan, fear this while you're screaming bloody murder, because
these people have made more money and won more awards with this software
than you have with any of yours.

cut out the bandstanding, please. it looks really unprofessional.

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

it's obvious you didn't take this as i meant it. try not to put words in
my mouth. thanks.

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

depends. if options pertain to an entire file, then they belong in the
file menu. if you're talking about options to be applied only to a
selected portion of a document, then sure, "selection" or "options"
would be a better place for them.

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

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

it _better_ not. if i finish a word processing document and successfully
save and print it, then accidentally hit the keyboard with my elbow and
put lots of gibberish in the middle of my document, and if i say "oh
well, i was done anyway" and choose "quit," if that program outputs the
file state to the hard drive without asking my permission first and gets
the heck out without allowing me to undo the damage, i will trash that
word processor in a heartbeat.

"quit" should give you the _option_ to output, but should then behave as
"save" or "save as," and never have output become part of the "quit"
command itself.

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

the one i'd like to comment on here is screenplays. it's a wonderful
idea, but i rather like "the mac way" myself: rather than doing it for
you, or showing you and making you repeat, it puts a big red magic
marker circle around the next step (a menu choice or button, for
instance) and makes you do it yourself. doing it yourself is the best
way imo, but let me disclaim: i'm sure a lot of research has been done
in learning techniques, so my opinion and experience in this isn't going
to be as authoritative as my experience with gui's.

> >i disagree. the only items that should go into tmfkap are commands which
> >influence the whole application.
> 
> I'm beginning to agree.

in an earlier post you asked for examples of what else should go in
tmfkap. i'd propose the "about" box, the "configure" dialog (or whatever
we decide to call it... i like "configure" because it's a verb but don't
feel strongly), and "help" if it's safe to remove this one from the menu
bar (although the jury's still out on that one). i'd also leave it open
for future enhancements like macro recording, application-hiding, and
whatever other application-wide commands an author chooses to include.

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

let me comment once more on this: please keep it professional, and try
to make sure all your assertions are somehow backed with a fair reason
that has taken many alternatives into account. for the record, i've been
using a wide variety of graphic user interfaces since their invention
(okay, i didn't go to parc, but i did use the first macs, ataris, and
amigas) and have been whining about some of the conventions i've
complained about in this list for years. i've also done extensive
instruction on the more common gui platforms. i'm not jumping into this
thing anew and spouting fresh ideas off the top of my head. i think a
little effort on your part to understand why i say the things i say will
lead you to understand what i'm proposing from a new user's point of
view. give it a shot; that's all i ask.

thanks.
--
"They that can give up essential liberty to obtain a little temporary
safety
deserve neither liberty nor safety." --Benjamin Franklin