Re: tmfkap, File, &c

["Dan \"Effugas\" Kaminsky" <effugas best com>]

-----Original Message-----
From: Samuel Solon <ssolon@usa.net>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Wednesday, August 05, 1998 4:43 PM
Subject: tmfkap, File, &c


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


Do the words "thank god, I was beginning to feel all alone on this" mean
anything to you?

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


I think Tom would pay good money to have me be this clear.

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


Yup.

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


Watch out, sun doesn't want to insult your intelligence by mentioning how
stupid it is to compare GNOME to other HCI's.

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


Thing is, I think it's only us interface geeks that could even think of
removing File, everybody else is happy with it...contrast that with the
Windows Start Menu...

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


Well, the menuprint would be placed there by the system, maybe in a separate
process, to facilitate, in part, user friendly forcequit.

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


Quit needs to be in both places.  It just does.

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


yay!

>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.
>
>[audio engineers use lots of apps, and interface should stay consistent]

Preach on!

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


I didn't have much luck arguing with these guys on a theoretical level.

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


2000 and 2001 are both considered the "first years", so might as well put
forms of exit on both.

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


TELL ME ABOUT IT.

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

AMEN.

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

"Phone Toner"  "Phone Sounder"  who cares if nobody knows what the app does,
IT'S CORRECT!

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


1- Menu is small enough not to take over sort order
2- Consistent with macintosh interface
3- Looks better than "next entry after last text", and is more accessable
than right justified.

But yeah, your above arguments ARE VERY TRUE.  THANK YOU!

>Sam Solon
>ssolon@usa.net
>
>
>--
>         To unsubscribe: mail gnome-gui-list-request@gnome.org with
>                       "unsubscribe" as the Subject.
>
>