Choosing Web Conferencing Software

By David R. Woolley

This article was written for the 1996 International University Consortium Conference on WWW Course Development & Delivery. Portions of this article were originally published in the book World Wide Web Unleashed.

Contents:

• Introduction
• What is Web Conferencing?
• Categorizing the Products
• Key Considerations
• What Makes a Good Conferencing System?
• Universal Problems
• Conclusion

---

Introduction

The field of Web conferencing software is growing at a breathtaking pace. In the summer of 1994 there were exactly two products in this category, both of them rather primitive freeware packages. Today there are well over 60 commercial and freeware products, many of them quite sophisticated, that support conferencing on the Web in one form or another.

With so many products available, the choice can seem overwhelming. But with a methodical approach, you’ll probably find that you can quickly whittle the list down to just a few candidates.

What is Web Conferencing?

First, let’s define our terms. For our present purposes, conferencing is a form of group discussion that uses text messages stored on a computer as a communication medium. It does not include various types of real-time, or synchronous, communication, such as “chat rooms”, voice-based teleconferencing, or video conferencing.

A conferencing system is Web-based if it uses Web browsers and servers to provide most of its functionality. This is not as clear a distinction as it might sound. Most developers of conferencing software are hurrying to adapt their products to the Web, and the result is a lot of hybrid products that use the Web to a greater or lesser extent. Hence, the boundary between Web and non-Web conferencing software is a bit blurry.

Systems that work with unmodified Web browsers and servers are of greatest interest, because they are the most easily accessible to the great mass of Web and intranet users. Any Web software that requires users to install a browser add-on, or even an entire proprietary browser, suffers a handicap, although such special-purpose software might give it a significantly better user interface.

Categorizing the Products

Five Great Rivers

Web conferencing systems have widely varying designs, partly because they were built with very different purposes in mind. Hence, an across-the-board comparison of all available products would be meaningless. It makes more sense to group them according to the different traditions from which they have grown.

Historically, there have been five “great rivers” of conferencing and conferencing-like software that have evolved more or less independently of one another:

• Centralized forums
• Groupware
• Bulletin board systems (BBSs)
• Usenet
• Mailing lists

All of these rivers are now converging on the Web, and in this new environment they are mingling in ways that are beginning to blur the distinctions between them. But most of the conferencing products available today still strongly show their origins.

Centralized Forums

Centralized forum software originated on mainframes in the early to mid-1970’s with systems like PLATO Notes, Confer, and EIES. These were designed specifically for group discussion, and they treat messages as part of an ongoing conversation with some inherent structure. Discussions are stored on one central computer, and each new message is assigned a place in the discussion structure immediately upon being posted. Over the years this line of software has evolved sophisticated features for managing and participating in conversations.

Within this arena, there is another identifiable subgroup of products whose designs have been derived from Confer, a system originally developed in 1975 by Robert Parnes. I call these products “WELL-style” conferencing systems, because the WELL has been very influential in spreading this design. There are a number of features that tend to appear in WELL-style conferencing software, but the most readily identifiable feature is that it structures discussions as linear chains of responses, and displays each discussion as a continuous stream of text.

Examples of WELL-style Web conferencing software include:

• Backtalk
• Caucus
• COW
• Motet
• Web Crossing
• WELL Engaged
• YAPP

Examples of other centralized forum software for the Web include:

• Allaire Forums
• Big Mouth Lion
• HyperNews
• NetForum
• Podium
• Post-on-the-Fly Conference
• TALKaway
• WebBoard
• WebNotes
• WebThread (by Emaze)

Groupware

Groupware, or workgroup collaboration software, was defined as a new software category by the introduction of Lotus Notes in 1989. Lotus Notes evolved out of PLATO Notes, so in a sense this category is an offshoot of centralized forum software. But whereas forum software is focused primarily on group discussion, groupware products support a wide variety of other activities, such as scheduling and document sharing. Some groupware products are suites of ready-made applications; others are toolboxes for creating collaborative applications, with customizable templates included.

As a group, these products tend to be both powerful and complex. They are marketed mainly to corporate customers for internal use by workgroups, where conversation is generally deemed less important than an efficient work flow. Indeed, in some of these products, group discussion seems to be an afterthought, while others handle discussions quite well right out of the box. But in any case, many of these products offer tools that let you customize a conferencing environment to your heart’s content, if you have the skills and time to do so.

Groupware products for the Web include:

• InTandem
• Livelink
• Lotus Domino
• Oracle InterOffice
• TCBWorks
• TEAMate
• WebShare

Bulletin Boards

BBSs were pioneered by microcomputer hobbyists in the late 1970’s. These systems were designed mainly for swapping files, but also featured areas where users could post notices. Each message was treated as an independent entity with no relationship to any other message, and all were posted on one big “bulletin board” with no organization. Later, features began to appear for categorizing messages, responding to specific messages, and carrying on threaded discussions. But in general, BBS software is not as well adapted to conversation as the centralized forum software is.

Web BBS software includes:

• Spinnaker
• WebLines
• Worldgroup

Usenet

Usenet arose in the early 1980’s. Like BBS software, Usenet was designed to handle individual messages, although it provides separate newsgroups to sort messages by broad subject areas, and facilities for responding to specific messages. Usenet has two main distinguishing characteristics: first, it uses standardized protocols to format and transmit messages, and second, messages are passed from one news server to another and thus replicated at many places around the world, rather than being stored at one central location.

The most popular Web browsers, including Netscape Navigator and Microsoft’s Internet Explorer, have built-in news readers. Probably for this reason, few standalone Usenet products have been developed for the Web. (Forum News Gateway is the only one I know of, although Web Threads by inTouch Technology is designed to have a “news reader-like interface.”)

Some argue that with Web browsers supporting the Usenet standard, there is no need for any other conferencing software on the Web. I won’t get into that argument here, except to point out that the thriving market for other varieties of Web conferencing software would tend to indicate otherwise.

Nevertheless, it is certainly true that this is a fairly straightforward and cheap way to do conferencing. Just set up a news server using free, standard software, create some local newsgroups on it, have your users access your server with their favorite news-capable Web browser (or any other newsreader, for that matter) and voila! a conferencing site.

Mailing Lists

Mailing lists have probably been around in some form as long as e-mail has existed. E-mail is the least structured form of conferencing — so much so that it’s a stretch to call it conferencing at all. Yet it is an asynchronous, text-based, many-to-many medium, and can be used for some of the same purposes as other forms of conferencing.

E-mail does have certain advantages. It is the lowest common denominator of Internet services, and therefore reaches more people than any other avenue. Also, e-mail messages simply show up in your mailbox; you don’t have to go looking for them. On the other hand, e-mail is not organized by topic, and threading is difficult or impossible. For this reason, mailing lists are not as good at supporting multiple simultaneous discussions as are true conferencing systems.

Several Web interfaces to mailing lists have been developed:

• HyperMail
• MHonArc
• LWGate

All of these support browsing of a mailing list archive through a Web browser. With very little effort, it’s possible to automate updating of the archive so that new messages appear on the Web as soon as they are posted. None of these software packages have built-in message posting capabilities, but perhaps this doesn’t matter much, considering that messages can be posted to a mailing list with any e-mail client (including the ones built into many Web browsers).

Key Considerations

After considering which of the categories of conferencing software best suits your needs, there are many other things to take into account in choosing a product. The following are likely to be key “make or break” considerations for many people.

Price. This is still a young field, and prices are all over the map: they range from free to several thousand dollars. Don’t assume that a higher priced product is better. To a certain extent, you get what you pay for, but a few of the freeware products are actually stronger than some commercial products. Even if price is no object, the most expensive product is not necessarily the one that best suits your specific needs.

Operating System Support. Operating system platform might also be a key determining factor, especially if circumstances require you to run conferencing from an existing Web server. Many choices are available for Unix servers and many for Windows servers, but relatively few products support both. If you run a Macintosh server, your choices are more limited.

Compatibility with Other Environments. If all access to your conferencing system will be made via the Web, then compatibility with other environments is not an issue. But in some cases there is a requirement that discussions be accessible by some other means, and this limits your choices. For example, Caucus and YAPP are the only two Web conferencing products that also support access via a text-only telnet connection. WebNotes discussions can be accessed through a proprietary Windows-based client. And of course, Lotus Notes has proprietary clients for a number of platforms.

Administrative Capabilities. If you have limited access to your Web server, you’ll want to choose a product that can be installed and administered easily with whatever level of access you have been granted. Conversely, if you are running a server yourself and want to be able to delegate discussion administration chores to others, you’ll need a product that lets you give limited administrative capabilities to designated users.

Browser Support. Some Web conferencing systems rely on advanced HTML extensions such as frames or Javascript. A few require special browser add-ons. Consider whether all of your users will be able to access your conferencing system given these dependencies.

Customizability. Virtually all Web conferencing products are customizable to some extent, but some are much more so than others. In some cases, the customizability is limited to simple things like plugging a logo into a designated location on the page. But the most flexible products provide ways of significantly modifying or extending not only the displays, but the functionality of the system. This is done in a variety of ways. Caucus and Web Crossing provide macro languages that can be used to modify or completely redesign their user interfaces. Allaire Forums and TALKaway are built on top of general-purpose toolsets for development of Web database applications (Cold Fusion and WebDBC, respectively) and can be easily extended with those toolsets. Some conferencing systems, particularly freeware products, come with full source code, allowing you to hack them into anything you desire.

Various conferencing systems offer dozens of other features that might or might not be important, depending on your intended use. If there are still several candidates left after your key selection criteria have been satisfied, try to prioritize your feature wish list, and then compare each product against it to find the one that best matches your needs.

What Makes a Good Conferencing System?

Ask 100 experienced conferencers what makes a good conferencing system, and you’ll get 100 different answers. As with any kind of software, people tend to like whatever they are used to. But almost anyone who conferences regularly will readily point out flaws in their own favorite system.

There is no single perfect solution for all people and all purposes. But having used a variety of systems over the past 20 years, 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. Usenet is structured this way, as are many Web conferencing systems. But although 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 it’s often hard to figure out where to attach a response. Discussions tend to fragment and dissipate. I prefer a linear 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. On the Web there is an additional reason to use this structure: displaying a discussion as a continuous stream of text keeps interactions to a minimum. Since you don’t have to click a button on every response, there are fewer delays while reading messages. All of the WELL-style systems are designed this way. WebNotes and several others use a linear structure but display each message on a page by itself.

Informative topic list. A reader should be able to easily see a list of the topics in a conference. At minimum, the list 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) 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.

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 such as advancing to the next message should require only one keypress or pointer-click and should happen instantly when selected. If the system is slow or cumbersome, people simply won’t use it much.

Universal Problems

Although Web conferencing software has improved enormously in the past two years, in a sense, all of the products available today are fundamentally crippled. The problems are not the fault of the conferencing software, some of which is quite well designed. They are inherent in the architecture of the Web itself. The worst problems lie in two areas:

Performance. The Web is lousy for highly interactive applications because of the overhead involved in moving from place to place. Every time you click on a link, you have to wait. 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.

User interface. The only way to navigate through a Web conference is to click on buttons embedded in HTML pages. This is the only method that HTML supports. There are several problems with this. First, keyboard navigation is impossible; you are forced to aim your mouse at buttons on the screen. Second, the buttons don’t stay put! They float around and even disappear from the screen as you scroll through a page. Nobody would tolerate such a user interface in any application outside of the Web. Imagine a word processor whose menu bar disappears whenever you scroll down through a document. Such a product would be laughed off the market. Yet that’s the current state of the art of Web applications. As an added insult, the text editing capabilities built into today’s Web browsers are incredibly lame.

Solutions for the Web’s performance problems are in the works. Future versions of HTTP (the HyperText Transfer Protocol used in all communication between Web browsers and servers) will allow a Web browser to maintain an open session with a server while it requests multiple items. This should drastically reduce the delays involved in moving from page to page.

The user interface problems are tougher, given the structure of HTML. It’s even difficult to imagine reasonable extensions to HTML that would give software developers sufficient freedom to create a good user interface. Some Web software developers are using HTML frames and Javascript to attack these problems. This approach has merit, but it’s only a partial solution, and it comes at a cost: not all Web browsers support these features. The ultimate solution probably lies in bypassing HTML entirely, and writing the user interface in some other language — possibly Java.

Conclusion

No conferencing system available excels at everything. There is no single “best” product that is the ideal choice for every situation. The field of Web conferencing software is rich in variety, and many good products are available, each with its own strengths and weaknesses. But a careful analysis of your needs will help you to choose the product best suited to your application.