Eric A. Hall

NOTE: This article is an archived copy for portfolio purposes only, and may refer to obsolete products or technologies. Old articles are not maintained for continued relevance and accuracy.

March 20, 1998

Elephant Talk Redux: Communications Theory

Last week's issue of this newsletter explained why I chose e-mail as a distribution mechanism for feedback and responses, although only on a cursory level. The original version of that missive was quite a bit longer, with discussions on communication theory and the applicability of different models to different types of forums. But it was way too long, so I split the original into two parts: last week's issue, and now this one (which is still too long, I'm sure).

As I said last week, I chose e-mail as a "community" tool after looking at a variety of other mechanisms. As far as I am aware, I am one of the few (if not the only) "professional content" sites to use e-mail in this manner. Most of the others use on-line forums, while some use newsgroups, real-time chat, or a letters to the editor metaphor. These tools and techniques have their own benefits and liabilities, of course.

In an attempt to get a grasp on where the value lines are drawn, I've broken things down into common classifications and models, based on which aspect of a tool made it functional in one situation and a bad choice in another. The five different dimensions that I came up with are: the communication model, the immediacy of the channel, the level of permanence carried by the medium, the level of editorial control, and the author of a communique.

What's most interesting is that there are so many different dimensions to the basic act of enabling communication. What made one mechanism good in any given situation was almost always radically different from the type of benefit offered by another. For example, what made e-mail good had nothing to do with what made forums good, which was totally different from the benefits offered by real-time chat. Sometimes the best approach is to combine multiple elements, borrowing benefits from each and rolling your own communications solution.

Communication Models

During my collegiate stint, I took a few classes in Mass Communications. While most of what I learned has proven to be useless post-Internet, some of the concepts are still quite applicable. Understanding the various communication models and how they represent and dictate interactions between people and groups is of particular interest.

One-to-Many: This is the typical model used in most forms of mass communication. Content is generated and then made available through broadcast airwaves, printing runs or mailing lists. Modern examples of one-to-many communication include newsletters like this one and C|Net's News Dispatch, and of course spam. Another less obvious example can be found in the numerous non-interactive Web sites that don't adjust content according to readers' preferences.

One-to-many is an appropriate model for positioning, distributing bad news ("revenues are down" or "you're all fired") and other situations in which discussion and dialogue are not necessarily desirable. It's a terrible forum for providing information that is tailored to an individual (more on this in a moment), or for any other use that would benefit from bi-directional communication.
Many-to-One: However, one-to-many communications can be useful for initiating a dialogue. This is true of all forms of mass communication. "Call our 800 number," "return the pre-paid envelope" or "hit reply" are all standard tricks of the trade for engendering bi-directional communication.

The "mailto:" links on your web site are a modern-day equivalent of this model in action, while the "Reply-To:" field on this newsletter is another. But "contact your sales rep" and "post your comments" offer different outcomes. The first is an invitation to initiate a one-to-one communication, while the second is an offer to join a many-to-many discussion.
One-to-One: Historically speaking, almost all "transactions" occur at a one-to-one level. Pitching a product's benefit set, haggling over price and making delivery are almost always done on a one-to-one basis. This isn't always true, but for value-based products and services, it is used almost exclusively. By the way, transactions don't have to be tied to commerce: a "seller" can be providing knowledge or influence and in all likelihood a one-to-one transaction will still occur.

So if you're looking for tools that help you "sell" something, look for one-to-one mechanisms that suit that goal. You can still use one-to-many and many-to-one tools, but when it comes time to close the deal, rely on one-to-one for the actual transaction.

Sadly, there are very few Internet tools for building one-to-one communications. The most common form takes place in transaction-centered e-mail, where a buyer and seller communicate directly. Another example is ICQ and competitive "private-chat" technologies. There are also the few dozen commerce sites that customize the buyer's Web experience, but unfortunately they're the exception rather than the rule.
Many-to-Many: The last distinct form of communication is many-to-many. This is where the biggest boom in "community-building" tools has been, with offerings for on-line forums, real-time chat rooms, discussion lists and even groupware management products. Note that these tools all have different benefits and values, but they all fall into the many-to-many camp.

The principle value of many-to-many comes from the participants' ability to exchange ideas and experiences. Sometimes this is a good thing, and sometimes its not. Letting your users share network design issues is a mighty fine use, as their experiences will certainly be of value to others in their peer group. But you probably wouldn't want to ask your users for product feature suggestions, as this kind of setup would likely instigate debate instead of discussion. That goal would probably be better served with a many-to-one feedback system instead.

The communication model determines the potential success and failure of your project more than anything else. It doesn't matter how well you build the resource; a great tool in a bad model will still fail to reach its goal.

It's embarrassing when your customers argue among themselves. But it's a hanging offence when customers tell prospects what a miserable product you have, on your own service. These are avoidable scenarios, once you understand how the models represent and dictate the underlying communication patterns.

Immediacy and Longevity

Once you've chosen the communications model that your specific objective maps to the best, look at the time-based dimensions of the communication to decide on the specific implementation. Each of the communications models listed above lend themselves naturally to different types of "time."

For example, one-to-one communication channels tend to be focused on the here-and-now ("I gotta reboot the NT box, what's the password?"). At the other extreme, many-to-many channels tend to focus less on urgency and more on reference ("What's the best auto-boot program for NT?"). Meahwhile, many-to-one and one-to-many have varying levels of immediacy, but almost never have any sort of permanence.

These two dimensions - immediacy and longevity - are responsible for defining the underlying value of any medium more than anything else.

The tools available in the many-to-many category have the broadest range of time-based attributes. Real-time chat offers immediate postings with almost no inherent longevity at all, while discussion lists and moderated newsgroups offer sluggish relays with a natural tendency towards archival. Choosing the one that's best for you comes down to a true understanding of your business objective.

For example, Novell makes good use of newsgroups for its developer community. The nature of development kits is such that users are likely to ask the same question many times, but with different details or local issues. Newsgroups and on-line forums permit these questions to be asked and to be responded to, and they also offer a certain amount of archival capabilities, providing other users with an additional source of knowledge and expertise.

At the same time, Novell makes miserable use of real-time chat in its NDS Chat Lounge. A web site is by definition a one-to-many forum, while real-time chat is an immediate, impermanent, many-to-many tool. If this were an ad-driven site, it might be okay to mix up the metaphors, but as a product-driven company, it makes little sense. If the goal is peer-to-peer education, then a forum or newsgroup tool would be a much better solution. If the goal is general marketing and awareness-building, then a mailing list (or the existing web pages) would be better, providing a one-to-many forum for outlining the advantages of the technology. As it is, the jumble of metaphors is confusing and inappropriate. Perhaps this is why nobody ever seems to actually be in the chat room. It's been empty every time I've visited.

Editorial Control

Another aspect, and one that is directly tied to the immediacy dimension outlined above, is the level of editorial control offered by a specific technology. The ability to control who says what, or to control who gets to say anything at all, can provide value (or detract value from the forum, as the case may be).

The closer something is to real-time, the harder it is to moderate. There's no way you can control what somebody will say in a multi-user chat room. Conversely, it's relatively easy to moderate what is said in a discussion list or newsgroup, since you can review all of the commentary before it gets distributed.

This only works if the setup is architected properly. One issue to consider is the number of entry points that a forum allows. If a newsgroup is kept on a single corporate server, then there's only one entry point and you can control what does or does not get posted. But if a newsgroup is banged around over usenet, then you can forget about having any control whatsoever. This also applies to discussion lists in that you can control who can send mail to a group address using some relatively simple tools, but putting everybody's e-mail address on the "To:" line opens the door for random posts by anybody with a grudge.

Another level of content control can be achieved by combining limited entry points with some sort of "authenticated poster" access restrictions. For example, Robert Seidman only allows pre-approved parties to make posts on his InsiderTalk forums, and InfoWorld requires users to register before they can make comments. This not only keeps the noise level down, but it also gives the site administrators an ability to track down whoever posted the nudies. David Strom uses a letters-to-the-editor metaphor in Web Informant, sometimes reprinting reader feedback as the next issue. In this case, only one person is allowed to post, and that's whoever happens to agree with David the most <g>.

Who Said What

Finally, the most obvious aspect of communication theory is the author of the message. Credibility within the target market not only dictates who should speak, but it also dictates the type of forum that you should use for them to speak in.

Case in point: news releases about a company's products are typically sent from a PR or marketing person, although press releases regarding earnings and revenues typically come from the finance department. The finance department has more credibility within the finance community. This is a good thing!

The issue of credibility and authority plays the same in on-line forums, chat boards, e-mail, and all other forms of communication, although sometimes credibility is determined more from content than credentials. If I'm stuck on a technical problem, then anybody who knows the answer has credibility. It doesn't matter how they know it; the fact that they can help is all the credibility I require.

This whole issue can get wrapped up into the editorial content controls you decide to implement. Robert Seidman only lets people who are on-the-inside (wink-wink) to post commments, so authority is tightly integrated into his editorial service. However, I have to wonder how many good posts are never made as a result of this filter. Since it serves his purpose, it's irrelevant, but the example holds true nonetheless.

The point is, make sure you're getting comments from the authority figures in the community, whoever that may be. Once you define who it is, a big part of your deployment strategy has been decided for you. If it's the CEO of your firm, then maybe you shouldn't be looking to implement a many-to-one feedback mechanism. But if you're trying to get your developers to share coding secrets, then a many-to-many architecture is going to be the most appropriate. Figure out who the authors are before you decide on a specific model.

Mutant Models

Not a single one of these guidelines will likely be useful by itself. Your best bet is to pick the communication models that suit your specific goals, and then find tools that suit the strategic agendas. In all likelihood, you'll either have to implement multiple models in a cooperative manner, or you'll have to combine them into a single, mutant forum.

Some of the best information sources on the web mutate multiple models into one indistinguishable entity. For example, PR Newswire uses one-to-one demographic tools to customize the distribution of their one-to-many press releases, as does InfoBeat with their Closing Bell stock-monitoring service.

Another example: Microsoft offers a slew of newsletters to their customers, which are chosen according to areas of interest. On the surface this seems like a good idea, but I don't really like their implementation. They inundate me with "buy Office 98 now!" crap, which isn't nearly as useful as "bug fixes for Office 95" would be.

There are even a couple of web sites that have merged multiple metaphors into an indivisible blend, the best of which is probably FireFly (now a Microsoft property). They incorporate one-to-one controls into their one-to-many content, allowing for the dynamic display of specials, pricing and other content according to your past behavior. Such a system could be replicated by anybody who uses the web to "sell" and not just "market." It would seem that the rest of you should incorporate this type of customizable structure, dynamically showing content and specials according to my purchasing and surfing habits. I'm into protocols and network services, and don't give a hoot about the backup utility you've just licensed. Why are you wasting my time with that info?

Ad-driven sites like InfoWorld and C|Net could setup a mechanism for monitoring the stories that I view, and start displaying ad banners that match my most visible areas of interest. If I read lots of stories about IMAP, then it would seem to follow that I am most likely to be interested in ads for e-mail products, even if I happen to be reading an article on Token Ring switches.

I suppose that my own site would benefit from these kinds of dynamic services as well. Maybe I'll get to it one day. For now, I've chosen to implement three different models and tools simultaneously. I'm using a one-to-many model for sending out this newsletter, and I'm supplementing that with two different many-to-many services for building my "community." E-mail discussion lists give me fast distribution with a high level of editorial control, while the on-line archives< provide future readers with access to your great commentary. These three tools suit my goals well, and that's what's important. It doesn't matter that nobody else is doing it.