Copyright © 1995 Sams.net Publishing
This is a chapter from the book
World Wide Web Unleashed.
Addendum: see Update Notes,
For additional Web Conferencing articles and resources, see the
Think of it Publications page.
First written August 1994; Revised April 1995 for the 2nd edition.
This is a chapter from the book
World Wide Web Unleashed.
Addendum: see Update Notes, December 1995
For additional Web Conferencing articles and resources, see the Think of it Publications page.
Although graffiti boards like Bianca's are fun, they're not of much practical use. But they do offer a key feature that lies at the heart of all online conferencing systems: the ability to post a message in a public place for others to read. Conferencing has been available on the Internet for years in the form of Usenet newsgroups. When support for forms input was added to HTML, it opened the door to conferencing on the Web.
What do I mean by "conferencing?" It's an overworked term, but it will have to do until something better becomes generally accepted. For my purposes, conferencing is a form of group discussion that uses text messages stored on a computer as a medium for communication. Usenet newsgroups, CompuServe forums, message boards on America Online, and Lotus Notes discussion databases are all examples. I'm not referring to real-time video or audio conferencing, nor to facilities like CompuServe's CB Simulator or America Online's chat rooms, which instantly relay typed messages between participants who are online at the same time.
Graffiti boards offer little structure for the posted messages. Each new message is simply tacked on to the top (or bottom) of the page. In this sense, these Web pages resemble the early electronic bulletin board systems that began to pop up in the late seventies and early eighties. It is possible to write a message responding to an earlier posting, but since it is just tossed into a big pot along with unrelated messages, with no connection between the original message and the reply, it's difficult to carry on an extended conversation.
For true conferencing, some structure is essential. In particular, the system must support "threading," the ability to sequentially read the messages that make up one discussion. You need to be able to read all the way through the conversation about where to get the best sushi in Boise without having celebrity gossip and announcements about used stereo equipment for sale mixed in. Several conferencing systems now evolving on the Web offer such threading. But how much structure do you need?
WIT was a quick hack by Ari Luotonen of CERN, who put it together in a few days immediately following the WWW `94 Conference. Participants of the conference desired a way to carry on prolonged group discussions about technical issues related to Web development.
The weaknesses of Usenet and mailing lists for such a purpose are well known. Mailing list discussions have no inherent structure at all, making it difficult to maintain more than one or two threads of conversation. In a Usenet newsgroup, a message can be posted specifically as a response to another message, but the overall structure tends to be rather chaotic. Also, Usenet messages typically disappear within a week or two, leaving no permanent record of what points have been raised and what issues have been settled.
By contrast, a WIT discussion takes the form of a permanent, continuously expanding hierarchical tree. The tree can branch out indefinitely, but the top three levels of the hierarchy have specific purposes and are labeled accordingly:
When you enter WIT, you see a welcoming message describing the purpose of the discussion area, followed by a list of topics. Selecting a topic takes you to the page for that topic. Topic, proposal, and argument pages all have a few things in common: a title, date, author's name, and text. They differ in what appears below the text, though. A topic page lists only the proposals associated with the topic. But a proposal page shows the entire tree of arguments branching off of the proposal. An icon next to each argument indicates its type: a white checkmark for an agreement, a red X for a disagreement. An argument page is similar to a proposal page, except that only the portion of the tree branching off of that particular argument is displayed.
The list of checkmarks and X's can give you a quick sense of how a proposal is being received without requiring you to read all of the arguments. Looks can be deceiving, though: an agreement to a disagreement (are you still with me?) shows up as a white checkmark, although it argues against the proposal!
Of course, as soon as WIT was released, the structure of WIT itself became the most popular subject of discussion. One problem noted by many participants is that each article is forced to either "agree" or "disagree." What if you want to add a pertinent comment that does neither? What if you agree with some points of a proposal and not with others? Some people suggested adding a third button next to Agree and Disagree, labeled "other" or "idea."
Another problem is that every branch off of a topic is labeled a "proposal." But some topics need to branch into subtopics rather than proposals. One participant suggested that, in addition to proposals and arguments, there might be questions, answers, merits, demerits, summaries, categories, qualifiers, and reframes. Another suggested that proposals be broken down into subproposals called "points." Yet another asked for a way to rank arguments on various scales, such as serious to humorous, or friendly to flaming.
The limitations imposed by WIT's structure become immediately apparent when you start to use it for a discussion. Most of the suggestions for improving it center on extending the structure to accommodate a wider variety of comments. Yet the more classifications that are added, the more confusing and hard to use the system becomes. Deciding exactly where to place a response and how to categorize it becomes a major chore. And inevitably, arguments develop over such choices ("that's not a summary, that's a new proposal!") Eventually, either the system will collapse under its own weight, or the participants will begin to ignore the structure and use it however they please.
Since WIT was implemented so quickly, a lot of obviously needed features were left out. For example, navigation between messages is rudimentary, and there is no good way to find messages written since your last visit. But even with improvements in these areas, WIT's structure will make it awkward for general-purpose conferencing.
The creator of HyperNews, Daniel LaLiberte, hopes that it will evolve into a next-generation replacement for Usenet. One of Usenet's biggest problems is its redundancy: Each widely-distributed newsgroup is replicated on countless news servers around the world, consuming huge amounts of disk space. Consequently, messages must be thrown away quickly to make room for new ones. This, in turn, leads to another kind of redundancy, as people repeatedly ask the same questions and hash out the same issues. Rather than building a repository of knowledge, Usenet is forever locked into a cycle of destroying and recreating the same knowledge time and time again.
A HyperNews discussion does not rely on such massive replication. It can exist on a single server, yet still be available world-wide through the Web. Since each HyperNews server only needs to host a few discussions, it should be possible to keep messages for a much longer time, perhaps forever.
LaLiberte's vision extends beyond conferencing. HyperNews, or something like it, could be used as a structure for organizing vast amounts of information. For the purposes of finding a particular piece of information, HyperNews would appear as a hierarchical tree with general subject areas near the top and finer divisions of knowledge further down. But since lateral connections between documents are also possible, the true structure would be a constantly evolving web. Some areas of the web would be mostly discussion, while others would be mostly static information, but responses would be possible anywhere. LaLiberte has some innovative, yet-to-be-implemented ideas regarding discussions, such as allowing a message to be linked as a response to multiple articles, and the ability to snip off a subtree of responses and attach it somewhere else in the web.
This is an ambitious concept, to say the least, and LaLiberte does not claim to have solved the myriad thorny issues it raises. I am less convinced than he of the value of keeping everything forever. Do we really need to save every byte posted to alt.mcdonalds.ketchup for the benefit of our children's children?
The next version of HyperNews will allow users to "subscribe" to specific articles, so they will be notified by e-mail when new responses are posted. This could be useful in keeping slow-paced discussions alive, but when a discussion becomes very active it would quickly become a burden both to the participants and to the HyperNews server hosting the discussion.
In any case, while HyperNews holds interesting possibilities, the current implementation is a bare-bones system at about the same early stage of development as WIT; that is, not ready for prime time.
LaLiberte has recently joined NCSA, where he is applying many of his ideas to an annotation system that will let readers leave comments for the owners of Web documents. Flexible access controls will allow an owner to accept annotations either from the general public or only from a specified group of people, and determine whether annotations are visible to others. If visitors are able to read and respond to annotations by other people, annotation begins to blur into conferencing.
HotWired calls its conferencing system "Threads." What distinguishes Threads from most other conferencing software is that it presents each discussion as a single stream of text, rather than as a collection of discrete messages. In this, its design was obviously influenced by PicoSpan, the Unix-based conferencing software used on the WELL.
The WELL was born in 1985, and by the early 1990's had gained a reputation as perhaps the place to find intelligent conversation online. In terms of membership, it is dwarfed by services like CompuServe and America Online, but the WELL's renown and influence are far out of proportion to its size. Many WELL adherents attribute its success in large part to the way PicoSpan structures conversations.
In Threads (as on the WELL), a topic consists of an initial message followed by a linear string of responses. There is no branching within a topic, as there is in Usenet and HyperNews. Each new response is attached to the end of the topic, rather than to a particular prior response. While reading, you can scroll through an entire topic without having to press a key or click a button to move from message to message. As a result, reading a topic in Threads feels more like following a "real life" conversation than it does in most other conferencing systems.
On the Web, there is an additional reason to design conferencing software this way. When you request a Web page, there is usually a noticeable delay while the server is contacted. A document can be transmitted very quickly once the connection is made, but still, the delays in moving from one page to another can be frustrating. Transmitting an entire topic as one document minimizes the number of separate transactions the client must make with the server. So there are fewer delays while reading messages, making the experience much more pleasant.
Threads does not keep track of what you have read, but it does let you filter messages so as to see only those written since a certain time. Unfortunately, the only way to specify the "since" cutoff is in hours. Quick, how many hours since 8:00 PM last Tuesday?
Threads has other design problems, as well. Within a conference, the topic list displays the full text of the first message in each topic. This makes the topic list itself look like a conversation, which is very disorienting. Also, the term "thread" is used to refer to what most systems call a conference or forum, and that is confusing to anyone familiar with other conferencing systems. "Thread" usually refers to a single conversation within a conference.
In the spring of 1995, Threads gained a cousin when San Francisco's two daily newspapers, the Chronicle and the Examiner, jointly opened a Web service called The Gate. The Gate's conferencing system is also modeled after the WELL. That's no surprise, given that it was created by John "Tex" Coate, who was the WELL's conferencing manager for six years.
The Gate's conferencing is not as glitzy as Threads, nor does it offer as many ways to sort, filter, and view messages. But this might actually be a benefit. While navigation in Threads can be confusing, navigating The Gate is straightforward. The Gate is less cluttered with buttons and features, yet it offers one crucial feature that Threads lacks: it remembers what you have read and shows only the messages that you havenít yet seen. The biggest problem with The Gate is its performance; moving from page to page seems to take forever.
Although both Threads and The Gate suffer from flaws, they are the first Web-based conferencing systems that display a conversation as a continuous flow. It would be good to see this become a more standard feature of conferencing software.
What distinguishes WebNotes is that it is not a standalone system, but an interface to a client-server conferencing system. In a client-server system, the client is a piece of software running on a userís computer, and the server software typically runs unattended on a centrally-located computer, responding to requests by clients. The key to a client-server application is the definition of a protocol, or common language, through which a client can access or update information stored on a server. It is a way of achieving platform independence: the server doesn't care what hardware or operating system the client is running on, and the client doesn't care what platform the server is using, as long as both client and server speak the same language. The World Wide Web itself is based on this concept, and it could never have achieved such phenomenal success otherwise.
The particular client-server software that WebNotes is built upon is a full-featured conferencing system called NetNotes, also made by OS TECHnologies. NetNotes is not the first conferencing system to use a client-server design. Lotus Notes, DEC Notes, and most other conferencing systems used in the corporate world are based on client-server technology.
A typical use for NetNotes is to allow employees of a company to communicate over a local area network. But with an Internet connection and the WebNotes add-on, a NetNotes server is capable of inexpensively hosting discussions among participants around the world. NetNotes client software is currently available only for Windows and the Macintosh, but WebNotes in effect allows any Web browser to act as a NetNotes client.
In terms of features, WebNotes/NetNotes is unmatched. It keeps track of what you have read, an essential but rare feature among Web conferencing systems. Navigation is both flexible and easy. The server includes a high-speed search engine, allowing you to quickly find messages by author, keyword, or other criteria. The user interface is highly configurable to accommodate individual preferences.
The only features of NetNotes not available through the Web interface are conference host privileges and the ability to attach binary files (executable programs, spreadsheet files, etc.) to messages. The plan is to implement binary file attachments as soon as the HTML 3.0 specification is established. One use for this feature might be to embed an image in a message. As for host privileges, they will have to wait until standards are in place for secure transactions on the Web. A conference host can delete messages posted by other people, change access privileges, and do other things that could wreak havoc on a conference. With security on the Web as lax as it is today, it would be dangerous to allow these functions to be performed over the Web.
WebNotes is not only a better performer than any other Web conferencing software available today, it is built on a foundation that is interoperable with other platforms, and that will allow it to evolve along with the rapidly changing technology of the Web.
That's certainly possible. Two different approaches have been taken: building a newsreader into a Web browser, and creating a Usenet gateway on a Web server.
Netscape Navigator is an example of the first approach. It has a built-in newsreader that is adequate for occasional browsing, but lacks many of the capabilities found in traditional, full-featured newsreaders. Mosaic's newsreader is even more primitive: there is no threading, and it doesnít allow you to post messages.
The Forum News Gateway takes the second approach. It is a server-based gateway developed by the Geometry Forum at Swarthmore College. The gateway accesses a newsgroup on demand and converts each article to HTML for display. Each user's personal subscription files, which keep track of which articles have been read, are stored on the server - a big advantage for people who use more than one computer to read news (at work and at home, say). The gateway is easy to use, and has some nice features such as the ability to highlight or kill (skip) articles about a certain subject or by a certain author. Unfortunately, it is painfully slow. This is mainly because it is written in Perl, and is implemented in such a way that it can handle only one request at a time, so the server tends to bog down when a number of users are reading news at the same time. At this point, the Forum News Gateway is a good prototype, but it would need to be completely rewritten before it could be a viable product.
In any case, it will not be possible to make the best use of the Web's capabilities through Usenet. For instance, a Usenet message could contain HTML formatting and hypertext links, but it would be readable only by other Web users. To anyone using a standard newsreader, the HTML codes would look like garbage. Furthermore, Usenet suffers from some fundamental problems, particularly the massive replication of data discussed earlier. It is also lacking in access controls and host tools for managing discussions. (The Usenet concept of a moderated newsgroup is too blunt an instrument of control and precludes fast-paced discussions.) Usenet is probably not the right model to carry forward into the future.
On the other hand, e-mail is not organized by topic. Threading is difficult or impossible, because not all mailers supply enough information to associate a reply with another specific message. Even when they do, most mail reading programs do not display messages as threaded topics. Nevertheless, mailing lists remain popular, and there have been some efforts to create Web interfaces for them.
HyperMail is one such interface. It was designed as a way to browse an archive of e-mail messages through the Web. It does so quite successfully, allowing you to sort messages by date, author, or topic and thread. Threading is often haphazard, but it works as well as can be expected.
Time-Warner uses HyperMail for discussions at their Pathfinder Web site. They have added extensions to HyperMail making it possible to post messages to a discussion through a Web form.
There is no one perfect solution for all people and all purposes. But having used a variety of systems over the past 20 years, I think I can make a few generalizations about what seems to work well.
Separate conferences for broad subject areas. This is a nearly universal feature. Whether the discussion areas are called conferences, forums, newsgroups, or notesfiles, they provide a basic level of organization. Besides focusing on different subjects, different conferences often have very different atmospheres and social conventions. People become "regulars" only in the conferences that most interest them.
Threaded discussions within conferences. This sometimes takes the form of a tree structure, in which each topic is the starting point for a branching tree of responses. For example, Usenet, HyperNews, and WIT use this structure. But while a hierarchical tree is a good way to organize static information, it does not work as well for conversation. It is easy to get lost in the tree, and often hard to figure out where to attach a response. Discussions tend to fragment and dissipate. I prefer a star structure, in which each topic has a simple chain of consecutive responses attached to it. This form is easily understood by most people because it closely resembles "real life" conversation. WebNotes and HotWiredís Threads are examples of systems that use a star structure.
Informative topic list. A reader should be able to easily see a list of the topics in a conference. At minimum, it should show each topic's title and some indication of the amount of activity in the topic: the number of responses, date of the last response, or both. The topics should be sortable both by topic start dates and by last response dates.
Respect for the integrity of topics. A reader should always be able to go back to the beginning of a topic and follow it all the way through to the most recent responses. Of course, it is necessary to clear out obsolete material to avoid clutter (and because nobody has infinite disk capacity) but pruning should be done by deleting entire topics after they have fallen into disuse. Some systems (notably Usenet and CompuServe) throw away older messages even if they are part of an active discussion.
Support for both frequent readers and casual browsers. A browser wants to choose a conference manually and scroll through the list of topics, dipping in here and there, moving backward or forward sequentially through topics, returning repeatedly to the topic list. A frequent reader wants to cycle automatically through a customized list of conferences, skipping topic lists entirely and getting immediately to the new unread messages. Most conferencing systems are biased toward one type of reader or the other; few support both well.
Search and filter tools for readers. A reader should be able to search messages by date, author, or keyword. Word searches on both topic titles and message texts should be possible. Frequent readers should also have tools for controlling what they see: for example, a way to "forget" topics so that any subsequent responses are skipped automatically.
Access control. Both public and private conferences are useful in different situations. A conference host or moderator should have flexible control over who can access the conference and what level of access each participant has. For example, it should be possible to give some participants read and write permission, others read only, and others no access. This, of course, runs counter to a widespread anarchist sentiment on the net. Anarchy is marvelous - the Web might never have evolved without it - but being unable to have private discussions among chosen friends or colleagues is just a different form of tyranny.
Host tools. The host of a conference should have good tools for managing topics; for example, weeding out obsolete topics, archiving those that are worth saving but no longer active, and moving a divergent thread of a topic to a new topic of its own.
Speed. Frequently used functions like advancing to the next message should require only one key press or pointer click and should happen instantly when selected. If the system is slow or cumbersome, people simply won't use it much.
What I have laid out here is an ideal. No conferencing software that I know of excels at everything. The systems that have been successful are those that do some of these things well enough that they capture a critical mass of enthusiastic users, who then provide the content and culture that attracts others.
For years we have been shackled to plain ASCII text. People have responded creatively to ASCII's limitations, inventing customs like smileys ;-) to express emotions and *stars* for emphasis, and even creating gigabytes of ASCII art (imagine a full-page picture of Snoopy cursing the Red Baron here.) Some will bemoan the passing of this era, but the expressive capabilities of HTML text far surpass those of plain ASCII. Many sizes of type! Real italics! Bold text! And so on.
The Web's multimedia capabilities will add another dimension to conferencing. Many of us have long dreamed of including pictures and sound in our messages, and the Web will finally make this possible. Some of the uses will be trivial: ASCII smileys will give way to full-color smiley cartoons. Some uses will be annoying (imagine every instance of "LOL" - net shorthand for "laughing out loud" - being replaced with a recorded laugh track.) But there are many situations where a picture really is worth a thousand words.
Hypertext links embedded in messages offer endless possibilities. One obvious application is to make the author line of every message an active link to the author's home page. This would eliminate the need for the long signatures often attached to Usenet articles, which add clutter and disrupt the flow of conversation. Links can reduce the need for quoting earlier messages, as well. Instead of copying the text of the message, just include a link to it.
Links could also be used to post a message in two or more conferences in which it is relevant. For Usenet readers, this probably brings up hateful images of "spamming" - the posting of identical messages to every newsgroup in the world. But if a message is linked to multiple conferences rather than replicated, then you will only see it once. If it appears again in another conference, the software will recognize that you have already seen it and skip over it.
There are practical reasons to use the Web for conferencing, also. There is an expanding plethora of Web client and server software to choose from, supporting a wide variety of hardware. Much of it is free. No proprietary system is likely to match the Web in terms of universality of service.
One of the Web's great strengths is that it provides a common user interface for Internet utilities like FTP, Gopher, and WAIS. It is natural to extend this to conferencing, as well. People should be able to reach everything the Internet has to offer without leaving the familiar environment of their Web browser.
Finally, a conferencing system on the Web can be designed to scale well. Since the data can be distributed across any number of servers, there are no inherent limits to growth.
What's new? Regular readers of a conference want to see only the new messages added since their last visit, so the system must keep track of what each reader has seen. Either the client or the server could do this, and it's not clear which is the better choice. Web servers are designed to be "stateless," that is, they simply respond to each request as it arrives and do not keep track of what clients are doing. Requiring the server to remember what messages have been sent to each client violates the spirit of the Web's design. On the other hand, client software is not "aware" of the distinction between a conferencing system and any other Web document.
Uploading. Users need to be able to upload existing files into the conferencing system, rather than always having to type messages into a Web form.
Images in messages. While the ability to include images and sound into messages is one of the most exciting features Web-based conferencing has to offer, it might also be one of the most difficult to implement. A message containing an HTML reference to an existing image is no problem, as long as the image is already available on some Web server. But how can a user get a new image to the server? Ideally, the user should be able to draw a picture with her favorite "paint" program, drag it into a document editor with the mouse, type a message, and click the "Send" button. But this will require much more sophisticated HTML document editors than exist today, as well as coordination between the Web server, the Web client, and the document editor.
Limiting HTML. It seems natural to let users include HTML markups in their messages, yet this poses a problem. If users are allowed complete freedom with HTML, they can write messages that are visually disorienting to readers, or that interfere with the functioning of the conferencing software. The display must be formatted so that structural elements of the system, such as message headers and navigation buttons, cannot be confused with the content of messages. Exactly how much formatting freedom to allow in messages is a difficult design issue.
Maintaining focus. Web sites have no obvious boundaries, and the temptation to surf is strong. It's easy to click on a hypertext link and find yourself wandering right off to another continent. If users can embed active links in their messages, it could be difficult to keep readers involved in a conversation long enough to follow it through to the end and add their own 2 cents. As we gain experience with Web-based conferencing, we might find that conversation is more successful if hypertext links are limited to a few specific applications, such as referring back to an earlier response.
Speed. This is crucial not just for conferencing, but for any highly interactive application. For users without a high bandwidth connection, the Web can be agonizingly slow when moving from one page to another. Using the Web at 14,400 BPS feels about the same as using an ordinary dial-up BBS at 2400 BPS. Some of the sluggishness is built in - the Web was designed for shipping files around the world, not for quick response to keys. Netscape has introduced some changes in Web client technology that speed up navigation considerably: displaying each page as it is being received, and aborting the transmission if the user selects any link. Yet performance remains a major problem. Conferencing involves skimming over a lot of stuff to find the most interesting nuggets, so you need to be able to move around quickly.
It's not difficult to create a simple conferencing system on the Web using a scripting language like Perl. WIT was the first of this variety, and there must be at least a dozen such systems today. These are fine for casual use, but they tend to be slow and lack many capabilities that are essential for long-term, heavy duty conferencing,
WebNotes represents a trend with more potential. Makers of commercial conferencing software are hurrying to build Web interfaces to their products. WebNotes is the first such system to market, but others will follow. Meanwhile, work is moving forward on Web systems for voting, annotation, and other types of collaborative projects that have the potential to evolve toward conferencing.
The Web continues to evolve rapidly, chaotically, and unpredictably. But it's safe to say that the Web will be a popular platform for conferencing. The promise it holds is too great to ignore.