Magazine

Presentation Features of Text-based Conferencing Systems on the WWW

by Daniel LaLiberte and David Woolley

Abstract

Text-based Conferencing on the Web

Other kinds of "conferencing", voice-based teleconferencing and video-conferencing, are not considered in this survey. We also don't consider "chat" types of systems that provide synchronous or immediate updates even though they are largely text-based. Several largely orthogonal issues are not considered in this paper on presentation features, such as customization, security, searching, filtering, and notification.

A conferencing system is web-based if it uses WWW browsers and servers to provide most of the conferencing functionality. Systems that work with unmodified browsers and servers are of more interest because they have the potential to be widely adopted, but there are undeniable advantages to adding capability via specialized clients, extensions, and plug-ins. The current HyperText Transfer Protocol (HTTP) and HyperText Markup Language (HTML) standards have limitations that make many desirable capabilities difficult or impossible to offer.

We will also compare some non-web-based conferencing systems such as Usenet, and mailing lists with web-based systems. Although technically, usenet news and email are already part of the web since they have widely supported URL schemes, there is still a large difference in the tools used to support each and the kind of service provided. Consider that Netscape Navigator provides a web browser separate from the news reader and mail reader. Even Lotus Notes is joining the web via gateways to Notes servers and Notes clients that are also web clients. But again, the question is: What can be done with most web browsers today?

The paper is organized as follows. First we discuss a major categorization of conferencing systems into star-based vs tree-based since it impacts many of the other features. Then we discuss the related concepts of presentation and navigation, including how forums, discussions, and messages are displayed and how users interact with the system to read messages.

Star vs Tree Structures

In a "star" structured system, a forum is usually composed of a top level list of the active "discussions", and each discussion has a linear list of messages sorted by the time they were posted. In a "tree" structured system, there is also a top level list of active discussions, but each message in a discussion is followed by its own list of replies, and each reply can have a list of replies, etc. Tree structures are often called "threaded discussions", but this is confusing because star-structured discussions are also often called "threads". We will avoid the "thread" terminology in this paper.

Proponents of star-structured discussions argue that they are easier to navigate and easier to understand because they more closely resemble real-life conversations where one person speaks after another. In contrast, proponents of tree-structured discussions argue that they allow the inevitable drift in conversation to occur and readers can more easily skip past the parts they are not interested in.

One useful way to think about the tree-structure vs. star-structure distinction is as a difference in focus. A tree-structured system is designed with an assumption that individual messages are the important units: typically, each message is titled, there is some index that lists all the individual messages, there are ways to choose which messages to read and which to skip, etc. But a star-structured system doesn't ascribe as much importance to individual messages; instead, the emphasis is on entire conversations (which are variously called "topics", "items", "discussions", etc.) There are typically no titles on individual messages; there is only a title for each topic. There is usually no index of messages within a topic. You can choose to "forget", "freeze", delete, or move whole topics of discusion. Of course there are options for manipulating individual messages in various ways, too, but these receive much less emphasis than in a typical tree-structured system.

Some systems provide no structure whatsoever, other than ordering all messages by time; these are usually called guest books, free-for-alls, or chat systems. Both star-structured and tree-structured systems provide some structure to forums although in different ways. But there is more to a conferencing system than any particular structure. Forums provide a context or a sense of place that sets the stage for the collaboration between participants. Certainly the kind of structures imposed on users by the system influences the look and feel of a forum, but the need to communicate will often transcend any deficiencies. It is really the participants and their contributions that make or break a forum.

Both star and tree systems are exemplified on the web; a list of most of them is available at [Woolley]. Most conferencing systems support either one or the other type of structure but not both. Software that comes out of the Confer/PicoSpan/Caucus lineage has linear conversations. This style of presentation is used by many Web conferencing systems, such as Motet, Caucus (see Figure [Caucus]), Web Crossing [Crossing], Backtalk, COW, Yapp, HotWired Threads, etc. One might call these "WELL-style" systems because the WELL has been so influential in spreading this style. [WELL]

# Title (select to see entire item) New Last 1 Introduction to this Demonstration conference. 0 0 2 Introduction to Caucus: Conferences, Items, & Responses. 2 2 3 Add A Response Yourself 49 49 4 WWWCOOP discussion: Browsers and HTML Language 17 17

Usenet is the most well-known system with a tree structure, and some web systems, such as the Forum News Gateway [FNG] map the Usenet structure and data directly to the web. Email archive systems such as Hypermail [Hypermail] reflect the tree structure of email messages, to the extent that they can. Entirely web-based systems can impose additional structure on discussions as well as using HTML capabilities. For example, WIT forums have a list of "issues" for which several "proposals" may be posted each of which are followed by a tree of arguments.

Some systems attempt to bridge the gap between the star and tree models of conferencing. Some star-structured systems provide several levels of structure before a flat list is reached. For example, NetForum [NetForum] has forums composed of topics composed of messages followed by a linear list of replies. A different kind of hybrid is Web Crossing [Crossing] which allows forums to be composed of nested forums, called folders, as well as linear conversations, as shown in Figure [WebX]. HyperNews is building the bridge from the other side since it supports trees throughout, but it uses an abbreviation in the presentation of discussions that happen to be linear. Figure [outline] later in the paper shows part of an outline of HyperNews messages that uses this abbreviation.

Cookbook (20 discussions) Design Issues (4 discussions) Revision History (24 discussions) Features: Questions and Answers (127 messages) User Interface Enhancements (72 messages) General User Interface Wishes (55 messages) Bugs and centipedes (55 messages) Sites using Web Crossing (14 messages)

Presentation of Forums

Typically there are several forums, one for each major topic of discussion. And within each forum, there will typically be several minor, more focused topics of discussion, each one called a "discussion" or "conversation" in this paper. In tree-structured systems, every message can potentially be the start of a new discussion. This distinction between major and minor topics is arbitrary, but it is reflected in some form by most conferencing systems.

Users need to determine which forum they want to use, so there should be some list or directory of forums, probably with descriptions of each, that the user can browse or search through. If all forums that exist are known to the system, a single list is possible, but this is not very appropriate if the list is very large. An automatically generated list of forums has the advantage of possibly providing up-to-date information about the status of each forum, such as the number of discussions and new messages.

To manage a large list of forums, a hierarchical organization of the forums into topics and subtopics is often used, much like the hierarchy of usenet groups. This suggests that one should provide a hierarchical browser much like many filesystem browsers. The Netscape news reader is an example of this type of browser of news groups, of which there are thousands. A complication is that there is not just one way to organize this hierarchy because many topics logically belong in many places in the hierarchy.

Another complication is that current browsers provide no way to incrementally modify the view of an outline, such as an outline of forums, nor does HTML provide a way to indicate that this should even be possible. One alternative is to appear to expand or contract an item of an outline in-place by requesting a new version of the document from the remote server each time the view of the outline is changed. These many alternative views are less likely to be found in a local cache, so the network and server load are increased and the responsiveness to users is decreased. [Hierarchy] argues that we shouldn't sacrifice usability even if there is a moderate performance cost. JavaScript can now be used to generate alternative views of an outline from a locally cached copy, but currently, only by regenerating the whole page rather than incrementally modifying it.

Another alternative is to break up a large collection of forums into several separate pages that each list a few related forums. This also allows us to break away from the strict hierarchy so each page may refer to any related forums that the maintainer feels are appropriate, whether they are on the same server or located elsewhere on the web.

Lists and Outlines

For each item in a list, usually only some information about the item (some of its "metadata") is shown, not the whole item. If the items in a list are discussions, as in many star-structured systems, the metadata might include the topic of the discussion and how many old and new messages are in the discussion. Sometimes the topic of a discussion is defined by its first message, and thus the list of discussions is similar to a list of messages, with additional information about each discussion [e.g. HotWired Threads]. If the items are messages, the title, author, date and other summary information about each message might be shown, but not the whole body of the message. (Inlining the whole body is discussed in the next section.) Instead of a title specified by the author, a small summary or the first line of the message might be used.

In a tree-structured system, an outline view of messages is appropriate because that reflects the recursive structure of the discussion. But the basic outline can be modified in several ways. For example, any part of the outline could be expanded or contracted. But as discussed above, current web browsers provide no support for incremental, in-place expansion or contraction of outline items. Redisplay of the whole outline with parts expanded or contracted is possible, but that would be time consuming for a large forum. Alternatively, the depth of the outline as a whole could be changed, as supported by HyperNews. The user can select the desired depth, or select "All" to see the full outline. In Figure [outline], the depth is set to 3, so a part of the response outline that is deeper than that is ellided.

HyperNews also uses an abbreviation in the special case of a reply to a reply to a reply, etc. This linear sequence of chained replies would normally be displayed with each reply indented below the previous one. But since this occurs frequently, an abbreviation is used in which all the subsequent replies are displayed at the same indentation level with a "->" prefix. Figure [outline] shows an example of this.

Messages Inline Depth: Outline Depth: 4. Navigation (Manfred Humphries) - 6/26/95 1. Going Back (Roberto M. Melo) - 6/26/95 -> Need to go to "Next" from indented responses - 6/28/95 -> Next button not necessary. (Axel Boldt) - 9/11/95 -> But next-in-thread is useful (Daniel M LaLiberte) - 9/11/95 -> Yes, and maybe context-sensitive? (Axel Boldt) - 9/12/95 6. Embedding Responses within existing HTML file (Doug Dunlop) - 9/29/95 1. Turn the problem in another way (Frederic Goudal) - 9/29/95 1. Embedding and Wrapping (Daniel M LaLiberte) - 9/29/95 ... 2. Mostly implmented (Daniel M LaLiberte) - 9/29/95 1. Re: Mostly Implemented (Doug Dunlop) - 9/29/95

Reading Messages

Displaying a stream of messages lets a user see a set of related messages that can be scrolled through without having to select each one. If most messages will be read, this can save a lot of time because each request for a message must open a new connection and wait for the response. On the other hand there is an increased danger from badly formatted HTML messages interfering with the formatting of all following messages.

Star-structured systems tend to stream messages or responses. It makes sense to do so to improve performance, but moreover, because the discussion is intended to be read as a continuously flowing conversation. Also, streaming makes the context of each message more readily available; you can easily glance back up at the previous message for reference; very likely it's still on your screen! Figure [stream] shows an example using the Caucus system of a collaboratively produced limerick. Many star-structured systems only show lists of discussions and streams of messages in a discussion. One hibred between the list and stream is Motet [Motet] which allows the user to first select from a list of the messages in a discussion, and then just those are streamed.

11:16) [Seen] 27-SEP-93 13:29 Clif Flynt The problem with adding line five 11:17) [Seen] 27-SEP-93 13:47 Charles Roth With only four people who strive 11:18) [Seen] 28-SEP-93 8:03 Will Jaynes Is, you think and you moan 11:19) [Seen] 28-SEP-93 15:07 John But by four you're alone 11:20) [Seen] 28-SEP-93 15:04 John And the ending is yours to contrive.

Tree-structured systems usually display one message per page, partly because they emphasize individual messages as opposed to discussions. But some systems also support inlining. An obstacle to readability is that an inlined tree of messages does not read like a conversation since a reply to a message might appear much further down the page. The inlined messages may be indented, just as in the outline display, to show which messages are replies to what, but deep indenting tends to interfere with readability. "Threads" in Allaire Forums are displayed with an outline followed by the inlined, indented message bodies; clicking on a title in the outline jumps the page to the corresponding message. HyperNews inlines messages without indentation but each message identifies what it is a reply to. The user can inline all messages in a subtree recursively, or just the top level messages and any replies to those messages are shown in outline form.

Another way to display a message is in the context of information about all related messages. These could include replies to the message, sibling replies to the same thing, ancestor messages that it is a reply to, and all replies to those messages. One way to think about this is to imagine an outline display of messages with just one message expanded inline at a time. But again, this is difficult to implement on a large scale with current web browsers since the whole display must be regenerated each time. HyperNews uses a limited form of this context display by showing the list of ancestor messages before the message and the reply outline after the message, but it does not show any sibling replies. Similarly, Web Crossing, with its nested folders, shows messages in the context of the list of ancestor folders.

Navigating to Neighboring Messages

Readers typically wish to read not just one message but several related messages. Traversing through the related messages is referred to in this paper as "navigating". Note that navigating is largly irrelevant when related messages are displayed inline, as described previously. But one must nevertheless navigate from one display of inlined messages to the next.

When one message is displayed on a web page, the messages related to that one may be referenced either explicitly with their titles, authors, etc, or implicitly as described by "Next" and "Previous" links. These anonymous links to neighboring messages are effectively commands that might be bound to keys in other conferencing software, but current web browsers do not permit any key binding. (Future developments using Java or JavaScript might support key bindings.) As it is, the only way to navigate with current browsers is through these links that move around on the screen as the user scrolls the display, thus making their use cumbersome at best.

A proposed extension to HTML will allow LINK tags to express relationships with other documents such as "next" and "previous". Browser developers are free to provide special key bindings and GUI controls for these links but it will be a while before this tag is widely supported, if at all.

Another persistent problem with links to neighboring messages is that new users tend to get lost as to which way a link goes and where they are in the discussion. (A linear discussion in a star structure obviously avoids most of this difficulty.) Part of the problem is the ambiguity of terms like "next" and "previous". Does "next" mean the next thread, the next message that is a reply to this message, the next message that is a reply to the same thing that this message replies to, or the next unread message? The relationship to the neighboring message is either ambiguous or the full description is verbose; the actual title of the message often does not help either. This is not unlike the problem of being lost on the web itself. But in the case of conferencing systems, the documents are related in a highly structured way and readers want to know that they have read all that they want to.

A further problem is the time it takes to navigate through several pages, one at a time. Even if the average wait between pages is only two or three seconds, the delays become annoying when you're trying to navigate quickly through a large amount of material. Solutions for the Web's performance problems are in the works. One promising proposal is the Keep-Alive feature of HTTP version 1.1 in which a Web browser will be able to maintain an open connection with a server while it requests multiple items.

One way to speed up the display of a long list of messages is to limit the number of messages that the user can see at one time. This applies whether the messages are inlined or in an index. For example, the list of messages might be limited to 20, and if a user wants to see more, a link at the bottom of the page could be followed to see the next 20 messages. Similarly a link at the beginning of the page would take the user back to the previous 20 messages.

A recent development in browser capability, frames, permits a reasonable display of context and content at the same time. For example, HyperNews optionally uses frames to display the outline of messages in one frame and the content of each selected message in another frame. Another frame displays the forum description.

Another very good use of frames is to make some frequently-needed buttons readily available in a frame so the user is not required to scroll the display to find them. Navigation actions such as "return to topic list", "go to next conference in your hot list", "go to list of conferences", etc., are possibilities. But note that the action for a button cannot know which message is currently displayed in another frame, so a "next message" button cannot be implemented in a straightforward manner. However, JavaScript does make this possible.

Sorting

Sorting by date lets users look for just the newer messages since they will be together at the end of the list. Reversing the order displays the newest messages first, which is more useful if not all of the messages are to be displayed - the user might interrupt the transfer of messages, or perhaps only a range of messages will be displayed at one time.

Star-structured systems typically always present messages in a conversation sorted by date; you would be unlikely to find any alternatives. But sorting the list of discussions makes sense. Typical options would be to sort by topic number (a low number typically means the topic was created earlier), by number of responses, by number of new responses, or by date of last response.

If we sort a tree-structured discussion by creation date, the result is similar to a star-structured linear conversation, but when a reply to an earlier message is added at the end of the list, the reader will tend to lose the context unless there are sufficient clues.

Sorting messages alphabetically by author or title is useful if you happen to know the author or title of a message you are looking for but do not know when it was created. But this could be better done with a search service since the sorted display is primarily useful to facilitate manual searching through the sorted list, so it might as well be automated. Automatic searching can do even better by allowing many more advanced capabilities such as partial matches within the author name or title, misspellings, or conceptual matches.

Another way to sort is by the kind of message, such as Question, Problem, and Idea, or by some other changable state of the message, such as Pending, Approved, and Resolved. If these attributes of messages are available, sorting on them can be quite valuable for visually arranging all messages into groups of related messages. One can view all the groups as well as the messages in each. In the Figure [sorting], the messages are sorted by the kind of message within each branch of the tree.

Improve Electronic Mail Among Federal Agencies Agreements Government-wide E-Mail -- Brenda J. Moore [12 Dec 1994 19:46 EST] Disagreements Action vs Reports -- William H Carr [10 Dec 1994 16:20 EST] Agreements Implement Email -- Scott Morizot [11 Dec 1994 19:45 EST] It's Time to Make E-mail Easy in Government -- Col James L Vick [15 Dec 1994 23:43 EST] Action vs Reports -- William H Carr [10 Dec 1994 23:42 EST] Keep it Simple, Please -- Cooper, Larry [17 Dec 1994 16:30 EST]

[See author's version of this paper for updates or additions to the references list: http://union.ncsa.uiuc.edu/~liberte/www/collab/conferencing/features.html]

References

• Allaire Forums
• Caucus
• The Forum News Gateway
• HotWired's Threads and a Thread on Threads
• Hypermail
• HyperNews
• Motet
• Mother Jones Live Wire
• National Performance Review - Open Meeting on Reinventing Government!
• Web Crossing
• The WELL
• WIT - WWW Interactive Talk
• Computer conferencing functions and terminology
• Conferencing on the World Wide Web - A guide to software that powers discussion forums on the Web, maintained by David R. Woolley
• Conferencing on the Web from the book
• HyperText Markup Language (HTML)
• HyperText Transfer Protocol (HTTP)
• [Hierarchy] NIF-T-NAV : A Hierarchical Navigator for WWW Pages, by Kirsten L. Jones, Silicon Graphics, Inc.
• A Protocol for Scalable Group and Public Annotations, by Daniel LaLiberte and Alan Braverman

Daniel LaLiberte (liberte@ncsa.uiuc.edu) is with the National Center for Supercomputing Applications and David Woolley (drwool@skypoint.com) is with Chrysalis Software, Inc.

Copyright © 1997 by Daniel LaLiberte and David Woolley. All Rights Reserved.