frontend suggestions

[Eric Dean Tribble <tribble>]

Abstract:  some frontend improvements suggested after yesterday's
meeting.  I attributed the suggestions to the people from whom I heard
them.  Some of these ideas have been around for awhile, so thanks to
everyone. 

1) the endset view should display each end in a list.  Next to each
end are two buttons (check boxes?), one for from-set, one for to-set.
Clicking on the button adds/removes the given end from the appropriate
endset of the link being created.  -Roger's idea

2) improve on Drexler's '- 0 +' close boxes.  clicking on the '+'
close box not only endorses the document, it also puts a Recorder on
the document, and it starts funding the document at some default
level.  I think it is a reasonable default to track additions to
anything you advocate.  I don't know quite where the Recorder ought to
feed into, however.  Since you are interested in it, it's not
inappropriate to help keep it around.  - I suggested adding sensors,
MarkM added funding.

Holding the button down on the '+' could bring up a menu of
alternative supportive reactions: endorse and comment, fund but don't
endorse, endorse but don't fund, etc.  We probably will make this a
very simple list that always endorses.  I'm not sure what the
corresponding actions should be for '-'.  Now, when you edit something
that you want people to read, close it with the '+' box.  It's
straightforward to note that filtering will only show documents that
have been annotated with a '+' by the user you're filtering for.

The close boxes can have different options depending on what you've
done.  Wihtout endorsement, it might show a thumbs up.  with
endorsement it might just show '+' or '!' to indicate that you can
increase your support (ie funding) to keep the thing around.  The '-'
would then translate to removing the endorsement and removing funding.

3) make any recorder take an alarm.  The separate alarm document is
*really* confusing.  The backend's generality seems simpler to me (I'm
biased, to be sure!).  For a specific alternative: Any Recorder
document has a knob at the top which says how urgently to notify the
user.  Three possible settings are 'just record', 'soft alert',
'scream'.  The soft alert brings up the window (beneath the active
window) if it's closed, and flashes it in the backgraound if it's
open.  I know this can be simplified further.  When I log in, all the
'screams' go off, and all the soft alarms get presented in a single
view.  The single view could easily be an inclusion list of all the
soft alarm documents....  Properly done, this simplifies the link-pane
quite a bit.  - several people

4) As a simplification, we can have a perfectly good system with just
soft alarms. - MarkM

5) Make the list pane into a document. A concrete example:
inclusionList headers can be either simple textDocs or LinkDocs.  the
frontend displays linkDocs as in each line of the linkPane.  The
backfollow operation just makes a Recorder and presents it to the
user.  Now all the normal update operations will update the 'linkpane'
when a new link gets made.  To make a recorder, just keep the linkPane
document around as a named document!  This usnifies the two backfollow
operation, and makes sensor creation easy.  (I'm not sure how it
interacts with the '+' close box for xcreating sensors...).  This also
let's us explicitly manipulate links as objects. - MarkM (and me I
think)

6) Combine the inclusionList view and the flatView into a single view
somwhat like MarkM's drawing.  I would really like to blur the
distinction between referenced/contained documents and headers.
-MarkM

dean