What’s Wrong with Email? (for collaboration)

The Web abounds with collaborative efforts to solve complex problems. To date, the only tool that supports a robust discussion among remote parties is email. But email does not easily support lengthy discussions aimed at reaching a conclusion, nor does an email-archive provide a readily-accessible historical record. This paper evaluates email’s strengths compared to Web-based discussion tools, identifies its weaknesses, and defines the requirements for a truly effective online discussion tool.

Originally published 2000

Originally Written for the Bootstrap Alliance, 5 Sep ’00

Acknowledgments
The thoughts expressed here arose as a result of the colloquium and follow-on meetings hosted by Doug Engelbart at Stanford University and SRI in the Winter, Spring, and Summer of 2000, aimed at designing the systems we need to augment our collective human intelligence and increase our capacity to solve complex, urgent problems. My conversations with Doug Engelbart and Eugene Kim, in particular, inspired this work.

The World-Wide Web has introduced unparalleled opportunities for remote collaboration. Open Source projects, in particular, engage far-flung participants in cooperative efforts aimed at solving complex problems. Today, open source developers are able to share source code, make changes, and track version differences, all using the Web. When a problem arises, email provides a vehicle for communicating opinions and arriving at a solution.

So far, so good. But even though email is effective for some communications, very little open source design goes on over the Web. The reality is that attempts to initiate open source projects languish in obscurity until a preliminary code base is constructed. [Reference: Eric Raymond] Once code exists, open source projects tend to gather momentum. Incremental additions and improvements “accrete”, and the system grows over time.

But as valuable as it is to improve an existing system, it is even more valuable to establish a solid design-foundation. However, the process of design and the decision-making it requires rarely takes place over the Web, or via email. The systems that exist today simply do not allow the process to take place in an effective, constructive manner.

Design discussions are one example of far-ranging, exploratory discussions that are designed to reach a decision. Such discussions take place in most every field of cooperative endeavor, in research labs, schools, and businesses. Although email and Web-based discussion tools provide a vehicle for exchanging short messages and sharing ideas, they fall short when it comes to deep discussions. As a result, such discussions typically take place in face-to-face meetings.

But the reality of an Open Source development effort is that only rarely can the participants engage in face-to-face meetings with any degree of frequency. That audience in particular is in dire need of an effective discussion tool. This paper pinpoint email’s deficiencies for carrying on decision-oriented discussions. It also evaluates email’s strengths relative to Web-based discussion tools, and defines the requirements for an effective replacement.

We’ll start by evaluating email’s strengths We will see that, in many respects, email provides a valuable user-interaction model. However, the specifics of the interaction fall short, largely due to the inadequacy of the data structures that email systems manipulate. As we investigate email’s weaknesses, we’ll adduce the data-structure requirements that will allow effective discussions to take place online. Finally, we’ll evaluate some of the web-based discussion alternatives like Slashdot.

About this Document
This write up started as an analysis of the weaknesses of email and web-based systems for investigative discussion and information management, a topic originally suggested by Eugene Kim. But as I struggled to explain email’s major weaknesses, I found it impossible to do so without resorting to an explanation of how the system should operate — because it is only in comparison with the functional requirements that the weaknesses emerge. The consideration of the ideal system’s functional requirements led naturally to an explication of the required data structures, because it is the information contained in the data structures that makes the functional behaviors possible. A central tenant of this document is the proposition that the relative poverty of email data structures precludes the sophisticated behaviors we need. It therefore seemed imperative to elucidate the data structure requirements in detail, so that all of the required functionality would be possible, even if not immediately implemented.

As a result of the aforementioned “feature creep”, this document has grown to nearly 12,000 words, contained in 24 pages or so. It is in reality three documents in one: an analysis of email and web-based forums; a functional specification for system that meets as-yet-unaddressed requirements for information exchange and collaboration; and a data structures document. The final section of this document provides a matrix that relates the data structures and the functional requirements. Despite that, the data structure segments could probably be extracted into a separate document fairly easily. Ideally, it would be possible to separate the analysis of current systems from the functional specification for its replacement. However, the two are so inextricably linked that it is difficult to see where to insert the knife. (In the proposed system, each paragraph could be tagged as “analysis”, “functionality”, or “data structure”. It would then be possible to look at different “slices” of the document, and see what pops out. It is requirements like that motivate this discussion.)

Email’s Strengths

Although email is rife with weaknesses, it also provides a fundamentally right model for a communication system. The following are characteristics that any proposed replacement must share, in order to retain email’s advantages:

Asynchronous

One of email’s primary advantages is that two people do not have to be present at the same time to carry on a discussion. That lets each party respond at a convenient opportunity, after having a chance to reflect on the topic of discussion. Frequently, when you hear of software system designed for “collaboration”, it turns out to be a real-time, synchronous system that is essentially a vehicle for holding online meetings. Although such tools are valuable, a truly effective system for discussion and decision-making will share email’s asynchronous character.

 

Centralized

Another major strength is that an email system is “command central”. You don’t have to go looking for information you are interested in — it all comes to you. That feature makes email both convenient and efficient.

Note:
A lot of information you don’t want comes to you, too, in the form of spam. In my view, wasting enough time from enough people is the moral equivalent of killing someone. That, too my mind, is the fundamental ethical basis for designing easily understood interfaces, robust functionality, and data safety. But spam? That’s like killing two or three people a day. It’s unconscionable.

 

Highlighted

In email systems, new and unread messages are automatically highlighted. In other words, the differences between your previous message repository and the current version are visible, so you can easily focus on what’s new.

 

Earmarked

In addition to seeing new messages at a glance, it is also possible to mark messages for follow up. Netscape’s Messenger is particularly good at this. With a single mouse click, a small “flag” appears on a message, so it stands out as something you need to act on.

 

Local

In general, email messages are copied onto your local system from the server. The makes determining which messages are new a fairly simple matter. (A single-server solution would need to keep track of what every person had read. A fairly daunting task.)

In addition, the fact that messages are viewed locally makes it fast. Reading messages and replying to them is fundamentally an interactive activity, so speed is important. A slow system is not only painful to use, it also tends to derail your train of thought. When you are capturing ideas in a form suitable for communication, a system that moves “at the speed of thought” is essential. Otherwise, it can become more of an impediment than an assistant.

Local systems not only operate faster, they operate dependably faster, which may be even more important. Remote interactive systems, with only rare exceptions, have proven to be uniformly inferior to local systems — which accounts for the popularity of personal computers. In a remote system, you not only suffer the constant latency introduced by sending requests down the wires and waiting for a response, you also run into sporadic latencies introduced by web traffic and competition for server resources.

Finally, the fact that messages are copied onto your system achieves one of the fundamental goals of the Internet — safety by virtue of redundancy. Because copies exist in many locations, it is largely impossible for a single catastrophe to erase the data that people are depending on. In a major flood, for example, you might lose not only your system, but all of your backups, as well — even if they were stored somewhere else in the city. (Unless you have major foresight and the deep pockets to store your backups under a mountain somewhere in Colorado.) But with local copies stored in far-flung locations, it is always possible (if difficult) to reconstruct your message repository.

 

Threaded

Most email systems provide for logical “threads”, which produces a tree structure where replies are indented underneath the messages they respond to. The threading provides three important advantages. First, it reduces the size of your inbox by moving follow-on messages out of the way. Second, it groups related messages together, so you can follow the conversation. Third, threading lets you collapse and expand the hierarchy of messages, the same way that you expand and collapse directory trees.

The ability to collapse and expand lets you can focus on areas of interest while excluding a majority of irrelevant information, while still keeping a “bird’s eye view” of other topics. That last feature is important, so I’ll repeat it: You can keep a high-level view of other topics. Consider a directory tree, for example. You “drill down” to see the files in a particular directory, but you can still see other directories in the tree. That high level view makes it particular easy to shift your focus to another directory. An alternative mechanism for dealing with such a hierarchy is to “drill down” by limiting your focus. In a directory system that uses that mechanism, visiting the directory replaces your view with the contents of that directory. In such a system, you can only shift your focus by moving back up the tree. By interactive interface standards, that is a laborious, time consuming operation that interferes with your ability to see the whole as a gestalt and see how the elements in the structure are organized relative to one another.

The moral is that having a hierarchical structure is important, but it is equally important to use it effectively.

 

Organizable

In the same way that threads are organized hierarchically, present-day email systems let you create a hierarchy of information folders and store your messages in them. The ability to organize the information in a way that makes sense for you improves your ability to find information you are looking for.

 

Integrated Authoring

Just to be complete, it is worth pointing out that when you are viewing a message, you can reply to it with a single button click. After sending the response, you are automatically returned to where you left off. The functions of reading and authoring messages work together sufficiently well to qualify as an “integrated” authoring environment.

 

Replies “In Context” 

Although it occurs in an inefficient, ad hoc fashion, email also lets you author communications “in context”. When you reply to a message, the original is typically copied into your message and offset so as to distinguish it from your text. That lets you reply to a lengthy message point-by-point, interspersing your comments with the original text. In effect, then, you splice your replies into the original message. (That mechanism creates problems at the receiving end, which we’ll discuss later. But it’s useful when authoring.)

Because of its many advantages, email presents a seductive environment for information exchange. In attempting to design a system that allows serious discussion and decision-making to take place online, it makes sense to use email as the basic model, and work to improve its (many) shortcomings. Before settling on that decision, though, let’s consider some of the alternative web-based models for communication systems.

Email Alternatives

The alternative communication vehicles that have surfaced so far have not quite succeeded in improving on email sufficiently well to offer an effective replacement. In some cases, they offer improvements but lose some of emails major strengths. In other cases, they offer few additional functions, while at the same incurring adding disadvantages.

Newsgroups

Newsgroups fall into the latter category. Newsgroups tend to function very much like email systems, so newsgroups warrant replacement for the very reasons that necessitate an improvement on email for serious discussions. (Those motivations are described in detail in the next section).

In addition, Newsgroups lose one of email’s major strengths — its centrality. You don’t see newsgroup messages until you go looking for them. The issue is most pronounced when you post a question. In a web-based forum, you have to keep going back to see if it has been answered. In a mail-based system, the answer comes to you. (Some hybrid systems have recently come into existence that send a message when a question has been answered — a very good thing.)

The benefit of newsgroups is that they segment information in a particular subject area into a separate “box”. That separates the information from other messages, so you can deal with it at an appropriate time. However, today’s emails let you automatically filter messages into different folders, which achieves the same segmentation without loss of centrality. (When newsgroups arrived on the scene, of course, such filtering did not exist — a fact which no doubt accounted for their initial popularity.).

Web-based Systems

More recently, web-based systems like Slashdot (www.slashdot.org) have come to the fore. Although they offer some interesting capabilities, they don’t quite rise to the level of a serious discussion tool — at least, not the kind of tool that is needed to carry on a design discussion, for example.

Slashdot’s most useful contribution to the concept of online structured discourse is the ability to evaluate messages. In addition, Slashdot lets you rate the evaluators, thereby weighting the effect of their evaluations. The existence of message ratings then lets you view messages based on their rating, so you can filter out some of the more egregious noise. As you’ll see later on, rating-capability is a critical component of an online discussion tool.

However, systems like Slashdot still don’t address the most critical shortcomings of email, and they introduce several disadvantages when contrasted to the email model, all of which derive from being Web-based:

Latency

Since the messages are stored on the web, you get all the latency that the web introduces — roundtrip response times, web traffic, and server congestion. Since message viewing is an interactive process, the latency is especially noticeable. For example, changing your view from a chronological to a threaded display of the messages takes much longer than it would on an email system.

 

Data safety

Since copies of messages are not stored locally, data safety becomes an issue.

 

Cost of failure

In addition, if the server goes down, thousands of users are unable to access the information, so the cost of a single system failure is huge. In contrast, the cost of a local system failure is relatively minor (to all but the affected individual). Of course, a power failure can affect multiple users, but a power failure at the server location is not confined to small geographic area — it can affect users all over the globe.

 

Inability to simplify

Most importantly, web based systems don’t not let you prune the data by deleting things, or reorganize the information in useful ways. Local systems, on the other hand, let you delete things you’re not interested in and recategorize information into folders.

 

Lack of signposts

Finally, web-based systems don’t highlight new and unread material. If you don’t stay up to date all the time, its hard to figure out where you left off. And of course, you can’t set follow up flags or mark priorities on the messages.

In short, although Slashdot is a reasonable vehicle for sharing news (it’s basic purpose), it is not quite up to the task of carrying on serious design discussion. To understand what we need in a system that will allow such discussions to take place effectively, we’ll investigate email’s shortcomings next.

Email’s Fundamental Weaknesses

In general, then, email provides a useful model for interacting with an Asynchronous Communication Environment (ACE). However, although its interaction model is valid, email presents functional shortcomings that preclude serious discussion. The cause for these deficiencies is fundamentally structural — the kinds of structures that are stored in email archives and sent as mail are simply unequal to the task of carrying a far-ranging discussion effectively. This section identifies both the functional weakness (the things you can’t do) and the structural weaknesses (the design limitations that make those capabilities impossible). The next major section, A Matrix of Possibilities, ties things together, presenting a matrix that describes lists the functional needs for an ACE-quality system and relating those needs to the structural requirements for the system.

This section identifies email’s most fundamental weaknesses — it’s lack of extensibility and the lack of structuring. The next section identifies the advantages that accrue from using structured messages. The section after that highlights additional functionality that is missing in existing email systems and identifies that specific structural requirements that will enable them.

Not Extensible

There are hundreds, if not thousands, of editors out there. Yet, when you use an email system, your choice is narrowed down to one — the editor the email client provides. That is not only inconvenient — you lose some functionality you have come expect and invoke some of the existing functionality with different gestures — but it seriously limits the ability of the system to evolve.

Doug Engelbart (developer of the NLS and Augment systems. His take on things is that mankind is in serious need of computer systems that can help us solve urgent, complex problems. But the design of such systems is itself an urgent complex problem. So we have a chicken and egg problem — we need an effective system to build an effective system! The only solution is to make the system evolvable, allowing it to increase in capacity over time. The advantages we derive from any given stage of the design then applies to subsequent designs, accruing at an exponential rate, like compound interest. (For more information, see Toward Integrated, Evolutionary Office Automation Systems
at https://www.bootstrap.org/augment-71279.htm.)

Today, XML gives us the capability for sending arbitrarily complex messages in reasonably standard form. If email clients were extensible, we could already be sending XML messages back and forth, using our favorite XML editor for the authoring. The email server could then be extended to recognize and operate on such messages in interesting ways.

The lack of extensibility in existing email clients, however, has forced Doug Engelbart Open HyperDocument System (OHS) project to attack matters from the other direction. Instead of expecting XML messages as input, the system currently under construction expects to translate plain text messages into XML structures, which it can then operate on in useful ways. Due to the added structure, the email archive will be able to provide greatly extended functionality. However, a plain text form of the message will continue on to its destination until XML-based clients can be devised.

Unstructured messages

Discussion of XML leads naturally to the consideration of structure in messages. After, all folder hierarchies have structure. Thread hierarchies have structure. Why not messages themselves?

In the 70’s various attempts were made to introduce structure into text, in the form of “outliner” applications. Some of that functionality survives today as adjuncts to word processing applications. (For example, the outlining capability in MS Word.) Outline programs failed for a number of reasons. One was the inability to compete with marketing and development potential of organizations that had a large installed base of word processing users. Another was the serious inadequacy of some early outliner interfaces — well-publicized efforts that secured a lot of early-adopter mindshare, only to be abandoned after their deficiencies came to light. But, perhaps the single most important reason for the demise of outlining applications was the lack of a unified standard for outline structures.

As the growth of Internet communications made abundantly clear in the 90’s, the development of standards is the most important game in town. It’s a lesson the consumer electronics industry learned in the 80’s. The software industry has only recently caught up to that fact. Had their been such a standard for outline structures, the combined weight of the outliner organizations might have been sufficient to make a dent in the word processing market. Today, the existence of XML makes such a standard possible.

Designing an Effective Email Replacement

Many of email’s limitations stem from a simple lack of structuring. The next section dwells on requirements that are a direct result of the need for structure in messages — any structure. The section after that moves on to specific requirements — that is, the kind of functionality that is required for an effective discussion tool, and the information that must be encoded in the message structure to obtain it. The analysis concludes with a function/structure matrix that relates required functional to the structural mechanisms which support it.

General Requirements — The Need for Structure

The addition of structure to email messages provides a number of benefits, all by itself. Having a structure of some kind is therefore the most critical requirement for any system aimed at carrying on serious discussions. In addition, there are a number of specific structural requirements (specific kinds of information the structure must include). Those are covered in the next section.

View controls

Given an XML-based standard for online communications, many capabilities become possible. Not the least of these is view control capability. You use view controls now when you expand and collapse the tree view of your directories, your email folders, and your lists of threaded messages. The same ability to collapse and expand hierarchies should exist when viewing messages!

Hierarchy expand/collapse is most useful in documents that have headings. Each heading takes up one line, so the resulting display is very similar to a directory tree. Paragraphs, on the other hand, take up a lot of space, which obviates some of the advantages of collapsing the hierarchy. But the existence of structure in a message allows for single-line viewing. That is, rather than displaying a full paragraph, only its first line is displayed. That way, even large paragraphs can be viewed as though they were tucked away under a one-line header.

With structured messages, the “table of contents” for a message is built into the message itself. When the hierarchy is collapsed, the overall organization becomes clear. That makes it more convenient to view the message now, and easier to find things in the message later.

Fast manipulations

The existence of structure in text produces two major advantages. One — the ability to collapse and expand — has already been mentioned. That capability makes even very large documents seem conceptually smaller and easier to manage. (I recently discovered that my directory tree contained 1700 folders! It never seemed that big, due to the hierarchy.)

The other major advantage is the ease with which such structures are manipulated. Consider the actions you take when replying to part of a long message, for example. To remove part of the message you are not concerned with, you click to start a selection, scroll to the endpoint, click again, and then cut. This click-scroll-click-cut sequence is more time consuming than you might think, You probably do it so often that you are not even aware of how much time it takes — until you do the same operation in a structured environment. Because a header contains everything under it, you delete entire sections with: click, snip. That is: you click on a heading, then you delete. With structure deletes, you rapidly narrow things down to the relevant paragraphs. Then you can remove unwanted bits of text to trim with normal click-and-cut operations. Similarly, you can rearrange sections by the simple expedient of dragging a heading to a new location — all of the text under it comes along for the ride.

Note:
As you’ll see shortly, in a well-designed system you won’t even need to include text in your replies! So that operation will disappear entirely. It’s something you do so frequently in current systems, though, that it made an excellent illustration for the ease of manipulation that structuring introduces.

More functional windows

The typical email client deals with three entirely separate structures — folders, message headers, and messages. Each of these structures is manipulated in a separate window. But must it be so?

Certainly, the existence of separate windows is convenient. Having one window that automatically shows message headers for the currently selected folder is convenient, as is having a window that shows the body of the currently selected message. But at the moment, the hierarchy in each window is forced to stop when it comes to the next non-homogenous layer. So the folder window can’t show message headers, and the header window can’t show message contents.

But suppose each window was operating on the same kind of structure — an XML structure. The default behavior of the folder window could still be to show folders, but not messages. But with an extra gesture (say, a shfit-click) a folder in the folder window could be expanded to show the messages it contains. Similarly, a message header in either the folder window or the header window could be expanded to show the message it it contains.

When you combine that capability with the ability to easily drag and drop entire sections of a message, much useful behavior becomes possible. For example, even if the ability to edit messages were restricted to items in the “Drafts” folder (another restriction which, as we will see, needs to be overcome) you would still derive enormous benefit from the multiple windows.

For example, I typically keep an open “ToDo” list as a draft message. Having that message available in the folder window, along with a message hierarchy in the message window, would let me drag and drop a single paragraph or an entire section of a message to my ToDo list. As another example, when links to useful information appear in inbox messages, they could be dragged to a “list of references” message. In both cases, the hierarchy under the message could be displayed as well, and the information added to the appropriate subcategory.

The moral here is that the ease with which documents-in-progress can found and edited already makes email an attractive authoring environment, at least for relatively simple lists. The addition of hierarchy to messages makes such uses even more convenient, and enables much more sophisticated operations, as well.

Granular operations

The ability to delete a paragraph or a section results from one of the major advantages of hierarchies — their increased granularity. The granularity of a system is measured by the size of the fundamental unit upon which you can perform operations. In current email systems, the fundamental unit is the message. You can reply to messages, move them, and delete them. The message is the “atomic unit” of operations in such systems. In other words, present-day messaging clients are relatively coarse grained systems.

Hierarchical messages, in contrast, allow fine-grained controls. Rather than replying to an entire message, for example, you can reply to a particular paragraph in it. Of course, you could also reply to an entire message. But the ability to respond to a particular paragraph relieves you of the responsibility for editing the message down to the paragraph in question.

Elimination of redundant headers

One serious weakness of email threading is the fact that the message header typically goes unmodified. An entire hierarchy of messages in thread can therefore have the same header. This problem is eloquently depicted in Jim Hewitt’s paper,
Beyond Threaded Discourse, available at https://csile.oise.utoronto.ca/abstracts/ThreadedDiscourse.html. In cases like these, the thread is identified (repeatedly!), but the heading gives no clue as to the content of the message.

The reason that headers are not modified more often stems directly from the lack of homogeneity of the data structures. The heading is in a separate location. That requires moving to the text box, selecting the text in it, replacing that text, and moving back to the editing window. It rarely happens. In addition to the extra steps, it requires coming up with a descriptive title, so it rarely happens.

But why should the message have a separate field for the heading? Why not use the first line of the message, or the appropriate “head” element in a structured message, if it exists? When your reply does not have to include the original message, the initial text of the message will have meaning, even without a header. In addition, experience with Doug Engelbart’s NLS system in the 70’s, and outliners with single-line capabilities in the 80’s, showed that users quickly learn to state the central concept of the paragraph in the first line in order to facilitate later retrieval.

The existence of hierarchy in the message therefore allows meaningful headers to be constructed automatically, without requiring the user to switch to another window to create them.

Elimination of redundant text

But perhaps the most visible benefit of adding hierarchy to messages, along with the ability to respond to elements within it, is the elimination of redundant text from messages.

Currently, when attempting to reconstruct a conversation from a chain of messages in a thread, you encounter several problems:

1. You wind up reading the same duplicated messages over and over, looking for comments that may have been inserted into them.
    
2. There is no standard form for the indentation, so it is sometimes hard to tell which text is original message, and which the reply.
    
3. There are no view controls to help you keep track of the response-nesting, in other words, it is sometimes hard to tell where a response “Fits” in the sequence of messages.
    
4. Some replies occur before the quoted text, and others after, which can make the exact sequence of comments more difficult to discern.

All of these issues are either ameliorated or disappear entirely when hierarchy is introduced to messages. The ability to respond to part of message makes it possible to display the response “in context” — surrounded by the original message, rather than embedded in a copy of that message. The resulting hierarchy displays the conversational threads implicit in the message components in the exact same way that the header-window displays of message threading.

However, in the system under development, the header window will only contain responses that pertain to an entire message. Responses that pertain to part of a message will appear “in context”, indented under the part of the message they refer to.

Specific Functional Requirements

So far, we’ve been looking at general capabilities that hierarchical structuring enables. This section attempts to zero in on the specific weaknesses that impede an investigational dialogue — the things that current email mechanisms won’t let you do, and why it is that you really want to do them. Along the way, we’ll identify the kinds of information the message structure needs to store in order to do such things.

The discussion tool we need must solve several pressing needs that today’s email systems do not provide:

• The compilation of a usable “Organization History” or “Knowledge Base”
• The ability to access information quickly, and help others do so.
• The ability to carry on effective discussion

Organization History / Knowledge Base

As one author pointed out, there was little need to worry about capturing corporate expertise in the first half of the last century, because lifetime employment was the rule. In the latter half, however, with job hopping becoming the norm, corporate “brain drain” is a pressing problem.

To stem the tide of lost information, organizations would like to maintain a usable record of the decisions they’ve made — how they got where they are, and why — so they have guidelines for future decisions. Software developers, too, need usable histories. Typically, major design decisions are lost in the dim mists of ancient antiquity. But you frequently need to know why a particular path was chosen, and what alternatives were considered — either to penetrate the system’s code base, to defend a particular decision, or to revisit the alternatives.

Since so much communication occurs over email, the ability to maintain that record in a usable way would be of enormous value to the organization. (Ethical organizations, that is. Those worried about legal proceedings are not much interested in archives, usable or otherwise.)

Although email lists managers maintain archives, they are far from usable. Probably the most important factor in compiling a usable archive is the quality of the email discussion, itself. We’ll look at the issues surrounding that topic in a moment. For the moment, let’s take a look at what we need to make effective use of an archive — any archive:

Granular addressability

To be useful, it must be possible to reference material in the archive. In a software setting, for example, it should be possible link source code to the design decisions which motivated them — decisions which are themselves linked to the functional requirements for the system. In turn, both design decisions and functional requirements should be linked to the discussions that preceded them.

So addressablity is a major requirement. But you need the ability to reference parts of a message, rather than the whole document. Suppose, for example, that someone provides a very good explanation that is near the end of a response to a length email. In today’s messaging systems, there could easily be several pages of quoted text, interspersed with commentary. Referencing the entire message for that one explanation would be of little use.

To be useful, messages must be addressable to at least the paragraph level, using the basic principle of writing that every paragraph constitutes a single idea (where headings count as a “paragraph” — or an atomic unit of thought). The existence of hierarchy in the message body makes that addressibility possible. It then becomes necessary to expose the addresses.

Here, the system must avoid a major weakness of HTML pages. Although named anchors can be defined anywhere in the document, they’re of no use to anyone but the document’s author, because they are not exposed to others. Without a tedious inspection of the document’s HTML source, other users can only refer to the entire document, not to elements within it.

More importantly, named anchors don’t exist in HTML pages unless they are created. So, even if named anchors were exposed, users would be limited to referencing the things that the original author thought to provide links for. At a minimum, then, every paragraph should be addressable, and those addresses should be exposed.

For a good example of how visible paragraph addressing can work, go to main page for the Open HyperDocument System (OHS) at https://www.bootstrap.org/ohs. The small purple numbers at the end of each paragraph represent paragraph numberings. (The system alternates between numbers at letters at each level of hierarchy, so “1A2” is number of the first major heading, 1st subheading, 2nd sub-subheading.) The OHS project intends is to turn those unobtrusive identifiers into archive-links. Since each identifier will be a link that points to itself, referencing a document will be a matter of copying the link from a paragraph or heading.

XML provides important functionality in this regard. The globally unique identifiers for information nodes need to be Universal Resource Names (URNs) rather than Universal Resource Locators (URLs). The difference is that a URN allows you to find the referenced item locally, if a copy exists, and only go over the wire to the remote archive if no local copy is present. (As a general rule, URNs tend to look exactly like URLs. It is the processing mechanisms which differ.)

“Entity references” are another useful XML mechanism. With an entity reference, the referenced material appears “inline”, as part of the current document, rather than as a clickable link, so you can easily quote sections from another document.

Vastly improved search criteria

Before you can address things, however, you have to find them! But the ability to search present-day email archives is of so little value that, coupled with the deficiencies in the message structure itself, the archive is all but useless.

The lack of granularity is one problem. When you do a search, you get the whole message returned, rather than just the relevant text — so you have to search again in the message.

Even worse, a search in current systems returns a list of message headers! Since the headers are largely redundant, you don’t even have the initial text of the message to remind you about it’s content. What you really want, of course, is for the matching text to appear “in context”, the way it does when you search any other document.

But even if searches appear in context, present day systems are problematic. Since messages threads typically include quoted material from earlier in the thread, the search tends to generate “false hits”, where the text you are looking for exists as part of an inclusion from an earlier email. So you find yourself reading the same material over and over in every message that commented on it.

The redundant text problem is especially acute in the email archive. Since every irrelevant, “me too” message is retained in the archive, the false hits multiply. As a result, it tends to be more rewarding to consult the messages you’ve saved yourself, rather than the shared archive.

That problem, in conjunction with the redundant headers, tends to limit your searches to those discussions you have been a party to. When searching through messages you have read and saved, you can improve your odds of finding the material you want, because you can refine your search based on who said what, and when — information which is available in the message header and shown as part of the search results. But if you were not privy to the original discussion, that information has little value.

But if the only way to limit your searches is to have been part of the conversation, and to have kept your own personal archive or digest of it, then a shared archive has little to recommend it. To become a useful knowledge repository, it is paramount for the discussion tool to provide effective search tools.

Categorizing

Another factor that makes searching one’s private history of discussions infinitely preferable to searching a shared archive is the existence of mail folders. The ability to file messages into different folders greatly reduces your search time, because you can restrict the search to messages in that folder.

In essence, folders let you categorize information to so you can find it again later. But you only get one category, unless you copy the message. And you can only categorize an entire message (a granularity issue) And no one else derives any benefit from your categorization (a shared information issue).

To qualify as a knowledge repository in any sense of the word at all, the message history must represent an archive of shared information. Each message contributes information to that repository. But categorizing also represents a contribution of information. And that information is not shared in current email systems.

And even though you can restrict the search to folder in current systems, you can’t search on other information you have added. For example, you can’t restrict the search to items you have marked for follow-up. Plus, you cannot easily search multiple folders. Nor can you search on an “intersection” of folders — that is, search for messages with membership in one or more folders.

The lack of categories is another factor that tends to limit the utility of message archives to those discussions you have been a party to. For instance, if you want to find examples where somebody solved a supply-chain distribution problem, you would be hard pressed to do so in a email archive. If the situation occurred in recent memory, you could track the information down based on the message header, and further refine that to the solution proposed by a particular person. But in such a search, you are depending on personal knowledge of events to find specific information that is relevant to a general subject area. There is no capacity to find messages that match general categories like “distribution problems”.

Finally, it is not possible to change the header of an email message, no matter how irrelevant it is. (I find that I resend things to myself all the time, just so I can file them with a decent header!) The ability to categorize individual nodes using either an agreed-upon set of keywords, or possibly a private set of keywords, would go a long way towards making important information retrievable in the future. The hierarchy of categories could then double as a list of “folders”, except that even more powerful selections could be made, beyond choosing a single folder for display.

All of these issues cry out for a more generalized capacity to define and use categories. The ability to do knowledge-management kinds of things with the message archive depends heavily on the existence of categories. And, as you’ll see later, categories are also essential to the ability to carry on an investigative dialog in any kind of structured fashion.

Note:
It is likely that it makes sense to maintain private as well as public categories. For example, the “trash bin” could easily be implemented as a category that saves a URN, rather than a message. A deleted message could then be recovered from the archive, with only a minute space penalty for the ability to do so.

Possibly the definitive example of the way categories should work is exemplified by the Traction system. You can get a visual “walk-thru” of that system at https://www.twisted-systems.com/slides/readermov.swf. The Traction system lets you define hierarchies of categories. Categories you add are available to other users of the system, as well as yourself. You can also change categories, and choose which items in that category are affected by the change. The system keeps an audit trail of category changes, so you can tell who did what, when. The categories a paragraph belongs to are listed to the right of the paragraph, in a light, pastel color so they are not visually obtrusive. All in all, the Traction system presents a definitive model for the way that categories should work in an online discussion tool.

Fast Access / Enabling Access

As important as it is to be able to find things in an archive, the ability to manage the flood of messages that arrive daily is equally important. For that, we need vastly improved selection criteria and the ability to share a valuable view with others.

Filtering out noise

One major annoyance of existing messaging systems is the degree to which you are continually bombarded by replies to messages that you have already declared as totally uninteresting. Having already deleted a message, why does the system think you could possibly be interested in comments on it? You aren’t, and it shouldn’t.

True, every once in a long while a reply comes along that is of intrinsic interest. But not nearly often enough to warrant the daily deluge of messages pertaining to topics you have already expressed a total disinterest in!

If the “trash can” category is used, then new messages which are replies to old messages automatically wind up in the trash bin. Since URNs are stored in the trash can, rather than messages, the space requirements are not that great, and all future replies automatically wind up where they belong. (The fact that existing systems must store entire messages means that the trash bucket is periodically purged, which works any useful ability to ignore threads.)

Many other mechanisms are needed to effectively filter out noise (some of it well-intentioned), as well. Those mechanisms should be available to either by the user directly or, at the very least, to a discussion moderator, if present. We’ll discuss those mechanisms in the next section.

Seeing what’s new

The ability to rapidly identify new and changed material is an important form of noise filtering. In this case, material you have already read constitutes “noise”. You want to focus on what is new an different. Doing that in a hierarchical system means that each node must have a version attribute. Then, just as an email system currently highlights new messages and the folders that contain them, the hierarchical system can extend that capability down to the paragraph level to highlight new responses.

Now, the “go to next unread message” function that previously took you to a message (along with any redundant quoted material) now takes you to the text of the response, surrounded by the original message.

Expanded selection criteria

In addition to some the standard view controls of hierarchical systems — collapse/expand, and single-line viewing — the system needs the ability to select messages based on a variety of criteria — for example, by subject, date, or author, or by a combination of categories. It also needs the ability to exclude entries from the current view, based on the same criteria.

The ability to filter the messages to be displayed is another mechanism that contributes to noise reduction. For example, if a message consists of a long hierarchical document, it may be desirable to see the original document by itself, without any of the commentary that others have added. Then, when making comments of your own, it may be helpful to view what others have had to say on the same subject.

If replies fall into categories that the community members have agreed on ( for example: question, agree, disagree, additional info) then it becomes possible to selectively view documents and its associated commentary in interesting ways. (We’ll investigate this point further when we come to the requirements for carrying on a structured discussion.)

Expanded view controls

Besides selecting the messages you display, you need control over how they appear. For example, a <gls> tag might mark a phrase that is defined in a common glossary. Should that phrase appear like other links –say, as an underlined, blue link? Or does that give the link “equal weighting” to other, more important links. To “weight” the link such links more appropriately, it may be desirable to render them in italics, with no other indication that a link exists, except that the cursor changes shape when it hovers over the link.

Or maybe you want such information to automatically appear in roll-over window when the cursor lingers over the phrase. The point is that the document author should be able to categorize the link according to a common standard, and you should be able to determine how it appears on your system.

In addition to glossary links, you need to the capability for identifying citations (references), and quotations. The system therefore requires the ability to define link types. Like categories, the types defined by the community present a circumscribed list of choices that document authors can use to describe the role the link plays in their message/document. As a reader, you then have the ability to determine how the linked material appears. Quotations, for example, would typically be displayed as inline. While a citation would typically be displayed as a colored, underlined link.

Sharing views

In addition to formulating useful views of archived material, the ability to share those views with others is highly desirable. In fact, as early as the 1970’s, Doug Engelbart and his crew put two and two together, realizing that in any system in which views are controllable, links to referenced material must be able to specify the appropriate view.

The need for view-specifiable links results from the fact that your reply may well respond to a subset of the material in a hierarchy. For example, you could be commenting on the list of requirements contained in a section of a document/message. In that case, you might want to reference the high-level view of headings the section contains, as though they were taken from a table of contents, rather than referencing all of the material in that section of the document.

(For more information on typed links, see information pertaining to NLS and its successor system, Augment, at https://www.bootstrap.org. You might also see if the video demonstration of the NLS system is available from the organization, or read the Video Review posted at this site.)

Letting the cream rise

As mentioned earlier, the ability to evaluate information nodes is highly desirable, as well. Systems like Amazon.com, which now provides the capacity for sorting query results by their average evaluations demonstrate the value of adding ratings to any list which represents a set of alternatives. That function is also critical to the ability to carry on a structured discussions, as we’ll see shortly.

Note:
Slashdot also allows for evaluations. But there, ratings are used more as a selection mechanism than for ordering alternatives. But it is the latter use for which ratings are most valuable.

Finally, the ability to make selections and do ordering based on message ratings improves the utility of search mechanisms, making the organizational archive that much more valuable.

A Note on Graphics
As a general rule, I am not a big fan of system that attempt to solve complexity problems graphically. Although graphic displays greatly improve pattern recognition when there only a few kinds of objects in the system, text-based information nodes do not fit the notion of “a few kinds of objects”. Even when categorized, the number of categories in a system can grow very large. (Using the human factors limit of 5-8 items we can hold in our heads, I suspect that 8 or 9 is the maximum number of node types that will submit to graphical treatment.)

Ratings, however, provide a tremendous opportunity for graphic enhancement. After all, the fact that a list is sorted in rating-order provides no clue as to whether the list contains 4 stellar entries and one dud, or 1 good alternative and 4 that are only average. Graphic icons would make such information available at a glance, and fall within the 5-8 item horizon. (Five graphic images would be sufficient to identify the rating of possible nodes, thereby allowing human pattern recognition.)

Effective Discussions

Having a usable archive and the ability to select appropriate views are important attributes of an effective online discussion tool. But of even greater importance is the capacity to carry on a discussion in a structured fashion, to investigate alternatives, and to arrive at a decision. To achieve that goal, we need better authoring and organizational mechanisms.

Encourage collaboration

The most fundamental requirement for effective collaboration is a willingness to cooperate to achieve a goal. And there is no motivator so strong as recognition for one’s contributions. To guarantee that recognition, and ensure that every node can be traced back to its originators, the system must support automatic attribution. In other words, it must be possible to identify the author of every node in the system, along with the authors of all nodes it references.

Email systems already do that, at a coarse grained level, by identifying the author of every message in the system. But a good discussion tool needs to ensure that when a paragraph or section of a message is copied or reused in any way, the appropriate attribution is automatically preserved.

Note:
Automatic attribution also makes it possible to keep track of who changed what, and when.

Modifiable Entries

One annoying aspect of current email systems is that you can’t fix a typo or correct a link in a message you have sent — even though you have a copy of it that you could easily correct and re-post. Well, you could do that. But the result adds further clutter to the email system, requiring all of the messages recipients to delete the original in order to keep the hierarchy clean. Even then, if someone has responded to the original in the interim, the result is anything but clean. And no matter if everyone does the deletes in perfectly synchronized fashion, the message archive still suffers from the clutter.

The only solution is versioning. And it must occur at the node level so that individual corrections can be made. (When a new node is added to a list, the parent of the list is versioned.)

It might also be useful to define an “in progress” category that allows the nodes in a hierarchy to be modified at any time, without versioning. Once the message/document was “published”, the normal versioning mechanism would go into effect.

In either case, editing must be restricted to the original author, by default. In a system that does not support automatic attribution, the non-policy that allows anyone to modify anything is feasible, if precarious. The Wiki system is like that. It serves up HTML pages and allows changes by anyone who reads them. In a system that supports automatic attribution by node authors, the risks in such a system are simply too great.

To support effective collaboration, though, editing-authorization is needed by more the original author. In all likelihood, the system moderator should have edit privileges — that is, the ability to correct a typo or fix a poor choice of wording. But, more importantly, it must be possible to extend the privilege of adding nodes and reorganizing them to a selected list of project collaborators.

Until the message/document is ready for review, it should only be visible to members of the author list. When it is ready for its initial reading, it should be possible to make it available to a selected list of reviewers. Only when it is deemed fit for public consumption should it be made available to the list as a whole. The system therefore needs reasonably sophisticated access control lists.

As in all other aspects of the system, the access controls must be hierarchical. The ability to edit a node therefore applies to all descendants of the node — that is, to the entire subtree anchored at that node.

Note:
Since the system will be distributed, it also needs a mechanism for resolving conflicting changes. In many cases, the existence of a fine-grained hierarchy will side step the problem. Even though we are working on the same message/document, we are likely to be working on different parts of it. However, our changes will accumulate on our local systems until we push them out, increasing the chances that a conflict will occur. The system must detect such situations and act to resolve them.

Removable entries

Email discussions grow and evolve over time, accumulating messages. But they never compact or shrink. One reason is that there is no mechanism for removing Irrelevant messages.

Once sent, an email can never be deleted — not even by its author. But there are a number of reasons for wanting to do so. You may have said the wrong thing, or posted to the wrong list, or maybe the timeliness of the message has expired.

Imagine coming to the office after a week’s vacation and not finding a bevy of messages regarding Tuesday’s lunch menu, and the like. The ability to remove messages would make such a delightful scenario possible. At the very least, deletion should be allowed by the message author.

Just as with adding a node, the deletion affects the versioning of the parent node. So the deleted message is always available, at some level. But its removal from view relegates to the level of uninteresting detail that only historians and lawyers find appealing.

Note:
There are now two different kinds of deletes in the system. One places an entry in the local trash can, and does not affect the global, shared repository. The other affects both. The system must clearly distinguish the two and make provisions for both.

Movable entries

An even more important vehicle for evolving a useful body of knowledge out of an email system is the ability to rearrange things — to move messages where they belong.

For example, when that same-question-asked-for-the-thousandth-time arrives from a new user, it would be most helpful to file it under the Frequently Asked Question (FAQ) heading that answers it. Every node must therefore include a link to it’s parent node, and the new link should be marked as “new” when the originator of the message updates their local version. The “reply”, will then have tied them into a larger body of discussion that covers their question.

When you are an old timer on a list, you wish that people would consult the FAQ list more often. When you are new user, however, you realize how much time it takes to come up to speed on the pertinent terminology — terminology you need to formulate the right question in the right way! The need to reformulate a newbie’s question and direct them to the FAQ which answers it will never disappear entirely, until fully automated, incredibly intelligent systems are developed that understand natural languages — if that ever happens. So the system must have a fast, simple way to deflect queries, especially as it the number of users grows.

Since other users see the new question, as well as the pointer to the old discussion, they have a chance to contribute to the discussion, as well. For example, I once posted a query to find a local optometrist. I received several responses. One was a list of responses that had been saved when a similar query was posted several months earlier. There were resends of some of the same recommendations, and there were also several recommendations from another people who had not been part of the original discussion. In the ideal system, all of those responses would be saved under a FAQ heading, with redundant entries removed. And it would be possible to reply with a pointer to that list, rather than with a copy of it.

For one reason or another, a new message sometimes arrives that is in reality a reply to a previous message. It would extremely helpful to be able to put the message where it belongs, if for not other reason than to improve the search-ability of the repository later on.

Reorganization can be helpful within a discussion, as well. In Beyond Threaded Discourse, available at https://csile.oise.utoronto.ca/abstracts/ThreadedDiscourse.html, Jim Hewitt does a wonderful job of pointing out how discussions “migrate” over time. User “A” posts a question. “B” answers it. “C” answers B with a comment that is relevant to B, but far afield from A’s original query. The migration has begun, and they are off the to the races.

For all of these reasons, the ability to rearrange entries would be helpful. But extant mailing lists do not give even the list moderator any such capability. They have veto and blocking privileges, but little else.

Categories are one mechanism by which a node can be “moved”, in virtual fashion. A node can also be a member of several categories. In tandem, the combination of granularity and categories provides for powerful manipulations and searches. But it should also be possible to change a node’s “home position” so that it resides under a new parent.

When providing these capabilities, the system must take into account the very real tension between the need to create a well-organized, useful repository on the one hand, and the need to minimize disruption of the user’s view, on the other. Current messaging systems present a static display. A message, once it arrives, will always be in the same relative position to other messages, depending on how the view is sorted.

Having a message suddenly move to a new position could prove disruptive — especially in the short term. Over the long term, the exact position of a message is probably less and less of an issue. The chances increase that it will be found as the result of a search, rather than from memory. But in the short term, the message-list could turn into “shifting sands”, if messages keep moving around when you don’t expect it. This is an interface issue that deserves careful consideration.

One mechanism that mitigates that tension is versioning. With versioning, the old organization is recoverable. It may even be desirable to include a “go back to the view I started this session with” in order to find things. (Since a messaging client may well stay operational for days at a time, the “current session” should be defined as the “time I started using it”, where several hours of “quiet time” is sufficient to inaugurate a new “session”.

Edit and Publish

The ability to add nodes within the message hierarchy, to edit them, remove them, and rearrange them combine to blur the distinction between a message (something you send) and a document (something that you edit and revise). The value of the system for evolving knowledge depends on erasing that distinction.

Ideally, the system will allow you to make changes locally, and then publish them at one time. As a corollary, the system needs the ability to “re-sync” — to undo local changes by replacing the original version of a message, using the local version when present, or retrieving it from the network when it is not. This function depends on versioning and on having a distributed system.)

Structured discussions

When carrying on a design discussion — or an investigative discussion of any nature that has decision making as a significant goal, you need the ability to pose questions, list alternatives, discuss them, evaluate them, and make a choice. In The IBIS Manual: A Short Course in IBIS Methodology, available at https://www.gdss.com/wp/IBIS.htm, Jeff Conklin provides an excellent description of the principles underlying such structured discussions in an “Issue-Based Information System”.

One participant in a moderated, IBIS-style discussion noted that its overall effect was to make people relax. Because every proposition was posted as the response to a question, there was always room for alternative viewpoints. And because each alternative was listed, and because no decision was made until all alternatives had been visited and evaluated, participants knew that their views would eventually be heard.

The ability to carry on such structured discussions online depends on the existence of categories. For an IBIS-style discussion, categories are needed for queries, alternatives, argument for, and argument against. There may well be other useful models for structured discussions. A community’s ability to define a conversational model and use it therefore depends on their ability to create and use categories.

Note:
When such systems are automated, however, users frequently complain about the need to define categories for their thoughts. Having to stop and select a category presents the user with a momentary disruption of the thinking process that is more of a hindrance than a help. There is also the issue of cognitive overhead discussed at https://web.uvic.ca/~ckeep/hfl0098.html. It seems clear then, that it should be possible to add nodes to the system without categorizing them, and add the categories later. In XML terms, the implication is that categories must be implemented as attributes of elements, and not as element types.

Decision making

When it comes to making a decision, the ability of the system to record and present ratings is extremely helpful. Whether the decision occurs as a result of a vote or by fiat is a social decision. Ideally, the system would someday interact with Jon Bosak’s notion of an automated parliamentary system, so that highly political discussions could take place in hopefully rational fashion, asynchronously and online. For the moment, though, we’ll assume that the decision is made by fiat, after the ruling czar reviews all the inputs.

In addition, it is frequently necessary to restrict the number of participants in the decision-making progress, if only to make any headway. For that, it must be possible to restrict messages to a subset of the original list, exposing the discussion only after the decision has been made. (A wide-open democracy is a wonderful concept, but at times it’s a formula for inaction.)

Having made a decision, it is important for the system to reflect that fact. Where before there was a question, under which several alternatives were proposed, each of which contained arguments for and against, and evaluations, there should now be only the selected node. The original question, the alternatives, and the discussion should all exist under that node. Should it become necessary to revisit the decision, the information is available. But the discussion should no longer clutter the view of what it is we have decided to do.

In current messaging systems, in contrast, any meeting of the minds that occurs is buried down near the bottom of the discussion. Anyone viewing the history is treated to the entire discussion as a matter of course, rather than having the ability to see the final result first, and only pursuing the conversation if interested. As a result, it’s hard to mine the information in the system for reuse later. You can’t easily find the alternatives that were considered, or the reasons for rejecting them.

A design discussion will, over time, visit many topics. If each the hierarchy remains constant for each thread, as they do in current message systems, it becomes increasingly impossible to see what the results of the discussion have been. The ability to invert the hierarchy is essential to minimizing the top-level view so that it reflects the highlights of the discussion. (Among other documents, source code will ideally contain links to those decisions one day, making clear the reasons for the otherwise inexplicable “mystery code” that appears there.)

Convergence capabilities

Current systems present an ever expanding body of messages that never converges in any meaningful way. Like the problem of redundant headers and migrating discussions, lack of convergence is an issue that is eloquently discussed in Jim Hewitt’s Beyond Threaded Discourse. (The graphical solution he proposes may or may not be effective, but the analysis of the issues is superb.)

The capabilities discussed so far will help significantly to ameliorate the convergence issue. In particular, the ability to hoist a decision so that it becomes the root of that subtree will a long way towards making it clear where convergence of opinion has occurred.

But as a preliminary step towards achieving convergence, summaries are often posted. But such summaries are problematic. If they are posted under the original heading, they are buried. And if they are posted as a separate message, they are detached — they now begin to attract responses of their own, and the discussion fragments into separate areas.

If the summary attempts to synthesize multiple threads, the situation is even worse. The proposed summary is no longer attached to any of the threads that preceded it. It accumulates many responses, as do the original threads. Big time fragmentation.

A summary, therefore, needs to subsume the entries it summarizes. In other words, those entries must become subordinate to the summary. Of course, there may well be disagreement over the summaries. The system therefore needs mechanisms that supports the delivery of “trial summaries” — one which allows the original discussion to remain in view while competing summaries are developed. At some point, though, the original discussions should be “pushed down”, hidden under the summary or summaries that represent them, so that the high level view remains as clean and simple as possible.

Note:
The issue of convergence is a difficult one, especially from an interface perspective. It needs much more study and analysis. But some mechanism is clearly needed that will allow us to simplify our discussions over time, as well as complicate them.

A Matrix of Possibilities

To summarize the characteristics of an effective communications tool — one that builds on email’s strengths, but one which is an even better vehicle for serious discussion — this section presents a matrix of Functional Requirements (rows) and Structural Requirements (columns) for an ideal system. A mark appears in the matrix everywhere that a functional behavior depends on the structural requirement represented by that column.

The value of this matrix is largely as an evaluation tool. If a communications system (or a design for one) leaves out one of the structural requirements, you can scan down the column to see which functional behaviors are precluded.

Structural Requirements

These are the columns in the matrix that follows:

Functional/Structural Matrix

Summary

E-mail provides a valuable user-interaction model for an online discussion tool, but current systems suffer from insurmountable problems, mostly stemming from the impoverished structures they manipulate. Adding structure to email messages presents a significant improvement in the capacity for online dialogue, all by itself. But incorporating the right kind of information in that structure allows the development of qualitatively different kinds of discussion tools.

References

• Eric Armstrong.
  Doug Engelbart’s NLS System (review of 1968 video)
  https://treelight.com/software/collaboration-system/video-review-doug-engelbarts-nls-system/ 
   
• Jeff Conklin.
  The IBIS Manual: A Short Course in IBIS Methodology
  https://www.gdss.com/WP/IBIS.htm
   
• Douglas Engelbart
  Toward Integrated, Evolutionary Office Automation Systems
  https://www.bootstrap.org/augment-71279.htm
   
  Bootstrap Alliance.
  https://www.bootstrap.org
   
  Open HyperDocument System development page:
  https://www.bootstrap.org/ohs
   
• Jim Hewitt. Beyond Threaded Discourse
  https://csile.oise.utoronto.ca/abstracts/ThreadedDiscourse.html
   
• Christopher Keep, Tim McLaughlin, robin
  Review of IBIS systems: https://web.uvic.ca/~ckeep/hfl0104.html
  Cognitive Overhead of IBIS systems: https://web.uvic.ca/~ckeep/hfl0098.html
   
• Traction system (visual walkthrough)
  https://www.twisted-systems.com/slides/readermov.swf

Copyright © 2000-2017, TreeLight PenWorks

Please share!