Re: RGSG

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: sun <as387@yfn.ysu.edu>
To: Dan Kaminsky <effugas@best.com>
Date: Monday, August 03, 1998 9:40 PM
Subject: Re: RGSG


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


Wh00t.

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


I completely disagree, but lets wait till you get there.

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

Document settings...fudgy thing, but things that apply to the ENTIRE
file(i.e. margins for page setup) do fit here, I guess.  I'd prefer to see
them in some kind of general settings menu though.  Really, page setup deals
with how a file is output to the printer.  Any more detail belongs
elsewhere.

As for defaults, default settings define how a new file is input into the
application.  We're still in I/O land.

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


And exactly what prevents you from putting "new session" inside of file...a
"metafile" is just another file, you know.  And that's ALL a project is,
just another metafile, just another file, just another piece of guidance for
I/O.

Anyway, it's redundant to have two menus, and leads to consistency problems
re: apps that allow you to have open multiple windows in the same context.

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


Well...

1)  Keyboarding.  Spoke about that earlier--keyboard changes for each app ->
harder to learn.
2)  Interpretation.  File has presumed contents after a while--the I/O stuff
just happens ALWAYS to be there.  What is a session?  Session management?
Doesn't that turn the computer off?  Not mocking--since eveyrthing can be
misinterpreted, best to limit the amount of change between applications to
that which is necessary.  "Ah, the app I understand has file open stuff up,
so I bet this new app also has file open stuff up...look!  I was right!"

Kaminsky's second law.  :-)

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


Oh, heck yeah it's a great idea for new users, but why not allow experts to
theme away any menu entitled help all the way into the gnomeprint?  This is
a programmatic issue...if it's easy to do, cool, but no big whoop if it's
not doable.  GO/G4 in my book.

(I really don't like "C4", obvious reasons.)

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


Uh, KDE does this to the extreme.  Just because we accept we've been handed
battle torn 95 veterans doesn't mean we should throw them back into
battle...just means we should understand where they're coming from and deal
with it.  THAT is the key goal of UI design, by the way.

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


Ditto.

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


I didn't say the reverse was true.  Opening a file doesn't mean I want to
close all others, but it DOES mean I want to open a file!

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


I'm with you so far.

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


Uh, ok, we have an app open with 0 files.  That I have 0 files open isn't a
bad thing...

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


You saved.

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


Why should I scream?  You saved.  Quitting didn't kill any unsaved material.

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


AND OPEN THE FILE THAT YOU BOTHERED TO SAVE.  Now, lets say you hit quit
BEFORE SAVING, and it KILLED THE PROCESS.  Guess what, if GIMP doesn't say
"heh, dude, you just spent ten hours working on this stuff and didn't save,
are you sure you aren't a putz", something is VERY wrong with GIMP.

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


No, the process exited gracefully.   It checked to make sure all work was
done, it was, and it left.  This is a different thing from a SIGKILL, which
says OUT NOW.

>i'm getting _very_ frustrated here, dan. i've taken you up as a "pet
>project"

woof woof

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


oops maybe we should read what our pet says first

Just ribbing you a little.  I've made mistakes like this myself, hopefully
you'll chill out the GIMP quit issue as quick as I did, say, chill on the
edit menu requirement.

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


I will ask my test subjects this question:  "If you press quit, and the
application has unsaved files in memory, should it ask you if it should save
them or should it destroy your work?"  Oh boy I wonder what the response
will be ;-)

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


You know, this is odd, I just used Clarisworks a few hours ago, and page
margins were under Format->Documents.  Different version?

However, I don't have a problem with printer settings, including page
margins, getting shoved into the file menu, because these are filewide
settings that modify printer output.  That sticks with the I/O theme of file
very nicely.

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


I agree.  I've been too sarcastic.  In an attempt to illustrate the severe
degree of error I was interpreting, I became rude.  I apologize.  As you can
see though from your own type, it's an easy trap to fall into.

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


Sorry, sometimes I hear something different from what you say.  I was wrong.
I misinterpreted you.  You really meant...

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


Holy hogwash, the man and I agree.  See, here's your problem sun.  When you
gave your examples, you listed things that weren't really applicable to the
entire document but rather to subsections.  I can accept document level page
margins because I print on letterhead at least once a month.  The other
stuff wasn't really applicable.  Oi.

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


Gee isn't that funny that's what word and photoshop and probably everything
else do, isn't it funny that I was saying we should copy the functionality
of word and photoshop and do exactly this...ugh, I HATE misunderstandings, I
could have spent all this time working on the style guide instead of arguing
about stuff WE AGREE ABOUT#@%#@$%#@  AIIIIIIIIIIIIIIIIIIIIIIIIIIII

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


This is something beyond screenplays, this is something like "active
tutorials"...they're quite nice, but I think they're a PAIN IN THE ASS to
create...I wouldn't be averse to something like this.  The point though is
that we have XLab functionality now, and screenplays are REALLY easy to
make--just do it.

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

I'm edgy on putting that kind of functionality in the prog menu, but I
understand why one might.  In fact it's probably the most logical place, but
that means separating preferences from options--not necessarily good.

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


I shove my head into the new users' all the time, why do you think I get so
pissed off at computers and computer interfaces; have you ever seen the mpg
of the dude who takes his keyboard and bats his monitor off the desk and
then goes ahead and kicks it?  I've been there, I know where he's coming
from.  It doesn't take much to piss off a user.


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