----- Original Message -----
From: "Eric Armstrong" <eric.armstrong@eng.sun.com>
To: "ohs-dev" <ohs-dev@bootstrap.org>
Sent: August 24, 2000 1:45 PM
Subject: [Fwd: Meeting Summary: 22 Aug '00]
> 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.
We actually do not need to convert the XML to HTML,
we can use CSS in IE5 and NS6.
>
> * The idea is that it will siphon off standard
> email messages to build a better email archive.
When the email is in XML, then intelligent searches and
referencing can be used to connect similar ideas in different
emails.
>
> * 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.
I was thinking that when we take a text email, convert it to an
XML doc and put it in the archive, then we would have the
advantages of XML.
>
> * 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.
It will be! Content in the archive will be easier to use and see
relationships between topics and emails.
>
> * 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
I hope that when a user decides to submit an email to the archive,
the user gets the chance to place it in a category of choice.
Then, the noed map or topic map shows these categories and
keyword type content of each item in the archive, making it easier
to find subjects, topics, keywords, ect.
> (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.
I don't think that the XMLized emails will need to contain
'viewcontrol elements' view control can be accomplished using
XSL and/or CSS, which will work to control views using the
rather simple XML email markup already proposed by Eugene
(we made need some more thaought on that markup, but I
don't see why we will need any special markup related to views.
>
> --The proposal puts Augment's view-control commands into a
> very central position, very early on. I would be more
I think this is just because XSL and CSS had not been invented then.
Modern docs separate content and the viewing of content.
> 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.)
A GUI could have buttons that select different views of the current doc
including its realationship to other information items inthe archive.
The differnet viewing options would be limited to some extent
by the structural granularity of the markup, but the XML doc would not
need to contain any special view-control markup.
>
> --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.
This sounds like you want a filter that controls what goes into the archive.
At his point, and maybe always, the user is the filter.
The user decides what to go into the archive and how it is embedded
into the map of 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).
Thes last two paras show how much an intelligent archive will help.
Again, when the archive is XML docs, then a navigable node or topic,
(or whatever) map to whatever level of detail is desired can be derived,
making it easier to find unique or related information items.
>
> 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.
You are right, but the archive architecture, with some level of user
interaction as to what gets archived under what category
will make it easier use. Note, the XML email markup needs a
category attribute.
>
> 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.
>
Well, it seems like to me that Doug wants to get something working
so that we use it to see where it fails.
Thank You and Best Regards,
Joe
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:52 PDT