Comments On Dean's FE Proposal

[Eric Dean Tribble <tribble>]

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. 
This distinction could easily be made.  If we imagine the document
icons on the right, then a triangle/arrow takes you to a refeenced
document, whereas a bubble takes you to a contained document.

   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.

Thinking in terms of exemplars, if we can only do one, it should be
contained documents.  Thus, our frontend demonstrates a feature that
none else can do, and one that we want our developers to understand.

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

We need to discuss containment vs. reference.  I would expect
'professional' users to be far more likely than 'amateurs' to use the
reference model, so again, the baseline should be containment.

   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. 

You're almost right.  The main thing we did was disassociate the icon
from the outline structure.  In retrospect, that was the primary thing
that bothered me about it.

   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 was one of the exercises for the reader.  Forget checkmarks.  We
just represent selection in the obvious way of reversing the icon (or
outlining it, or...).

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

I came up with some other ways of dealing with this.  I still don't
know what you want this for.  Until I do, I can't integrate it nicely
with the rest of the design.

   On the opposing side, we can observe that no existing outliners 
   have parent-only operations. 

Being merely as good as everything else in the world would be a big
comedown :-)

   Another reasonable observation is that parent-only operations 
   are not frequent. However, when you want one, you want it really 
   bad. 

This won't be true if we have the right set of other operations.

   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.

How often are these operations in which you want to promote/demote
items without changes the veritcal location of any of their
children/siblings?  If that's not sufficient, then we still have an
advatnage by being able to easily select sets of children.  You move
the entire family, then select all the children (a quick click and
drag) and move them back to the parent or sibling with which you wan
them associated.  This has the advantage that we don't make policy
decisions about wehre the orphaned shildren should be placed.

   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.

Good philosophy.  I would still like a specific example.

   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.

I disagree.  You have a particularly strong aversion to shift keys.
If the documentation is adequate, then it should be easy to find.  If
we use such extra selection bits sparingly, they should be easy to
find.  I'm not advocating such practices, but for infrequent or
specialixzaed operations, they don't seem so abhorrent.

   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.

There are many measures of complexity.  A major source of complexity
in the first design was having the triangle and the bubble in the same
location.  I could never keep straight which was for which, and there
were no layout hints with which to figure it out.  The rearrangement
saves us a lot more than a single icon.  With the above proposal, the
shape remains the same , but it's real clear what selecting each icon
should do (if it's not obvious, then it's certainly mnemonic).

   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. 

Not quite.  The set of distinction made visible by the two icons are
not quite right.  

   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.

I'll believe it when I see it.  I don't think they exist in general.

5) for making documents, we could just have a menu with items that
make links of some type to documents of some type.  It might be
possible to make this extensible externally.