Re: RGSG - File Menu

[Frederick I Gleef <gleef capital net>]

My responses have been split to keep separate topics on separate threads.

On Sun, 2 Aug 1998, Dan Kaminsky wrote:
> Gleef wrote:
> >The discussion of the "File" menu needs to be a separate item (or items).
> >Personally, I think calling such a menu "File" should be a C3, perhaps a
> >C2, but not a C1.
> 
> 
> Users EXPECT File.  Do we gain enough by breaking this expectation?  File
> and Edit are needed.

Yes, we gain much by breaking this expectation.  If you follow the
archived thread on this subject, many good arguments for changing the
convention were given.  Here are just some of them:
  *  File really makes no sense for many of the things that are often put
     in the left-most menu (eg. Exit, Setup, Print).  Changing the name
     makes much more sense than moving these important items.
  *  File really makes no sense for many applications (eg. many games,
     system monitoring tools, communications programs, other non-document
     apps).
  *  People will easily adjust to the left-most menu being a different
     name, as long as it is consistant and they can stil exit from it.
Making the left-most menu consistently something other than "File"
addresses these points, "Program" and "Main" seem to be among the better
choices for something to call it. There still is some room for debate as
to whether the traditional File functions (New, Open, Close, Save) would
be better off in the left-most menu, or if programs that need them should
have a menu called "File".  I think the consensus leans towards having a
separate menu.

As for Edit, it only makes sense if you are actually editing something.
This would mostly be a subset of the set of File-based programs.  It is
certanly not needed.

 
> >Also, the items in the Prog menu are likely to be very high use, common
> >items.  I have never seen someone bother with the About window unless
> >they: A) Need information about the program to get help or figure out a
> >problem, or B) Are bored.  This usage would argue far more for being in
> >the Help menu than in prime real estate in Prog.
> 
> 
> They would only be high usage if they use the stuff from File, but if they
> use the stuff from File there's no need for File, but if there's no need for
> File then we remove File, and if we do that we piss users off for the only
> reason that "that's the right thing to do".
> 
> Anyway, I'm not really sure why File is all that "right thing do doish".
> Lets see, what kind of stuff goes into file...
> 
> New:  Make a new file
> Open:  Open a new file
> Close:  Close the presently open file
> Save:  Save the present contents into a new file.
These are all indisputably file-oriented commands.

> Print:  Print the presently open file
Print is appropriate for non-file programs (eg. Print a snapshot of my
game, print the webpage I am looking at, print the snapshot of the current
SMP usage graph, etc.)  If you think about it, Print is more print the
current view than print the file.

> Exit:  Quit dealing with all these files and get out of here.
You are taking an absurdly file-centric view here.  Exit exits out of the
program, regardless of presence, absence or relivence of files.

> Send:  Send the present file.
Send, fax or other communication commands probably share more in common
with Print than with Save.  It is certainly 

> Settings:  Change the settings of this specific file(any other usage is
> inappropriate).
Programs need an entry for "Change the settings of this application".
This entry needs to be in the left-most menu.  Some programs also need an
entry for "Change the entry of this specific file".  It is clear that
these need to be clearly differentiated.  There was much debate on what to
call each of them, with no resolution.


> Import:  Import the contents of another file into this file.
> Export:  Export the contents of this file into something another file can
> use.
Import and export are primarily translation commands, but translation
commands that require a File-centric mentality.  The function served by
these commands are better handled within the Open or Save command than as
separate items.  This will also allow easier piping, assuming an input
pipe would get tied into Open, and an output pipe would get tied into
Save.

 
> Am I missing something here?

You seem to be taking a very File-centric view of applications.  Take
another look at just which applications really NEED files.

-Gleef