[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: <us>
- Subject: Frontend Surrender
- From: Marc Stiegler <marcs>
- Date: Thu, 21 Sep 89 15:35:50 PDT
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
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
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
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.