Re: RGSG - File & Edit Menus

[Frederick I Gleef <gleef capital net>]

On Mon, 3 Aug 1998, Dan Kaminsky wrote:
> >> 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.
> 
> 
> It shouldn't matter to the user if the project is composed of one file or
> many.
> 
> One file is a file.
> Database records are files within an organizer.

Database records are by no means files, and it is highly misleading to
refer to them as such.  Let me give you a real world example.  At work, I
use a contract management package called Expedition.  The information is
managed on a project by project basis, with about two dozen different
types of information you can track about each project.  Since it is a
Windows application, it has a File menu.  Since it is project based, the
menu items are New Project, Open Project and Close Project.  Letting the
user deal with files is inappropriate, but it has to have a File menu,
because all Windows applications do.

To further underscore the separation between users and files, versions 4
and 5 both used the same concept of Projects.  However, in version 4, the
information for each project was stored in several files in a separate
directory for each project.  Version 5, however can store project
information in two ways, either in a single local database file (one file
containing all projects, and a second containing all the indexes to the
first), or on a networked Sybase database server.  All of these are the
same program, all of these are the same project.  In none of these cases
do you want the user to think about Files, they should be thinking about
Projects.


> CD Tracks are audio files encoded according to the Redbook standard.

Just because some software will allow a computer literate user to deal
with each track as if it were a file, does not make it a file.  If you
start referring to them that way, I guarantee you at least 90% of
the population will get confused.

CD Tracks are not stored in a filesystem.  CD Tracks are always referred
to as tracks.  Therefore, they are tracks, not 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.
> >
> >Computer software is moving away from the file-centric way of viewing
> >things.  The GNOME Style Guide should not perpetuate
> 
> 
> BS.

Please refrain from using vulgar language on a public list, even in
abbreviated form.  It is rude, inappropriate, and likely to invoke a
flamewar.


> I count this as "we're modern just because we want to sound cool"
> concepts--tell me when somebody comes up with a computer with no use for a
> file system.

Well, not that it is relevant to GNOME, but most embedded computer systems
have no use for a file system.

On the other hand, I never said that GNOME should not deal with the file
system.  I said that many applications do not deal with the file system,
and a "File" menu for such applications is inappropriate and awkward.  I
continued by pointing out that more and more applications are moving away
from a file-centric user interface, and we should support these programs,
rather than stifiling them by forcing them into an obsolete interface.


> By the way:  Accessing the file system over the network, or
> the disk drive in a raw manner because the application knows the file
> structure better than the file system does, don't count.

A networked database is a far cry from a networked filesystem.  They are
handled differently, and the concepts used in a traditional File menu
often do not apply.

Accessing raw partitions is not accessing files, as there is generally no
filesystem in a raw partition.  Data does not equal file.


> >
> >> 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.
> 
> Various types of projects print various types of information that have
> SOMETHING to do with the underlying files.  If there ARE no underlying
> files, some kind of information regarding what's gonna happen when files
> happen to show up gets printed.

Again referring to the example earlier, Expedition does a lot of printing.
At no point does it print out ANYTHING that has to do with the underlying
files.  When you are, for example, viewing a Change Order (an entity that
is concrete to the user, but as far as the program goes it is an abstract
item represented by one or more rows in over eight different tables), you
can print out the default Change Order form (by hitting control-P, or
selecting File->Print, a name that is very confusing in this context, as
you are not printing a file, you are printing a document for inclusion
in the file in the file cabinet next to your desk), you can print
alternate Change Order forms (by selecting Tools->Reports->Forms, and
picking the form from the list), you can print a report summarizing all
the Change Orders in the project (by selecting Tools->Reports->Reports,
and picking the one you want).  None of these have to do with any files,
merely records within a database (which incidentally is saved as a file,
but many similar system do not do so).


> >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?
> 
> I didn't know you could save game on a realtime world :-)
Check out Freebase, from Black Dog Games (I think it's contained within
one of their other games).  It is a live action role playing game which
allows you to save your game on a realtime world. :-)

Serously, though.  Ultima Online has a save game feature (it saves your
inventory, stats, and location, and removes you from the active map).  As
far as I know though, it is never saved as a file in a filesystem, locally
or remotely.  It is saved as records in a database, and perhaps backed up
on tape (another storage format which often has no files).  Calling such a
feature "Save File" would be very misleading (I'm honestly unsure what
they call it, I think it's save or save game, but I don't play so I don't
know for certain).  This is another example of how forcing a file-centric
view of things would be troublesome and awkward.



> And no, the user shoudn't care where their save file is being
> saved....locally, remotely, extraterrestrially....they just wanna save.

Yes, they don't care locally, remotely, in a file, in a potted plant.  So
why are you forcing it to be called a File when increasingly often it is
not?!?


 
> >Exit this game FILE is completely meaningless.  Exit means exit, whether
> >or not you are dealing with files.
> 
> Well, like I said, there are TWO file contexts that Exit fulfills:
> 
> 1)  All applications are files.  "Not Java apps...oops I was downloading all
> those class files.  Not web pages oops I downloaded a web page..."  So, if
> you exit an application, you are closing the file you opened to get into
> that application.

This is stretching the issue to the point of absurdity.  Just like users
don't care if their save game is a file or a potted plant, they don't care
if their application is a file or a tree.  Again, why are you asking that
the Style Guide force them to be referred to as Files, no matter how
appropriate or inappropriate.

 
> 2)  By extension, closing the file you used to get into the app closes all
> "child" files.  So you're kind of trashing a two level structure in a
> heirarchy--the file and all children of that file.

Huh?  Generally you get into an app not by using a file, but by typing
a command on a command line, selecting something from a menu, or
hitting a button.  I fail to understand your point here.



> >How often do you need edit in: xload,
> 
> Copy my extremely high load to a mail to the sysadmin and complain that my
> computer is broken.
> 
> > xanim,
> 
> Screenshot.
> 
> > xmp3,
> 
> Screenshot, track info, etc.
> 
> > or GUI front ends for
> >FTP clients,
> 
> All the time.  Copy the URL from netscape, paste it into the FTP client.
> 
> > CVS,
> 
> CVS doesn't grant ANY information about what it's doing?  Nothing to
> highlight, copy, and paste?
> 
> > PPP,
> 
> Uptime?
> 
> Screenshot?
> 
> Who are you to say that the user can't copy?

I am not saying that the user can't copy, I am saying that forcing an Edit
menu on these applications is absurd.  I would like to see Edit
functionality everywhere possible, I do not want to see Edit menus
everywhere I look.


> > 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).
> 
> Well, uhm, the thing is the application that's doing the editing isn't
> always the application that's doing the copying.

We currently have an application independant way of doing copying,
X-Windows' copy features.  These features require no menus to operate.  As
GNOME develops, I expect we will see that a more robust copying system
will develop.  I further expect that this too will require no menus to
operate.

Why require an Edit menu for features that do not exist yet, when they
likely will not need it.

Don't get me wrong, Edit menus are very useful when appropriate.  I am
just arguing against them being a requirement.

-Gleef