Conferencing and Email

Conferencing has been an essential tool for much of my working life. I used an early version of Notes when I worked as a software developer for Lotus years ago. When I joined BYTE, I found myself in the midst of a group of writers and editors who collaborated extensively on BIX.[5] We conducted a huge amount of editorial business in our private BIX conferences: trading contacts, hashing out story ideas, reviewing drafts, exchanging news items. Across continents and time zones, BIX was our virtual office before the term became fashionable. Clunky by today’s standards, it nevertheless embodied many of the virtues of Internet groupware. It was accessible from anywhere, requiring only a modem and freely available software—in the case of BIX, just a terminal emulator. It combined email with conferencing. It was searchable. It could create multiple zones of discussion for sometimes overlapping, sometimes disjoint groups of users. It could admit a transient collaborator—for example, a freelance writer or editor—to one of these groups for a project of limited duration.

Although BIX conferencing was a deeply ingrained part of our corporate culture, by 1996 we could no longer ignore the call of Internet groupware. We switched from BIX conferences to NNTP newsgroups, retaining nearly all the benefits of BIX while adding a number of new capabilities, which we’ll explore in this chapter.

For a long time I thought everybody depended on conferencing the way I did. Eventually I realized that, in many organizations, email was the only collaborative tool in use and that the differing nature and uses of email and conferencing were not widely known or understood. So let’s try to spell them out. Put simply, a conferencing system creates a sort of hive-mind. It’s a great foundation for teamwork. To understand why that’s so, consider these axioms about the flow of information, and the creation of knowledge, in corporate settings.

You May Not Need What I Send You

In email environments, this axiom governs the dreaded FYI (for your information) syndrome. A scrap of information reaches Bob’s desk. He forwards it by email to Richard and Ellen, guessing rightly that Richard needs it, guessing wrongly that Ellen will care, and forgetting to include Sally, who for reasons unknown to Richard has just developed a vital interest in the matter. In a conferencing environment, Bob posts his message to a newsgroup that the whole team visits regularly. Richard briefly scans the message; Ellen skips it; Sally seizes it and puts it to immediate use.

When you offer information to a group, the push method (email) obliges you to identify the right set of recipients. The pull method (conferencing) allows recipients to self-select. But it imposes a different obligation on the sender. It’s Bob’s responsibility to post to an appropriate newsgroup, using an appropriate subject header, so everyone can rapidly evaluate the purpose and significance of the message relative to their needs.

What I Send You Now, You May Not Need Until Later

In an email-only scenario, Bob’s correct identification of Richard as an appropriate receiver may still go to waste. Why? Richard didn’t need the information at the time Bob sent it; his need arose months later. With luck, Richard will remember Bob’s message and will be able to find it in his mailbox. But it might have been purged; it might not be locatable using full-text search; it might never have been downloaded to the laptop Richard’s using at the moment. In these cases Richard might prefer that Bob had posted the message to a newsgroup, so access to it would not depend on the state of Richard’s email client. Private newsgroups, like Notes discussion databases and Exchange public folders, are server-based data stores that can remember things more effectively than many email clients can.

When You Do Need What I Sent, You May Have Forgotten That I Sent It

When Bob emails Richard a message for which Richard has no immediate use, Bob may still have performed a useful service. Assuming that the information will become useful to Richard at a later time, Bob has a) transmitted it and b) alerted Richard to its existence. When Richard does need what Bob sent, he may remember that Bob sent it. But what if Richard doesn’t? What if Bob doesn’t either? Nobody else knows about this messaging event, so nobody else can help. Had Bob posted the message to the team’s newsgroup, the following dialogue might then occur:

Richard: “I’m researching LDAP and I can’t find a description of the LDIF file format.”

Sally: “Did you search our newsgroups for LDIF?”
Richard: “Yeah, nothing there.”
Sally: “Hmm. Still, I seem to remember Bob posting something about LDIF a few months back. Maybe it was just a URL, not the whole spec, so your LDIF search didn’t turn up any hits.”
Richard: click, scan, click, sort, “Aha.”

Group Spaces and Interpersonal Spaces Work Differently

You can see the power of the hive-mind at work. But isn’t there a downside to all this wonderful information sharing? Not everything merits the attention of the group. Overloading the conferencing system with endless chatter will pollute it in the same way that email systems often are. Later I’ll show how scoped conferences can help you optimize discussions and cut down on information overload. Here, though, I want to raise the crucial issue of privacy. No matter how a conferencing system is organized, much vital collaboration will need to occur privately between individuals or among ad hoc groups. In these cases the mode of choice is clearly email. It’s no accident that the Netscape/Microsoft newsreaders use the same tools to view and compose messages as do their respective mail clients. Fundamental to the idea of Internet groupware is the synergy between these two modes.

To show how email and conferencing work together, let’s suppose that Bob and Sally decide to start a new project. They begin developing the idea face-to-face, but since Sally is often on the road, it evolves through a series of phone calls and email messages. Some of these messages are cc’d to Ellen, whom Bob and Sally recruit as an informal project advisor. When the idea gels sufficiently, they post an announcement to the whole group. The anouncement serves three purposes:

  • It alerts the group to the existence of the project.

  • It invites discussion about the project.

  • It invites potential contributors to join the project.

In the ensuing discussion, George raises an issue that Bob and Sally wish they had clarified before taking their idea public. Bob therefore responds not with a posting to the newsgroup, but privately to George and Sally using email. Because the mail and news clients share the same messaging tool, the switch from public to private discourse is seamless. Instead of replying to the newsgroup, Bob replies to George with a Cc: to Sally. He also uses Bcc: (blind carbon copy) to Ellen, to quietly keep the project advisor in the loop. (See the following tip.) Alternatively, George himself could have taken the matter offline with Bob and Sally before posting, and next time he will. In either case, public discussion can resume after an interlude of negotiation and compromise. For users of Internet groupware, the membrane that separates group from interpersonal spaces is selectively permeable. The tools enable you to cross back and forth as needed. Doing that effectively requires skill in the operational mechanics of email and conferencing, and equal skill in the social arts of computer-mediated discourse.

Tip

The reply buttons in the Netscape and Microsoft newsreaders mean two different things. In Netscape’s Collabra, neither of those is quite right for this purpose. Reply means “Post a reply to the newsgroup.” Reply All means “Post a reply to the newsgroup, and mail it to the person who posted the message.” Since Bob wants to drop out of the newsgroup for some private communication, he’ll have to eliminate the Group: header from the quoted message produced by either of these two buttons, then add To:, Cc:, and Bcc: headers, along with appropriate addresses. (In the case of Reply All, the To: field will already be there and will contain George’s email address.)

Microsoft’s Outlook Express handles the transition from conferencing mode to email mode more gracefully. Its Reply button means “Reply by email to the person who posted this message.” The quoted message it produces will have a To: header with George’s email address; Cc: and Bcc: will still have to be supplied. To post a reply to the group in Outlook Express, use the Reply Group button.

Groups Need Privacy Too

In one sense a newsgroup is a public space. A message posted there addresses nobody in particular but rather all current—and future—members of a group. In groupware lingo, we could say that that this form of communication is “role-oriented.” That suggests newsgroup structures ought to mirror organizational structures. For example, you might want to create one set of newsgroups for the engineering division and, within that, subtrees for project teams. I’ll talk more about why to scope discussion areas in the next chapter and show how to do it in Chapter 13. Here let’s just note an important fact about these kinds of scoped newsgroups: they can be made inaccessible, and even invisible, to nonmembers. Such a newsgroup is both public, because it stores messages that group members would otherwise exchange as email, and private, because only group members are present in the newsgroup.

A good basic design puts a few companywide groups at the tip of the iceberg and a larger substructure of departmental and team groups below the waterline. The companywide groups can carry broadcast announcements. These will typically be emailed too, but a newsgroup can store those emails centrally and make them available to people who weren’t on board when the announcements first went out. (See the following tip.) Can’t an email archive do the same thing? Yes, it can. There are, for example, innumerable ways to convert sets of email messages (or newsgroup messages, which are nearly the same thing) into web-based archives.

Tip

A newsgroup can be a natural and convenient way to archive email messages. In both the Netscape and Microsoft newsreaders, you can simultaneously post a message to a newsgroup and send it to an email address. This opportunity presents itself when you invoke the message composer in a newsgroup context—that is, when a newsgroup rather than an email folder is the current selection in the triple-pane window in which both applications present mail and news. In this situation, the Outlook Express button labeled New Post leads to a message composer that prefills the Newsgroups: header and provides an empty Cc: header where you can write the address of your email list. Collabra’s New Msg button likewise prefills the Newsgroups: header (which it labels Group:), and provides a dropdown list that you can use to address the message to other newsgroups (that is, to cross-post the message) or to email recipients.

Companywide newsgroups aren’t just for announcements. They can also serve as a key rendezvous point for teams that usually collaborate in more private spaces. Sometimes a departmental issue needs to bubble up to the surface, gather broad-spectrum input, then return to a more private realm for detailed discussion and implementation. Companywide newsgroups are an excellent way to achieve that effect. In Chapter 4 we’ll see other examples of how and why discussions migrate among newsgroup scopes.

Although some people will speak up in public (sometimes too much!), others won’t. Departmental or team newsgroups that are too broadly visible will intimidate shy people. Sometimes these people will participate more actively in a more private setting. Do everything you can to make them comfortable. The more communication people are willing to share, department by department and team by team, the more likely it is that the system as a whole will reach critical mass.

If I Put It There, I’ll Be Able to Find It Later

When you ask industry analysts why groupware systems fail to reach critical mass, they usually point out—correctly—that there’s a kind of “tragedy of the commons” dilemma. Everybody benefits from the ability to tap into a store of pooled knowledge. But contributors aren’t rewarded. “Free riders” who never contribute enjoy an equal benefit, so where’s the incentive to add to the pool of knowledge?

Note

The “anywhere, anytime” aspect of news, vis à vis email, depends on the degree to which your email system is client-centric or server-centric. The standard Internet client now supports both modes. The POP protocol is client-centric. If you access your mail from multiple machines—your office PC, road PC, and home PC—it’s almost impossible to keep those three different local message stores in sync. The IMAP protocol, on the other hand, is server-centric. You can use it to maintain a common message store on a mail server, as well as a common structure of folders and subfolders within the message store, which (as is also true for NNTP) can replicate to any PC you happen to be using. Finally, some IMAP servers support public folders, which work very much like newsgroups. When IMAP’s full capability is deployed, an NNTP newsgroup is no more effective as a shared central repository than an IMAP public folder. But IMAP arrived on the scene later than POP did, and although both the Netscape and Microsoft mailreaders support it, many of the mail servers deployed in organizations do not. In this situation, a newsgroup can be a useful repository.

You can appeal to the greater good, arguing that effective communication creates a competitive advantage for a company and yields benefits that trickle down to everybody. But trickle-down rewards are notoriously poor motivators. Why not appeal instead to enlightened self-interest? If I store my project-related documents in a newsgroup that serves as a central repository, I can realize purely selfish benefits. Just as with email, I can find those documents later by scanning the newsgroup along its dimensions of subject, author, and date. But unlike my client-centric email, this server-based newsgroup can be available to me anywhere, anytime, from any computer (see the earlier tip). When newsgroups are indexed for full-text search (we’ll see examples of how to do this in Chapter 8 and Chapter 13), the case is even more compelling. It’s ironic but true that relatively few local filesystems can be searched as effectively as can the Web. We can often find things “out there” more easily than we can find them on our own hard disks. If I might want to find something later, I have an incentive to put it someplace where it will get indexed automatically.

For example, I ran a development team for several years that not only discussed ongoing work in team newsgroups, but also routinely posted project-related documents there. These included email messages received from elsewhere in the company or from outside, web pages we found while researching hardware, software, and networking issues, and records of all the changes we made to our servers, the commercial software we ran on them, and the custom software we built ourselves. We could have used a combination of email and our local filesystems to store all this stuff. As we got into the habit of posting documents to our newsgroups, though, we found this was no more difficult than the email or “File Save As...” methods of saving the stuff. Since we all tended to work from multiple machines and multiple locations, the central and searchable newsgroup paid big dividends. If you know you’ll have “anywhere, anytime” access to a document, you’re more likely to take the trouble to file it properly. That’s enlightened self-interest at work.

I Don’t Have Time to File Things Properly

Knowledge workers deal with a relentless flood of information. Even when people want to categorize, file, and share the most important documents that they create, receive, and find every day, they’re operating under brutal time constraints. If it takes more than a couple of seconds to move a document into a shared repository, it’s just not going to happen. Here’s where the close integration between the news, mail, and web clients really shines. A newsgroup isn’t just a place for discussion. It can also be a convenient repository for email, and for web pages, that are of interest to a group. It’s true that a newsgroup doesn’t enable you to define custom fields—things like ProjectName, Category, CompletionDate, or Summary, for example. Sometimes, though, less is more. Customized docbases are great for certain uses, and Part II is full of examples showing how to build and manage them. But these are really for line-of-business applications: status reports, trouble tickets, and other sorts of documents that people are required to create. Many more documents can be usefully shared in a team repository—for example, an email from a vendor about a software bug, or the web page on the vendor’s site describing the workaround. These kinds of documents are, in aggregate, a vital information resource. Yet there’s never time to build forms to catalog them, and even if you did, nobody would have time to fill out those forms. But it’s a two-second operation to route an email or a web page into a project newsgroup. You can do it from your mailreader, or your web browser, with virtually no disruption or loss of context. It’s as easy as mailing the email or web page to your team but better for a number of reasons.

It’s nonintrusive.

News is a lower-priority channel than email, and this is low-priority communication. You just want to alert people to the existence of these documents so they’ll know about them and perhaps be able to look them up later. These kinds of communications don’t normally need a reply. Sending lots of them as email, on the FYI principle, is an abuse of the higher-priority email channel.

It’s centralized.

In environments where email is client-centric, a newsgroup is a more reliable form of “anywhere, anytime” access.

It’s historical.

Unless email is archived, new members of a team won’t have access to older documents distributed as email. A newsgroup that never expires is automatically an archive.

It’s searchable.

Users of AltaVista and Deja.com know that these search engines can pick out relevant documents from among millions, when search terms are sufficiently discriminatory. No intranet newsgroup will ever approach this scale, so if you can remember anything at all about a document that you or someone else posted to an indexed local newsgroup, it’s likely you’ll be able to search for it and find it.

How do you route an email into a newsgroup archive? Netscape Collabra can forward a message from the mail domain to the newsgroup domain. While reading an email message in the mailreader, use the Forward button to launch an instance of the message composer that contains a copy of the message you were reading. By default the composer presents a To: header that invites you to type an email address. Use the dropdown list of headers to instead select a Group: header, which invites you to specify a newsgroup. Then type the name of an appropriate local newsgroup—this might be something like webteam.mailarchive. Note that this newsgroup name implicitly refers to the default news server specified in Communicator’s preferences—that is, Preferences Mail & Newsgroups Newsgroup Servers. When you use local newsgroups as described in this chapter, you can also maintain connections to external news servers (e.g., msnews.microsoft.com), but your local NNTP server will be most effective when it’s the default server.

In Outlook Express, the Forward button works only in the email domain. The message composer that it invokes won’t let you specify a Newsgroups: header. Fortunately there’s another—and arguably better—way to get the job done. You can drag the message from the inbox and drop it onto a local newsgroup! This action launches a message composer with a copy of the email message. And unlike Collabra, which requires that you type the name of a local newsgroup, Outlook Express automatically fills in the Newsgroups: header.

You should always try to write a descriptive Subject: header for newsgroup postings. In this case, Collabra prepends “Fwd:” to the existing message title, while Outlook Express leaves this field blank. Neither method is adequate. When you route email into a newsgroup, you’re consuming a scarce resource—the attention of the people who monitor that newsgroup. Write a Subject: header that tells readers of the newsgroup specifically what this message contains. My email inbox, for example, currently contains several dozen messages labeled Subject: re: server-side performance. That title tells me nothing about the fact that the server in question is a web server or that the performance issue at stake has to do with Perl’s XML parser. Only a few of these messages are keepers. Were I to forward one such message to a local newsgroup, I’d retitle it “Perl-XML performance: Nathan Kurz’s benchmark results.”

This rule about rewriting Subject: headers applies to responses as well as to new postings. If you take the trouble to respond to a posting, it’s presumably because you’re contributing something new to the discussion. Say so in your message’s title! Some people think that the default title—e.g., “re: Perl-XML performance: Nathan Kurz’s benchmark results”—must be retained in order to preserve thread hierarchy. Not so. In some email environments, threading may depend on pattern-matching in message titles. But newsreaders don’t use titles for threading; they use NNTP message IDs in the References: header. There’s no reason not to write a fresh, descriptive title for every message that you post to a newsgroup. When you do write fresh titles, you help everyone scan the newsgroup more effectively.



[5] BIX stands for the BYTE Information Exchange. It’s a text-mode message board that derives from the University of Guelph’s text-mode CoSY conferencing system. Originally a BYTE/McGraw-Hill service, BIX is now owned and operated by Delphi Internet Services Corporation.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
100.28.132.102