Presentation Features of Text-based Conferencing Systems on the Web
Presentation Features of Text-based Conferencing Systems on the WWW
by Daniel LaLiberte and David Woolley
May, 1997
Copyright © 1997 by Daniel LaLiberte and David Woolley. All Rights Reserved.
An abridged version of this article appeared
in the May 1997 issue of Computer-Mediated Communication Magazine.
Abstract
We survey the variety of presentation features supported by existing web-based asynchronous conferencing systems, examine why some features are absent, and consider the prospects for the future. We use existing conferencing systems as examples of these features. A recurring theme is the implications of structuring forums with either flat lists or threaded trees of messages.
Text-based Conferencing on the Web
The essence of a conferencing system, as we define it here, is that it must allow users to read text messages in a forum and add messages to the forum. A forum is a place where people come together to discuss some topic. Many variations on this basic theme are possible, such as text with graphics, structured dialogs, and gateways to other conferencing systems.
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?
This paper focuses not only on how web-based conferencing systems are structured but how they could be better structured, given changes to the web. We attempt to generalize across the great variety of features in existing systems, so the focus is rather broad. But we ground the discussion by returning to how these systems can be implemented in the context of the World Wide Web.
One issue we don’t deal with much in this paper is access control. Clearly this is an important issue, but it is just as much an issue for collaborative document management systems in general, of which conferencing systems can be considered a special case. The documents in a conferencing system are messages, and the presentations of more abstract objects such as “discussions”, “forums”, “indexes”, etc. Access to these documents can be controlled via the familiar concepts of membership in groups and roles of participants. A few specialized roles are supported by many conferencing systems, such as a “host” or “moderator” who have special powers over events in a forum. Anonymity might be permitted in a conferencing system, but not usually in a document management system. For the most part, access control is not particularly different for conferencing systems.
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.
Next we look in more detail at how messages and replies may be posted, and how users find out about new postings. Finally, we look at how forums change over time via manual reorganization or automatic purging.
Star vs Tree Structures
There is one important feature concerned with the basic model or structure of discussions that affects many other aspects of a conferencing system, so it is introduced here first and each subsequent section describes how other features are affected. All conferencing systems present some context for the users within which messages are organized, but there are many variations on that theme.
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 discussion. 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]
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.
Presentation of Forums
On the web, users can visit a forum on a server and submit messages to the forum via their browsers. A forum typically has a URL – resolving the URL results in a document that may describe the forum and contain references to the discussions in the forum. The forum document also may contain forms or links for performing actions relative to the forum such as composing and submitting messages.
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
Tree-structured systems always have an index or outline of messages. By contrast, star structured systems always have an index of discussions, but only rarely do they have an index of individual messages. So both tree-structured and star-structured systems will usually show a list of some kind of thing within forums, either lists of discussions, topics, messages, or replies. These lists are the subject of this section.
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.
Some systems use a default title for replies of the form “Re:<original title>” which does not give any hint about how the reply is unique. This practice is actually encouraged for Usenet and email postings, where it may make sense. Usenet postings may be found or ignored more easily if they have common titles, and email programs typically lose the context of messages entirely if not for the common titles.
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.
Reading Messages
The real information in a conferencing system is in the text of the messages, and the lists and outlines of forums, discussions, and messages are just ways of getting to the messages. There are two distinct styles of displaying messages: one message per page, or a continuous stream of several messages. With a single message on a page, some way must be provided for the user to get from one message to the next; navigation is discussed in the next section while most of this section is about displaying several messages at once. This streaming feature has many names including inlining, digesting, embedding, and expanding.
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 hybrid 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.
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
The concepts of presentation and navigation are intimately connected. Whereas “presentation” is how each page, perhaps containing references to other pages, appears to the user, “navigation” is how the user gets from one page to the next, perhaps via references to other pages.
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
Another important option for presentation is sorting the lists and messages by various criteria.
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 changeable 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.
Filtering and Searching
Instead of viewing all available messages, the user might want to filter messages or automatically search for messages that match some criteria. For example, one might want to never show messages by certain individuals, or inversely, automatically include only messages by certain individuals. Filtering and searching might be based on the full text of the message or on any of its metadata (e.g. title or author); it might allow boolean combinations of terms or proximity conditions; it might permit relevance feedback to refine the criteria. It might be applied on all messages in a particular forum or a collection of forums, or it might be narrowed to a set of messages selected by some other means. In general, all the same capabilities of a search system for normal documents might be available in a conferencing system where each message is a document.
Conferencing systems put an additional requirement on searching support. Since additions to the messages in an active conference happen frequently, this means that indexing of the messages should be done incrementally to avoid reindexing the whole set of messages each time.
If readers find they frequently need filtering and searching to make effective use of a set of forums, that could be taken as a sign that the forums need some reorganization to facilitate more effective reading and browsing.
Customization
Customizations are changes in viewing options that apply to particular users or groups of users and that persist for some period of time. Customizations are important to support in some form because each user has different preferences and needs at different times and for different forums. Furthermore, a group of users of a forum may wish to customize how the forum appears to any member of the group, by default or of necessity. For example, a customization might say that only the top level messages in a forum should be displayed by default as opposed to the full outline. More detailed customizations might indicate which messages in an outline are expanded or contracted.
Customizations can be implemented in several architecturally different ways. They might be stored between sessions or they might apply only during the current session in which case they would be lost when the session ends. For the current web, sessions only exist in the sense of some state being passed back and forth between the client and server since connections are dropped after each request. The state might be made visible as parameters in the URLs, which is not desirable, or it might be hidden in the additional headers or content passed with each request and response.
Customizations stored between sessions could either be stored on the server or on the client. Storing customization data on the server might have scaling problems if there is a large amount of data or a large number of users. Also, in order for a server to know which customizations to apply for each user, it must know who the user is or what group they are a member of (for group-level customizations). With current web security mechanisms, this means that readers who want to use customizations cannot be completely anonymous to the server.
Customization data might instead be stored on the client side, but the only mechanism to do that now is “cookies” which are relatively small strings associated with collections of URLs for a limited period of time. Another possibility is to store data as parameters on the URLs themselves, but the user must manually save such URLs, for example as bookmarks, and select them later. In the future, Java applets might be given limited, secure access to specific disk space for storing customizations.
A potential disadvantage of storing customizations on the client side is that they might not be available independent of what computer a user logs in on. For example, if you are traveling and want to check in on the conferences you follow using someone else’s desktop, your customization data (and information about what you have read) may not be available. This problem can be worked around by essentially setting up a home-base server accessible to the user wherever he currently is. Keeping the customizations centralized, with respect to each user, is better also in that each of the different forums located on many different servers need not store their own copy of the user’s customizations and any changes are applied to all forums automatically.
While living within these usability and scalability constraints, several web conferencing systems support customizations on a per-user basis. Typically, server-side storage is used so users must first authenticate.
Writing messages
What can one reply to?
A reply to a message may be concerned with the message as a whole, but more often writers wish to reply to particular parts of messages, either at the paragraph level or individual sentences, phrases, or words. Most systems support replying only to the whole message and writers may work around the deficiency by quoting the parts of messages they really want to reply to, sometimes with the help of automatic quoting of the whole message using a prefix string on every line. This is true of Usenet and email systems, and several conventions for quoting have been adopted by users.
Some systems allow the user to write replies that are attached to the end of a paragraph or at arbitrary places within the text. With HTML representation of messages, it is feasible to use hyperlinks to indicate within a message the presence of replies. Mother Jones Live Wire is an example of this kind of system. The author of a reply enters a unique text string contained in the message; this string is turned into a hyperlink pointing to the reply.
But HTML links have several limitations that make them impractical for this purpose. Links cannot be overlapped, so if two people reply to overlapping parts of the text, this cannot be presented accurately. A workaround is to insert a single link point or icon at the end of the text being replied to. Another deficiency is that links can only be clicked on to bring up an entirely new page – one cannot just get a hint about what replies exist, such as a list of titles and authors. Java or JavaScript might make it practical to popup a small window listing the replies, or to display something in the margins.
In the opposite extreme from replying to parts of messages, star-structured systems only allow a reply to be added to the end of a linear sequence of messages, and thus it is typically not specified whether the reply is regarding the last message in the sequence or to some other earlier message. People will generally make it clear to the reader what they are replying to, but some systems let the author make an explicit reference. Motet lets you embed a link to another message in your message text; the link can refer back to an earlier response in the same discussion, or even to a message in a different conference.
What can one reply with?
A reply to a message may take many forms, from text to graphics to arbitrary attachments. Plain, unformatted, ASCII text is the most familiar, but one variation is whether long lines are automatically wrapped, as Macintosh and Windows users expect, or left as is, as Unix users expect. Unix users are also familiar with programs that fill short lines of paragraphs (this is like appending all the lines into one long line and then wrapping it). Paragraphs are usually indicated with an extra blank line.
The HyperText Markup Language (HTML) is an obvious text format to allow web users to enter, but there are several concerns. Should properly formatted HTML be enforced? If it is not, the display of a message could affect all following text in the display. A message writer might – deliberately or inadvertently – write an HTML message in such a way that it is disorienting to readers. It could contain elements that mimic or conflict with structural or navigational elements of the conferencing software itself.
Somewhere in between plain text and general HTML is text with simple markup that is processed to result in an HTML document. One example of this simple markup is Web Crossing’s Quick-Edit where users may indicate format changes with control characters at the beginning of each line. Another example, called “Smart Text” in HyperNews, not only fills and wraps lines of paragraphs but also selectively causes some lines of paragraphs to be preformatted. Such lines have a common prefix or begin with space or tabs. This feature is useful when the user is quoting code or text for which the formatting should not be changed.
To facilitate quoting, the text of the message that is being replied to could be inserted automatically in the text of the reply that the user edits. Several news readers and email systems support quoting in this way, but few web conferencing systems do. One reason, perhaps, is that the text editors built into current browsers for editing the text in a form field are too primitive to properly deal with quoted text. The user is effectively encouraged to do the minimum, which is to leave more of the quoted text in place even if it is irrelevant. Java and other browser extensions are likely to change this situation, however.
But HTML itself does not provide adequate quoting mechanisms. The BLOCKQUOTE tag is typically rendered with indentation, but there is no way to specify some prefix text to label each line of the quote, as is used to great effect on Usenet and in email. Furthermore, nested quotes, where a quote contains another quote, are not always rendered with deeper indentation. Many would argue that this is an advantage because it discourages deeply nested quotes which are generally confusing.
But note that excessive quoting tends to disrupt the flow of conversation, waste space, and obscure one’s own message. Quoting is necessary to establish context in email since messages from all sources are typically displayed in one mailbox. But it is much less needed if the context can be preserved. This is the case in a centralized conferencing system (such as most web-based systems) where each posted message is instantly assigned a fixed location in a discussion – the same context is visible to all users.
Another feature typical of web conferencing systems is automatic anchoring of text that appears to be a URL or an email address. Also common is making some text use bold, italics, or a larger font.
Systems that allow HTML formatting generally permit inline images to be included, since this is one of the more attractive characteristics of HTML. These images are referenced by an explicit URL that is known to the author, and each reader’s browser fetches and displays the inline image. Any other HTML tags might be allowed, but there is a danger, just as in web publishing in general, that not all readers, using their preferred browsers, will see what the author intends.
Instead of entering any text for a reply, the author might be allowed to enter a URL for a document that contains the reply. HyperNews supports this feature not only for replies but also for the initial message that describes a forum.
Another feature that may gain popularity on the web is to let the user specify one or more files to upload, as attachments to a message or reply. File uploading is supported by Netscape and more browsers are expected to support this valuable feature, partly to support web publishing in general. These files may be stored on the server and included inline in the message or referenced via hyperlinks.
Some systems restrict the kinds of messages that may be submitted as replies. For example, an announcement may not need any replies, and a bug report may have a reply which is a change report, but not another bug report. In the WIT system, a “topic” is a message that can only be followed by “proposals”, and each proposal, is only followed by messages that “agree”, “disagree”, or are “neutral” regarding the proposal.
Learning about New Messages
The primary interest of regular readers of forums is just the new messages created since the last time they visited each forum; that is the subject of this section. To find out about new postings in a forum, regular readers need to either revisit the forum periodically or be notified somehow. If we rely on the initiative of readers to visit the forum, then we need additional support by the forum software. Either the user must remember when they last visited the forum, which is unlikely to be accurate, or the server must remember for them. One disadvantage of having the server remember is that users cannot be anonymous to the server.
But note that a user may not be able to read all new messages in a forum each time they visit, so it is not sufficient to record only one “last visited” date per forum. Instead, the server must remember which messages the user has or has not read. This record might be compressed to sets of ranges of message numbers, and the user can further compress it by “catching up” for the whole forum, which indicates that all messages have been read even if they have not. Such techniques are used by Usenet news readers and the “.newsrc” file stored in each user’s home directory. But now we are considering whether forum software on HTTP servers should store similar data for each reader of the forums on that server. Unless the number of users is sufficiently restricted, this becomes a scalability problem since the storage requirements for each message could grow in proportion to the number of users.
But there is a further problem in requiring users to visit the forums they want to follow. A user may want to follow a large number of forums on different servers. Forums may be relatively inactive, but once some activity starts on one of the forums, it is often important to jump in quickly to be considered a participant and to keep the discussion alive. It is impractical to require most users to visit many such forums on the off chance that some activity has started in a few of them. Client-side “agents” could do this check automatically but this would load the servers unnecessarily.
In contrast to relying on users to visit the forums, the servers of forums can actively notifyusers when something has been added. There are several ways this notification might be done. Netscape’s “server push” might be used to synchronously notify users, but there are several problems. Briefly, users must remain connected to all systems with forums, or each system must queue up notifications until users reconnect, both of which may cause scalability problems with large numbers of users. A good way to solve this scalability problem is replication of forum servers so that each server is only responsible for a smaller number of users local to it.
Instead of requiring users (or their agents) to connect to servers to receive notifications, the servers can asynchronously notify the users. A notification might simply indicate that there is a new message, or it might include the message itself. Email is a well established mechanism for the delivery of messages that has the advantage of not requiring both the sender or receiver to be available at the same time as long as some intermediary is; the mail is stored and eventually forwarded to its destination. Email has a big disadvantage in that email from all sources is typically sorted by the arrival time and so the context of each message is not visible, although some mail programs allow one to automatically sort incoming messages into various folders. But this is a problem with current mail programs, not the delivery mechanism.
HyperNews supports email notification, and the gateway to email is actually bidirectional so users can reply via email instead of having to revisit the HyperNews forum on the web. Users can subscribe to be notified not just at the level of each forum but also for specific subtrees of messages. A user who writes a message is automatically subscribed to receive any replies to that message.
A promising direction for future research is the merging of web forum services, email readers, and Usenet news readers. Some integrated email and news readers are starting to appear, such as Newswatcher for the Macintosh and Gnus for Emacs. Hybrid services that maintain and provide access to messages either via the web, email, or news readers will close the loop. Users should be able to see just what is new for them, but within the context of related messages. If a user no longer wants to follow a discussion, simply deleting the references to unwanted messages should automatically unsubscribe the user.
Reorganizing
One of the more obvious characteristics of human users is that we make mistakes. In a conferencing system, users make mistakes in determining the most appropriate place to post a message. Even without posting mistakes, discussions that begin focused on the designated topic may drift away from that topic. Certainly tree-structured forums tend to encourage drift in many directions, one for each branch of the tree, but even a linear conversation between two people can drift. Star-structure systems with many participants can experience extreme drift at the expense of the comprehensibility of the whole discussion. Note that drift might be quite productive even if it is in the wrong context. It is sometimes difficult to notice just when a discussion is diverging, but at some point it is obvious that something should be done about it.
But even if the discussion stays on topic, it may turn out that the topic is too broad; some people are interested in some parts of the topic and others are interested in other parts. This is frequently the case with active Usenet forums partly because it is so difficult to subdivide them. The result is referred to as a low signal to noise ratio, but it would be more accurate to call it an impedance mismatch since the “noise” is often useful to someone, just not everyone. Each Usenet reader is confronted with much more input than they can possibly process.
Rather than discouraging divergence or discussion that is too detailed by imposing policies that might discourage productive work as well, we can allow it to happen and deal with it by fixing any problems after the fact.
For all of these reasons, it is useful to be able to reorganize discussions and forums. Generally, discussions need to be split at the point of divergence. Parts of a discussion may be moved to new discussions, either in the same forum or to other forums. An active forum may need to be split into two or more new forums, or rarely, two similar forums might be merged. Sometimes a message or discussion should simply be deleted.
Another reason to move or delete messages is to move old messages or inactive discussions to a more inaccessible archive or delete them altogether. This kind of change should usually be automated as a convenience to the administrator.
If a moved or deleted discussion is still active, the administrator should probably write some note to the participants informing them of the action taken. On the web, since a message or discussion may have its own URL, users may save such URLs and attempt to use them later, long after the discussion was active. But if there has been a change in the meantime, it is desirable that the resolution of a URL should still provide useful information to the user. Automatic redirection to the current location is also possible on the web.
In a star-structure, the related messages of a subdiscussion might be spread throughout a discussion, so the administrator first selects the individual messages to be moved. In a tree-structure, divergent discussions tend to be already grouped into subtrees since each message is potentially the start of another discussion.
References
- Allaire Forums
- Caucus
- The Forum News Gateway
- HotWired’s 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 World Wide Web Unleashed
- 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(Replace this parenthesis with the @ sign)ncsa.uiuc.edu) is with the National Center for Supercomputing Applications and David Woolley (drwool(Replace this parenthesis with the @ sign)thinkofit.com) is with Chrysalis Software, Inc.