[Fwd: Meeting Summary: 22 Aug '00]

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Thu Aug 24 2000 - 13:45:04 PDT

Rats. Should have posted this to ohs-dev, not unrev.

This is my summary of the meeting I had with Doug
Englebart last Thursday, on the subject of OHS design.

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

  * 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
      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

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