Response To Dean's FE Questions

[Marc Stiegler <marcs>]

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 
refutation
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.

--marcs