[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Response To Dean's FE Questions
- To: <us>
- Subject: Response To Dean's FE Questions
- From: Marc Stiegler <marcs>
- Date: Sun, 24 Sep 89 14:23:23 PDT
In response to dean's questions on characteristics of the frontend:
1. How does style information mesh with inclusion lists?
I haven't thought this through with much depth, but my first
reaction is as follows: Inclusion lists would share with basic
documents the same kind of character and paragraph formatting.
For paragraphs, the current plan is to support left margin, right
margin, single/double space, and tab settings on a ruler. I suppose
we should also have an "indentation per nesting" setting in the
inclusion list, that represents the size of the right-shift when
you start a new level of children (actually, I'm open to hard-wiring
the size of the right shift in Release 1.0).
When you click open the inclusion list into the flat view, the
rulers from the inclusion list become part of the context in
which the included documents are viewed, i.e., if the basic document
has no rulers, then it is viewed with the ruler found above its
headline. It should NOT work in the opposite direction, i.e.,
if there is a ruler in an included document, it should not modify
the representation of the headlines or documents following that
document. Thus the inclusion list retains control over the viewing
of the included documents within the context of that inclusion.
I am also open to the idea that all paragraph formatting should
be postponed until Release 1.1 (i.e., add during Beta if this
turns out to be the critical addition needed to be useful).
2. What does the bottom pane (for peeking at the other end of
a link) say
when an icon for more than one link (or sensor) is selected?
First off, the bottom pane doesn't quite peak at the other end
of the link--it simply gives an view of the link that is as wide
as the whole window. If you want to peak at the far end, hold
the mouse down on the link in the link pane.
I'm pretty neutral on bottom pane behavior with multiple selected
links. My first reaction is, it should show the first link in
the list that is already visible.
As an aside, new operations I'm considering proposing for the
bottom pane are:
A single click would cause the text pane to shift so that the
selected link is visible. With this you could use links as bookmarks:
scroll through the link list till you see the thing you wanted
to look at, single click the link, single click the bottom pane,
and see the local end of the link (rather than the remote end
of the link).
Double click on the link in the bottom panes opens a window on
the link itself and makes the link available for editing. The
link-edit window would have the from-to descriptor, the to-from
descriptor, the link type, and other goodies I'll talk about
later. As long as the link-edit window is open, it always is
updated to show whatever is in the active bottom pane.
3. How can we view links on links? For example, if you see a
link in the link-pane, how do you discover that the refutation
link has been refuted?
The flippant answer is, they load the link network into their
Decision Duel frontend and it all becomes intuitively obvious
:-). This is the real answer to some extent; there will be better
views of information in the future for spotting forests made
out of the trees.
But even with the InfoFactory, we have an answer that is better
than anything else I've ever heard of. If the user concludes he
needs an overview of the discussion, he can build a tree of refutations
as follows: 1)Turn on a filter that selects only refutation links
(he might have done this already anyway). 2) Request that the
link pane be converted into an inclusion list, with a link search
depth greater than one. He will get back a hierarchy of points
and counterpoints, which he can open as a flat document if he
wants to read complete threads in series.