Re: tmfkap, File, &c

[Samuel Solon <ssolon usa net>]

At 08:01 AM 8/6/98 +0200, Tom Vogt wrote:
>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.
>
>

Hmmm -- you are making the assumption that *most* people in the world can
discover the logical concepts underlying the organizational phenomenon,
abstract it to a set of principles and then reapply those principles to the
next, similar, concrete example of the phenomenon they encounter.

I don't know if most people can do this, but my experience is that many
people don't.

This is (IMHO) one of the characteristics of engineers and other technical
people who might just presume that everyone else thinks the same way that
they do.

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

This disturbs me most of all. In order to conduct tests you need to have
premise that can be proven true or false. You seem to have no such premise
to test.

You seem to indicate that users will grasp the left to right, most
inclusive to least inclusive menu ordering, but it isn't clear that this
will yield any improvement in either the user experience or their
productivity.

Doing this definately implies that *all* applications are hierarchally
(never could spell that word) structured. I dont' know if this is true, but
it is certainly not obvious and places constraints on the application
developer that are not based on any sound reasoning, much less
experimentation.

Thinking, for a moment, of a personal accounting application such as
"Quicken". There would be an "Accounts" menu as the leftmost text menu
which would provide a way to open accounts, close them, import, export, etc.

Report generation might be applied to a single account, in which case the
"Reports" menu should follow the "Accounts" menu. A report can also be
generated from multiple accounts so in a hierarchy "Reports" can be before
"Accounts".

Since reports always act on accounts (in this artificial example) it can
also be part of the "Accounts" menu, probably as a very large submenu.

Actually, everything in the program really deals with accounts, so we end
up with the possibility (mentioned by someone else many hundreds of
messages ago) that everything could be shoved into the "Accounts" menu.

That we are dealing with accounts should be obvious since we're within an
acounting program. Having a menu labeled "Accounts" seems redundant. So we
can move things out of the "Accounts" menu into their own menus. Reporting
on accounts goes into "Reports". Editing accounts goes into "Edit".
Loading, saving, importing, exporting and other filing operations go into
"File". What happened to "Accounts"?

I would guess most menu systems are task oriented and most users are task
oriented also. They are using a particular application to accomplish a
particular task and the application should help them accomplish tasks.

I feel like I've rambled here but I now believe that you want to enforce a
particular abstract organization on applications; a hierarchal organization
based on the hierarchy of data/structures/information.

I'm not sure this is a good idea or even a workable concept.

Sam Solon
ssolon@usa.net