frontend redesign :-)

[Eric Dean Tribble <tribble>]

Hugh and I and occasionally Roger beat about some alternative frontend
ideas:

The last and most immediate thing we talked about was getting rid of
bubbles (used to get to the document associated with a header).  After
long discussion, hugh half-jokingly suggested that we use the dots to
get to the documents (dots are used to create links to those
documents).  After a momentary doubletake, we realized that that could
make a lot of sense.  Clicking on a dot selects it (like a toggle).
You can select a bunch of dots (and deselect some of them).  When
you've selected a dot for every document you want to link to, go hit
the link button.  If you double click on any dot, regardless of its
selection state, it opens that document (notice that because they
toggle, a double click leaves dots in their original selection
state!).  This makes it very natural to select a few documents,
scroll,  double click to inspect as document, then select it, and
finally make the link.  A header without a document will have a cross
or something).  A few other obvious tuning are left as an excercise
for the reader :-)

A few final differences:  now the bubbles and triangles are in the
correct semantics location relative to their function:  triangles
follow the shape of the outline indents, and they are obviously
related to the outline objects.  The bubbles follow the flat document
structure;  they behave the same for every header, so they are all at
the same level.  It's easy to tell what you should double click to
open and close children.  Finally, note that approximately the same
thing happens when you click vs. double-click on the triangles vs
bubbles:  select the family/document vs. show the family/document.

Next: header only manipulation

What operations do we really care about doing to just headers?  Right
now the interface is complicated by the ability to manipulate headers
completely independently of their children.  By being specific, we can
perhaps generate a better interface that provides everything we
require. 

In particular, hugh pointed out that some outline editors strictly
maintain the existing tree structure while others prefer maintain the
order of headers.  As an example, consider promoting child 1 below:

parent
	child 1
	child 2

the result can either be 

parent
	child 2 
child 1

ala More, or:

parent
child 1
	child 2

More's policy always surprises and annoys me, and I think the
consensus is to do the second one.  

Are the other operations on headers only sufficiently rare that they
can just be command-selection of the header?

break:  just had another discussion for managing single header movement

If we have time to do the dotted-line representation of collapsed
children (ie ignore this :-), I have a good interface idea for
collapsing them manually (to get some children out of the way).

Assuming operations on headers without their children, we can have the
triangle simply select the header.  If the children are expanded, than
the triangle grows to two lines, and contains a smaller triangle on
the header line.  Selecting the small triangle selects just the
header.  Selecting an area in the larger triangle but outsaide the
smaller one selects the header and its children.  There are various
graphical representations that could work well for this.

A way of making comments easy is to have a button at the top of the
window that makes a comment document (a yellow sticky), links it to
the currently selected text (or the document if no text is selected)
and opens a quick window on it.  That makes it extremely light-weight.
Better still, have a small palette of buttons for different types of
comments (user selectable) very much like IconIt.

Next:  text selection

We discussed various ways of making a drag model for text selection.
There were various ideas thrown out, but here's the one that we seemed
to settle upon: After you make a selection, a floating button appears
near the end of your selection (below the seledction if you selected
downward, above if you selected up).  You can then click on the
floating button and drag it anywhere you want.  When dragging the
selection away, the original goes gray.  When you let up the button,
it gets deleted from the original sight and appears at the destination
sight.  To copy, just double click first.  The button reappears under
the mouse at the destination sight, so it's real easy to move it again
(or copy it).  (I like this better and better).

Part my goal for discussing text dragging was to find something that
generalizes to handling header and subtree manipulation.  I'm amused
by the result that the generalization leads approximately to what I
described above (and what we have now) - bullets for the appropriate
selections.  The only difference is the double-click behavior.  Can
anyone see a way to unify those?

dean