Comments On Dean's FE Proposal

[Marc Stiegler <marcs>]

Yessirree, it would really be nice to have our frontend--any 
version of our frontend--with which to critique proposals for 
the frontend.

In response to dean's recent message on fe redesign, I have the 
following comments:

1) Double clicking on the dot to go to the document would work. 
However, I question whether it will buy us as much improvement 
as one might hope because the bubble in the current design has 
2 other functions. One of those other functions, dragging the 
headline, is discussed below. The other function, which is newer 
than any of the documentation, is to make visible the difference 
between REFERENCED documents and CONTAINED documents. In the 
new draft-in-production, the bubble
is either square or circular to denote containment or reference. 
For more discussion of this, please talk to me or read the new 
draft of the documentation as soon as I get it done (probably 
tomorrow).

It is possible that we should not even have both contained and 
referenced documents in Release 1.0; it is possible we should 
only have referenced documents. However, I would like to have 
a clear upgrade path to contained documents, since we will surely 
want the distinction either in a later release or in a power-user's 
version (InfoFactory Professional?). The bottom line on this 
is that we will eventually need an icon the size of the original 
bubble icon, somewhere on the screen. What we eliminate by moving 
the open-document operation to the dot is NOT the bubble, but 
rather the dot, which was pretty inoffensive anyway. 

We also "fix" it so that, when you single-click to put a check-mark 
in the icon spot, you wipe out the indicator of whether the document 
is contained or referenced--a minor inelegance. You also lose 
the indicator of whether the document is empty or not--another 
minor inelegance. But a lot of little inelegances add up to a 
considerable inelegance.

This is the BEST case; we still have to deal with other parent-only 
operations besides open-document.

2) Having put the open-document command into the dot (which is 
also sometimes a "+" even in the simplest representation), we 
now faced the question, how to manipulate a parent headline without 
its children? Of course, the first legitimate question to ask 
is, do you really need the ability to manipulate the parent without 
the children? I must confess, my personal feelings about this 
are so strong that they qualify as "religious" feelings. So, 
to get the religion out of the way, let me say, YES YES YES WE 
MUST HAVE PARENT-ONLY OPERATIONS (whew, I feel better now :-). 


So, do we really need them for anyone but me?

On the opposing side, we can observe that no existing outliners 
have parent-only operations. So one could argue that even without 
them, our inclusion lists will be as powerful as the best of 
existing outliners. To state it the way I feel about it, our 
inclusion lists would be as powerful as the best of the hopelessly 
inadequate existing outliners.

Another reasonable observation is that parent-only operations 
are not frequent. However, when you want one, you want it really 
bad. Many many people out there really hate outliners (roger 
is our best local example). How much of that hatred is caused 
by the following sensation? On those rare occasions when you 
DO want a parent-only operation, it provokes surprisingly fierce 
anger, because you can SEE what you want to do, it's RIGHT THERE 
staring at you, but YOU CAN'T DO IT. Instead of just grabbing 
the parent and yanking it to the right place, you must first 
select all the children, drag them up to the adjacent parent, 
and THEN move the sucker. Needless to say, people make frequent 
errors--they grab the parent, then remember that the children 
are coming along for the ride. So they then reposition the parent, 
and THEN follow the "legal" sequence. This still happens to me, 
anyway.

Outliners earned their reputation  for being too rigid with just 
such clever behavior. I am desperate to make our system more 
flexible than basic outliners, for this among other reasons. 
The outline metaphor should add capabilities, not constraints.

3) Assuming we will do single-header movement, how do we represent 
it?

a) Use a command-selection to get the parent alone. This brings 
up a philosophical point: I do not believe that command-selection 
works under hardly any circumstances. It is possible that More 
HAS such a command selection to manipulate the header, I wouldn't 
know, because I gave up trying to use the sucker without trying 
this invisible possibility. Making it a command selection is 
marginally different from not implementing it.

b) Expand the parent's triangle icon when there are children, 
making 2 regions, one region for the family handle, one region 
for the parent-only handle. I like some characteristics of the 
concept--the parent-only distinction only appears when there 
is a family there to drive a distinction. I am uncomfortable 
with it in some way, but I can't articulate the issue at the 
moment; I'll need to think on it. Anyway, using this approach, 
combining it with the earlier discussion, our net reduction in 
visual complexity with the new approach is that we got rid of 
the column of small dots and now have occasional oversize icons 
here and there in the view.

4) Looking at the new approach from a meta-view, it appears to 
me that the main focus of this current proposal is a desperate 
effort to reduce the triangle-plus-bubble next to the headline 
to one icon, no matter what the consequences are for the rest 
of the screen. This pair of icons obviously bothers everyone 
else more than it bothers me. In my own mind's eye, the triangle 
and bubble DO merge together, only to be resolved when needed. 


I am really inclined to believe the best solution is to find 
a pair of icons that will seem to blend together in normal human 
vision much as this pair blends together in mine. I will put 
together a couple of proposals.

5) I like the idea of putting a "margin note" button in the control 
panel. Actually, in Mac-land, this is a canonical example of 
something you would just put in a menu on the menu bar, but I 
want it to be really easy to create documents this way, so I'm 
in favor of putting it in the control panel.

There should be a choice in the menu bar for attaching a new, 
blank inclusion list; I don't think this needs to be another 
button in the control panel. Eventually, we will want to make 
this system extensible so that you can use the same mechanism 
to create, for example, a new Autocad document as a "margin illustration". 
It occurs to me we could do this with a popup menu in the control 
panel, so that you could create either a margin note or a margin 
inclusion list directly; I'm not necessarily in favor of this, 
just observing the alternative: it is not quite as light-weight, 
though more flexible.

6) The drag button on a selection is closely akin to an idea 
hugh and I have discussed before. I would favor putting a button 
at each end of the selection rather than just at the stopping 
point, in case the guy wants to scroll around a bit after selecting. 
Using a double click to copy rather than move is a great improvement 
on the mechanism I had in mind for this operation earlier. If 
the user hits the Delete key after double clicking, it is the 
COPY that is deleted, not the original.

--marcs