I'll try to put my replies in context.
In message <39A58950.EBCC5ABF@eng.sun.com>, Eric Armstrong writes:
>
>Topics covered:
> * Doug presented a diagram with intermediaries
> translating plain text into XML and then again
> into HTML for display on a browser.
Plain text is inaccurate. These are RFC822 messages some of which are
MIME encoded.
> * The idea is that it will siphon off standard
> email messages to build a better email archive.
"Siphon off" seems a little strange. It will archive email messages
in a form that allows fine-grained addressability and control of views
so that email discussions can take place "in context". This is an
absolute prerequisite for integrating email conversations into any
shared knowledge base.
And to suggest that we are planning just another archive is also
misleading. The archive will be live and view-adjustable. Hopefully
the user-interface provided by the web-interface will be sufficient to
allow input into the discussions directly.
>Concerns:
>
> * The concerns I had then would still seem to be
> valid now -- it could take a lot of time to
> build accomodations for legacy email systems and
> the like -- time that could probably be put to
> better use if the system were defined using newer
> technologies.
> eg: Identifying the part of a message that
> a user is replying to will be tricky,
> and will consume many man-hours.
> But that's trivial if the mail system is
> XML-based. We could be taking XML's advantages
> and running with them.
A lot of Email is already HTML-based, which is halfway to XML.
Translating RFC822 email into an addressable form (which is only one
of the pieces of the proposed first step) is something that is going
to need to be done no matter what (for the incorporation of existing
archives if nothing else). I agree that some of this will be
difficult, but not all of it will be necessary, and getting a usable
system off the ground will not be difficult at all.
> * The email user will experience no benefit from using
> the system until they consult the archive. It remains
> to be seen whether that constitutes sufficient benefit
> to make it something that developers want to use.
Not entirely clear. We have a step in the system for adding
information pertaining to the archive to the email that is returned to
users. Other information could be placed in there.
> * On a process level, at SRI we started out doing use cases,
> then stopped that and considered defining interfaces,
> then stopped that and started defining an architecture.
> We have now stopped that and have started this new
> process, where the system architecure comes predefined,
> rather than being built up in response to the needs
> demonstrated by use cases and analysis. Basically, I
> don't "trust" the design, and we've changed methodological
> choices too often to trust the process.
I disagree with the characterization. We started off with use cases
for a system that we had neither the resources nor immediate ability
to build. We then stepped back and examined our own situation and
observed that email was one of our primary means of discussion outside
the meetings. So we scaled back our scope to something tractable (and
attractive to some of our potential sponsors), enhancing email
communication.
> * The plan is for emails to contain links into the archive. Those
> links would contain view-control commands, ala Augment. This
> notion raises several concerns:
> --This is fundamentally Rod Welch's system, where every message
> contains a link to the real information. Instead of having
> the redundant text in my inbox, I'm going to have a link
> to the text the message is replying to. Yuck. I'd rather
> have the redundant text, thank you. I don't think I'd bother
> using this system very long.
Here you have clearly misunderstood, or maybe Doug has too.
One of the requirements that came out of our use cases and some
sociological insights was the need to deliver tools that enabled
incremental buy-in. Users are married to their tools and typically
only migrate to tools that are perceived to give some benefit. The
plan here was to allow participation from even purely textual email
front-ends but encourage buy-in to the web-based interfaces by
allowing for one-click access to the full discussion via a
web-browser. The last thing I want in my email is a 10 page email
message which includes an entire discussion I've been participating in
with two lines of new information embedded somewhere near the bottom.
> --The proposal puts Augment's view-control commands into a
> very central position, very early on. I would be more
> comfortable with a gui-centric approach in stage 1 that
> added view-control commands later. Then, I would feel sure
> that the system was usable without requiring the user to
> understand a complicated mnemonic language. (That's the
> kind of the thing that the developers of a system love,
> because its so powerful. Power users eventually come to
> love it, too. But normal users hate it, and can't be
> bothered to use it. If the system depends on using it, the
> system is doomed.)
Doug puts Augment's view control commands into a central position.
It is an open question how view-control can easily be handled over
such a web-based infrastructure. A URL-based scheme leaves the job of
changing views to the server which will necessarily be very high
latency. Access to a DOM via JavaScript on the client-side makes for
a much more immediate response. It remains to be seen what we can
actually do.
That said, the system should ultimately reward commitment by providing
power-user facilities. Again, it remains to be seen what those should
look like. Hopefully, there will be enough flexibility in the system
that we can accomodate a the range of commitment from naive,
occasional user to full-time power user.
> --What I want, fundamentally, is an email system that delivers
> a reply to me "in context" so that it appears as part of
> the original message. I would also like to be able to register
> the threads I'm interested in -- always seeing threads that are
> really new, but not being bothered with additional messages
> to old threads that I've already chosen to ignore. The current
> proposal won't give me anything like that, but will instead
> clutter my inbox with link-containing messages. Reconstructing
> an argument from a series of messages like that will be
> next to impossible. That will force me to consult the archive.
You are definitely wrong on a couple of points here. The current
proposal moves gradually in the directions you describe. If we use
existing email reflector programs, then we have a limited ability to
"take control" of the delivery process. That is why we stopped at the
point of adding a link from the message into the archive. Eventually,
email will only be one of many means that users will have to insert
documents (or document fragments) into an OHS.
I'm absolutely in agreement that one should be able to "unsubscribe"
from threads. I haven't brought it up again recently because it is
something that seems undoable until we have replaced that preexisting
email reflector, which was not in our immediate term plans.
> --Unlike many users, apparently, I am not a big fan of archives.
> In fact, I hate them. I have my own archives -- copies of the
> messages I care about. I search them when I need to. So a
> system in which the archive is the most (and possibly only)
> useful part of the system holds little interest for me.
And in this context we seem to differ considerably. If I know that
email is being archived elsewhere, I delete almost all messages that
I'm not replying to directly. As a medium, email has such a unitary,
unconnected character that it seems best suited for notifications and
not discussions. Web-based email archives, especially if
view-adjustable and eventually "live" and integrated with web-based
"chat" have much more potential for exploitation as a piece of a DKR.
An answer to your problems in the system we are envisioning is to
allow you to painlessly construct your own view of the archive in the
shared environment so that others may have access to your assessment
of importance and notes that you have taken wrt. the discussions.
> --The other email problem that I would love to see fixed
> is not addressed by this proposal: searches. When I search
> messages in my inbox, I get a list of messages -- I then
> have to click each message to open the text, and do another
> search to find the term! Awful. Search should work like a
> document search (find next, always showing the term in
> context).
And of course searching is central. At this point we're still trying
to build something worth searching.
>Bottom line:
> Had we done the use case analysis, I would like to think that
>system requirements like "see reply in context", "ability to
>ignore threads" and "better searches" would have come out. For
>the use cases we did examine, the need for categories did appear,
>but is not addressed in reasonable fashion in this proposal, imo.
All of these were there at one point. If they haven't been translated
from meetings into text either on the mailing list or ZWiki then that
is a problem in transcription. Your concerns seem to be more with the
prioritization of goals and implementation path we have chosen than
with the use cases themselves.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:52 PDT