Rats. Should have posted this to ohs-dev, not unrev.
Overview:
This is my summary of the meeting I had with Doug
Englebart last Thursday, on the subject of OHS design.
Participating:
* Doug Englebart
* Eric Armstrong
Topics covered:
* Doug presented a diagram with intermediaries
translating plain text into XML and then again
into HTML for display on a browser.
* The idea is that it will siphon off standard
email messages to build a better email archive.
* We discussed several design options for how the
system might work.
Concerns:
* This is the same system that was proposed several months
ago. It may be viable, but I have not yet been convinced
of that.
* 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.
* 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.
* 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.
* The current proposal leaves the issue of categories entirely
unaddressed -- unless we do it with "link types". But to my
mind, there is a definite semantic flavor to categories
(question, answer, argument for/against, todo, done, etc.)
that is associated more strongly with the node. Link types
have a strong syntactic flavor in my mind (citations, replyTo,
attachTo (postIt), quote) -- I see those types as a
syntactic mechanism the GUI can use to control how things
are displayed (eg: replies shown inline, shown as links, or
invisible), while the semantic categories are used more for
node searching and filtering. This is a highly philosophical
distinction that has not been discussed or investigated. But
if my feeling is correct, using the link types for category
kinds of labeling will work against a useful "separation of
concerns". That could make it more difficult to create good
view-control mechanisms down the line.
* 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.
--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.)
--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.
--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.
--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).
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.
When we built StreamLine, I was fortunate to have two strong
developers who convinced me to let my preconceived notions go
and let the analysis take the system where it wanted to go,
rather than forcing down the path I had chosen. I wish we could
do the same with the OHS. I believe it would make a difference.
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:52 PDT