Re: tmfkap, File, &c

[Tom Vogt <tom lemuria org>]

Samuel Solon <ssolon@usa.net> wrote:
> >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.

indeed, I do believe that most if not all people have at least some amount
of this ability.

you say that I might be wrong. maybe you are right and a lot of people don't
have - or don't have enough of this kind of thinking. how can we find out?



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

I tend to believe that we have. we have the premise that by sacrificing
traditional concepts and replacing them by consistent new concepts, the user
might be disoriented for a short time, but will grasp the new concept
quickly because of it's consistency and end up using a better interface,
increasing his productivity.


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

I do see a gain in productivity. maybe the user doesn't even have to
consciously grasp the concept, but once he got used to find everything of
all-inclusive scope in one menu, everything working on the whole document in
a second and so on, he won't be searching around for new or unusual menu
items any more, making him faster and reducing frustration.



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

I'd limit this to the top scopes. I think every app will be hierarchically
(?:) ) structured for at least the first two entries - application scope
and document scope.


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

yes.

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

I do not think so, because a report works on the contents of an account,
while loading, saving, etc. works on the account as a whole. this is the
same difference in scope as between the ex-"File" menu that works on the
contents of the app compared to tmfkap that works on the app as a whole.

however, there will certainly be cases where the distinctions will begin to
blur. that is when we have to just declare "let it be thus" and make
ex-"File" the leftmost menu, period.

I still believe that we will be better off than with the current uis.


> 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.
:)))
we agree that this is a technically valid, but contextual nonsense argument?


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

first of all, the proposal as I understood it didn't want to see any edit
functions in "Accounts" to start with. "Accounts" would instead just replace
"File" with the contents being that of "File". thus you would have menu
items like "Accounts->Open" or "Accounts->Save As..." - which makes perfect
sense to me.



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

agree with you there. looks like we don't agree on the way to that goal,
though.


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

you have a point there, basically the same thing that we said against dan's
file-centric argumentation only applied a level higher. ugh, evil beast. :)

as "File" is probably equally bad from a task-oriented view, I guess you are
aiming at something completely different here? care to elaborate?

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