Re: RGSG



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: Sunday, August 02, 1998 6:43 PM
> Subject: Re: RGSG
> 
> >Dan Kaminsky wrote:
> >
> >> Users EXPECT File.  Do we gain enough by breaking this expectation?  File
> >> and Edit are needed.
> >
> >consider digital audio workstations that do audio-sample sequencing.
> >most of the ones i've used "think" in terms of "projects" or "sessions."
> >there's no sense in having a "file" menu, considering a five-minute
> >"session" could be comprised of hundreds of smaller sample files, plus
> >non-destructive edits files, plus mixer automation files, plus a
> >sequencing information file...
> 
> A project is a bunch of files.
> 
> New Project gives you a place to put a bunch of files.
> Open Project lets you open up an organizer for a bunch of files.
> Close Project lets you close an organizer of files.
> Print Project lets you print out the contents of an organization of files.
> etc. etc. etc.
> 
> What do you want, a files menu?  I mean, even when you hit open, you can
> choose from multiple files.  But that's too much pain for not enough gain.

there should be a "session" menu instead of a "file" menu in this case.
in the "session" menu will be "import" and "export" to deal with
individual sample files or sequencing files as needed, but since the
project is dealt with by _groups_ of files on the whole, the "file" menu
doesn't make sense.

i'm just pointing this out not because i like splitting hairs, but
because i don't think it's right to mandate a "file" menu. in fact, even
for applications which _do_ deal with single files, i'd rather see a
"picture," "document," or "sound" menu in place of the "file" menu as
necessary. the person (sorry, deleted the post, can't credit properly)
who pointed out that object-oriented content creation should displace
the antiquated filesystem metaphor was right.

> File|Settings is bad--unless you're changing the settings on the active
> file.  But that's it.
> 
> >i think a program should have a "file" menu _only_ if it deals with
> >individual files as its basic form of storage. most games, for instance,
> >would not have a "file" menu either. many don't already.
> 
> Open save game FILE...clear high score FILE...exit this game FILE...

no, you don't exit game files. you exit game applications. it's possible
to close a file without closing an application, and this is an entirely
separate operation and must be kept distinctly different.

btw, for the rest of your examples, i'd say "game->open" and
"scores->clear" are more concise, and create less confusion for new
users who haven't learned about storing information in file systems and
couldn't (and shouldn't be forced to) care less.

> >as far as "edit," same story: only include it if there's a real use for
> >it. if there's no content to copy or paste, your "edit" menu is pretty
> >worthless. don't put a down button next to an elevator in the basement.
> 
> Edit can be worthless, but only in games.  mIRC in Windows has no edit
> menu...ooh, hope nobody wants to copy and paste...

one more time, for posterity's sake: only include it if there's a real
use for it. if there's no content to copy or paste, your "edit" menu is
pretty worthless. don't mandate its use either.
--
"They that can give up essential liberty to obtain a little temporary
safety
deserve neither liberty nor safety." --Benjamin Franklin



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]