Re: RGSG - File & Edit Menus

[Frederick I Gleef <gleef capital net>]

On Sun, 2 Aug 1998, 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.

A Project is a Project.  It should not matter to the user whether the
Project is made up of a bunch of files, one file, some database records in
a database server, CD tracks, or a combination.

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

Computer software is moving away from the file-centric way of viewing
things.  The GNOME Style Guide should not perpetuate 


> Print Project lets you print out the contents of an organization of files.
> etc. etc. etc.

Project-based systems almost never have this menu item.  You can print out
various aspects of the project, in various views.  These aspects usually
have nothing to do with the files of the project.  A Print Project item
would only be of use to the developer, not the user.


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

Most games complicated enough to have save games, lately have a load game
and save game item on the main menu.  They explicitly separate the user
from the concept of files by only letting you access them by game, not by
file.  It matters not to the user whether the game is saved in a file, as
a portion of a file, or on their game server.  Do you honestly think that
Ultima Online is saving your current status in a file on your computer
when Save Game is hit?

Exit this game FILE is completely meaningless.  Exit means exit, whether
or not you are dealing with files.


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

How often do you need edit in: xload, xanim, xmp3, or GUI front ends for
FTP clients, CVS, PPP, etc.  An Edit menu makes sense in only two types of
applications: applications which need something more advanced than the
standard drag and drop functionality (eg. image manupulation software),
and applications where editing is so important that new users need to be
reminded of it (eg. gedit).

-Gleef