tmfkap, File, &c

[Samuel Solon <ssolon usa net>]

After actually reading "all" the messages (and turning off auto-check for
mail so I haven't received any new ones) it seems that Dan is the only one
arguing against tmfkap as leftmost and not renaming "File".

Since I'm against both, I might as well weigh in here.

I have lots of reasons and undoubtedly this message will become far too
long and rambling. I'll go into some of the more detailed reasons later but
two major issues keep coming to the front of my mind.

1. The tmfkap doesn't seem to "solve" a "problem". Users don't seem to be
confused about how to "Quit" applications on any computers I'm familiar with.

2. Most importantly, Gnome isn't the entire world. There already exist
applications that users will want to use with Gnome which won't have the
tmfkap menu -- and might not have it anytime soon. Adding tmfkap will force
an application to be Gnome specific.

I would expect both of these to be serious issues in the world of Unix
where each user has their own "sacred cow" and flame wars start over emacs
vs vi.

Adding an additional menu to the left of the "i/o oriented" menu is
jarring. I have had occasion to run Gnu emacs on Windows 95 and it adds a
menu to the left of the File menu (Buffers?) and it always throws me off.
It's not a huge problem in emacs since I usually use key-strokes but I find
it disconcerting. tmfkap will cause a huge disparity between Gnome apps and
non-Gnome apps for what appears (to me) to be little benefit in return.

Making tmfkap an icon makes the problem a little less evident since the
icon can easily be ignored as a menu (the zero th menu syndrome mentioned)
but that also makes it harder to find a way out of the program.

------------------------------------------------------------------------

On the question of renaming the "File" menu to be something else I have
very strong feelings. Fundamentally it seems silly to change one of the few
constants in the computer industry but there are other reasons that it
seems wrong.

Many have used the example of an audio recording program used by a
recording engineer to show that the user doesn't think in terms of "files"
and so the menu should present a more application oriented word.

This might be true if the recording program was the only application ever
used by that person. If that's true and the machine is dedicated to one
function, it doesn't really matter what the interface looks like. The
recording engineer will learn to use that tool because it is part of their
job. It is more likely that the same machine is used for email, word
processing, and all the normal things computers get used for and such a
person might not have any preconceived notions of what a piece of mail
should be called (a letter, postcard, email?).

A common viewpoint here seems to be that the "File" naming the menu is a
noun. If I remember my English, "file" is a perfectly good verb. As a
matter of fact, my dictionary lists the various verb forms of "file" before
getting around to the noun. Our recording engineer probably *files* his
audio tapes in a tape library. "file" might imply to people the permanent
storage of information and that is exactly what most of the entries on the
"File" menu do (including printing, which files to paper).

Without getting into the "Exit/Quit" as i/o operation controversy, putting
the "way to get out" of a program on the first menu makes a great deal of
sense, no matter what that menu is.

There is another important aspect of "file", this time as a noun. While
most people on this list understand the difference between memory, memory,
memory, memory, memory, memory & , that is: main store, disk storage in the
file system, devices in the file system, pseudo devices in the file system
(/proc), network files, executable programs mapped from a disk file, main
store pages swapped out, L1 cache, L2 cache and whatever else I've
forgotten, the concept is still confusing to many users.

It is not uncommon to hear people wonder why they've run out of memory when
they've just added an 11GB disk drive.

It is important to emphasize the difference between their information
stored in a (relatively) non-volatile form such as a file on disk and the
transient version they're working on in memory. The "File" menu is a
constant among most applications where the tools that control this
difference as located. It helps to emphasize that "Save" on the "File" menu
saves their information in some more durable form. What "Save" in a
"Session" menu would do is questionable. A recording application might
indeed have other "Save" menu items to commit various level of changes but
the "File" version of "Save" should have the clear meaning of "save things
so that I can get this stuff back the next time I run this program".

Finally, there is simply the question of consistency. The game "Freecell"
in Windows 95 uses "Game" as the first menu. Whenever I run that program
and mouse  up to the first menu there's always a little pause because the
menu just looks wrong. Maybe a small thing but it's the small things that
make an interface.

Most of the arguments I've heard in favor of tmfkap seem to be based on
"aesthetic purity". IMHO it is mostly engineers who are concerned with
aesthetic purity. We (engineers) pride ourselves on being precise while the
general population doesn't worry about it. They still "dial" touch-tone
phones (at least here in the US).

I'd love to see some real (alleged) benefits of adding a menu containing
infrequently used commands to the easiest to access place in the menubar.

Not adding tmfkap and making the first menu "File" has the advantages of:

1 - Consistent with majority of applications expanding the range of
potential Gnome applications.

2 - Consistent with many years of practice on a wide variety of platforms.

3 - Reinforces the difference in storage methods (in memory vs on disk).

4 - Self consistent. Every Gnome app will have a "File" menu containing
storage manipulation commands and a way to get out.

And the advantages on the other side are?

Sam Solon
ssolon@usa.net