Frontend Surrender

[Marc Stiegler <marcs>]

I started to prepare a long reply to dean's reply to my reply 
to the alternate frontend design. You can find some of that material 
at the bottom of this message in draft form. Most people can 
skip it, but some of it is still relevant to frontend developers.

I stopped working on it when I came to another meta-observation. 
We can get to Beta more quickly if we have fewer capabilities. 
So any controversial capability should be postponed till Release 
1.1. "Postponed till Release 1.1" means, we shouldn't have it 
when we start Beta, but if during Beta it turns out to be compelling, 
we should add it then.

On these grounds I surrender: no parent-only operations for Beta. 
We access the document behind the headline by double clicking 
on the icon that replaces the checkbox/dot in the column to the 
left. This icon can be round or square (contained or referenced 
document), hollow or filled (the document is empty or filled), 
highlighted or unhighlighted (the document has been selected 
for running a link to it from another window).

By the way, there are other features that cropped up in this 
discussion which belong in Release 1.1 as well. To bring everyone 
up to date on things that were put into Release 1.1 on the PERT 
chart a while ago, there are 2 more that may sadden people. The 
sparse link sidebar, i.e., the farthest-left column in all the 
displays, is postponed; only the link pane is available when 
we start Beta. And mouse-based copy and move is also postponed; 
conventional copy/paste is all we'll have for the beginning of 
Beta.

Though I love all 3 of these capabilities (parent-only operations, 
sparse link sidebar, and mouse-based copy/move), we can build 
a product without them that is good enough to be wonderful.

I will build new documentation of the Release 1.0 system. My 
apologies for not switching into Release 1.0 discussion sooner.

The obsolete rough draft of my next series of counterpoints follows:
--------------------

1) as I now understand containment, we cannot just do contained 
documents. Containment is fully transitive--if there's an inclusion 
list of inclusion lists, a change to a document in a sublist 
is a version event for the entire collection of documents. I 
expect that many people will have, as one of their organization 
patterns, nested inclusion lists acting as directories for everything 
they create. Thus their entire information pool becomes a single 
document, if containment is all we have. I have a painful vision 
of people implementing reference model inclusion lists by hand--basic 
documents in which each line has a link to a document, and the 
link list in the basic document sort of supplies reference inclusion 
list behavior. I have an even more painful vision of me writing 
documentation to explain to people how to build inclusion lists 
by hand, so that they know how to do this because they have no 
better alternative...shudder!

Referenced document inclusion lists are adequate for many purposes; 
if we can only have one, it needs to be reference. Indeed, the 
only thing for which containment seems superior to me at this 
time is for the later stages of writing a collaborative document, 
when you want version control over the whole collection as an 
entity.

2) How often are operations in which you want to promote/demote 
items without effecting the children? I suspect it depends very 
much on individual style, and on particular activities. When 
writing code, you may never want to move the function header 
without moving the code lines which are its children. So programmers 
wouldn't care. People who use outliners to organize "to do" lists 
probably don't use it either.

People who write text and think top down probably don't need 
it either. Personally, I write bottom up--I create notes, and 
then notice that some of the notes are more closely related to 
each other than others. So I group them. Then I regroup them. 
I don't finish regrouping them until the document is complete. 
I have no a priori mechanism for predicting how the grouping 
will change. It is best thought of as Brownian motion until rather 
late in the development of the document. An interestingly egregious 
kind of document for repeated reorganization is the trip report, 
in which there are large numbers of weakly linked items, and 
I may try several totally different overall organizations before 
I have a satisfactory flow. 

I cannot help believing that I am not unusual in my style and 
behavior. I suspect that most people who share my style simply 
don't use existing outliners. Outliners that insist on outlining 
are too clumsy. It is easier to cut and paste collections of 
paragraphs despite the clumsiness of collections of paragraphs. 
This is the particular reason why writing off single-line operations 
scares me. Clearly, most people who use outliners find it good 
enough most of the time. I really don't think we should implement 
this just for a single Marc Stiegler. But how many people are 
there who cut and paste in Macwrite because outliners are just 
"too rigid", where they don't themselves even clearly understand 
what is rigid about them?

Mindwrite does basic promotion of a child in-place. It also makes 
it "easy" to select the children (actually easier than anything 
I've seen anyone here suggest). I like it better than any other 
outliner I've seen. And when I move the parent, carrying the 
unwanted children, and then have to select all the children and 
carry them back to where I knew they went but now I've lost the 
location, I still think, "thanks for nothing, Mindwrite."

When I built a Hypercard stack to write large documents, I implemented 
ONLY single-line operations, without family operations. For various 
reasons I couldn't implement both, and I found single-line operations 
more useful than family operations.

The closest thing to a "frequency counter" for parent-only operation 
that I have from my personal experience is this: the vast majority 
of the times when I do a multiple headline selection, what I 
am selecting is ALL THE CHILDREN OF A PARENT. In general, if 
we had parent-only operation, you could use the parent as a handle 
for manipulating the children: grab the parent with family, move 
it to where the children should go, release the family, and move 
the parent alone.

PS I have a few ideas for paired icons that merge visually into 
a single icon. Irrelevant for the moment, of course.
------------------

--marcs