Date: Thu, 24 Aug 2000 13:44:10 -0700

From:	Eric Armstrong
	eric.armstrong@eng.sun.com Reply-To: unrev-II@egroups.com

To:

unrev2

Subject:

Meeting Summary: 22 Aug '00

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

  
  

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

  
  

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

  For example...

  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:

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

2. 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.)

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

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

5. 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).

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.

Sincerely,

Eric Armstrong
eric.armstrong@eng.sun.com