Re: tmfkap, File, &c

[Tom Vogt <tom lemuria org>]

Samuel Solon <ssolon@usa.net> wrote:
> 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.
this is true.
however, we have argued that users once used to something won't see it as a
problem anymore, no matter how bad it actually is. so be don't solve a
problem of the user, we do solve a problem (inconsistency) of the interface.

added value: new computer users will grasp the concepts and thus understand
the interface much faster.


> 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.
a valid argument.

only counterpoint: it might be in the interest of gnome to be different, as
long as this different is also better.


> 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.
true and valid.

we have tried to counter this by putting a button/icon there instead of a
menu. a few (very few) tests have shown that this MIGHT solve the problem.
at this point - as far as I understand it - we are waiting for some mockup
application to show to testees to find out more.


> 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.
might be true. we'll have to do some research to find this out. I fear that
you're right, though.


> 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?).
true again.

what do you think about themeable menus? the basic idea is that there is a
gnome-wide (i.e. per user) option to set the menu names. one option might be
a "File" menu that looks different depending on what exactly "File" means in
each app, one might leave "File" constant, and another one might make it
star trek like or whatever the user likes.


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

however, if we can come up with something that's consistent to the extend
that a USER notices the structure, it would reduce the learning curve a lot,
don't you think?


> And the advantages on the other side are?
yet to be determined.
how about we really mock up something in the way proposed and then send it
around to give it some real-life testing? I'm pretty sure it would give us a
whole new array of arguments.


-- 
Those who do not understand Unix are condemned to reinvent it, poorly.
		-- Henry Spencer