Practical Internet Groupware

Content preview·Buy reprint rights for this chapter

Almost every day of my working life brings a fresh demonstration of the power and utility of Usenet-style conferencing. Here's a typical example. While logged in to a client's Solaris box, I triggered this unfamiliar error message: "IO object version 1.20 does not match $1.15." What that meant, in general, was that something was wrong with a Perl module that I needed for an application I was building. What it meant specifically was a puzzle. I'm no Solaris expert, and Perl wasn't exhibiting this behavior on my own NT and Linux boxes. I faced the usual choices: fix the problem, or work around it. But which? And in either case, how?

For the last few years, the planetary knowledge base known as the Usenet has been my first line of defense in these situations. Sure enough, plugging the error message into the Deja.com search engine immediately yielded a posting rich with vital clues:

A Canadian developer named Oleg had run into the same problem.
Oleg's problem was also on a Solaris system.
Oleg was using the same slightly outdated version of Perl that my client's system had.

Nobody ever answered Oleg's plea for help. It's tempting to regard his solitary Usenet posting as a futile act of communication. In fact, it was extremely helpful to me (and possibly to others as well). Oleg's message enabled me to:

Confirm that the problem wasn't specific to my client's system
Strengthen a hypothesis that a Perl upgrade might fix the problem
Contact Oleg by email and suggest the hypothesis to him
Learn that he had already tested and rejected it
Learn that he had contacted the module's authors and failed to solve the problem

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

I define groupware in a very general way as any technology that links human minds into collaborative relationships. Since we'll have to wait a few years for direct mind hookups, current groupware systems rely on the exchange of documents that record what we do and say.

What's Internet groupware? It arises from three distinct—yet interrelated—modes of document exchange: the Web, email, and Usenet conferencing. The confluence of these modes makes the Internet the mother of all groupware applications. I found Oleg on the Usenet, by way of a browser, and then we communicated using email. During this process an ad hoc group formed, including me and Oleg primarily, but also indirectly some Perl module authors and some of my client's technical staff. Unbounded by time, geography, or corporate affiliation, this group briefly focused attention on a problem, pooled knowledge about it, then disbanded. This is Internet groupware in action.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

At its most minimal, groupware is just software that can read and write a shared data store. But wait a minute; doesn't a simple Novell NetWare file-sharing network qualify as groupware according to this definition? Yes, it does. Who among us hasn't played out the following dialogue?

You: "Where's the schedule?"

Me: "It's on drive T:, july98.xls."

More of us do more of our business this way than we care to admit. We realize that it's a flawed mechanism, but we tend not to analyze why it's flawed. There are two reasons. First, the file-sharing approach relies on an unannotated data store. A tree of filenames can describe only so much about its contents. Things got much better when long filenames became standard, but a bare hierarchical namespace remains an impoverished way to describe a data store that houses the intellectual capital of an enterprise.

The second flaw with the file-sharing approach is that it isn't, in and of itself, a mode of communication. After you copy july98.xls to drive T:, you have to tell someone—maybe everyone—that it's there. Hollering "It's on drive T:" over your cubicle wall to everyone within earshot was the time-honored way. But now that everyone is either working at home, or traveling, or in a satellite office on the other side of the continent, we need to project our voices through digital networks. Enter email.

Email appears to solve both of the problems with file-sharing. It does annotate the data store, in the sense that messages can richly describe and comment on attachments. And it is, obviously, a mode of communication. But do you see what's been lost? We defined groupware as software that can read and write a shared data store. Email doesn't do that; typically it reads and writes personal data stores.

Email can be used to annotate file systems, and in fact it tends to supersede them. We like to use mailboxes to manage documents, because there the documents are surrounded by useful context. We know who wrote them (usually not obvious in a raw file system), when (file systems do know this too), and most crucially, for whom and why. The name

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Email isn't really broken, it's just misunderstood and often forced to operate outside its domain of competence. It's the original (and still most effective) push technology. If Bob wants Ellen to review july98.xls, it's appropriate that he email her a copy, just as in the pre-electronic era he would have dropped a paper copy on her desk with a yellow sticky note requesting her attention.

Unfortunately things are never quite so simple. At the same time that Ellen needs to review the numbers, Richard wants to spruce up the spreadsheet's appearance. So Bob cc's july98.xls to Richard as well. Now when Ellen replies to Bob with a financial clarification, Richard gets an unnecessary and distracting email. Likewise when Richard replies to Bob, Ellen gets junk mail.

Things deteriorate from here. Bob and Ellen begin a dialogue that generates a series of back-and-forth messages, each containing an ever-more-confusing tail of quoted responses. Along the way they recruit George and Susan, by cc'ing them some version of the evolving discussion. George and Susan struggle to get up to speed. They don't have the entire transcript, which is distributed between Bob's mailbox and Ellen's, so they have to read between the lines in order to join the discussion midstream. Meanwhile all these messages keep hitting Richard's mailbox. As a member of the team, Richard should be at least peripherally aware of these goings on. But this chatter should be confined to a lower-priority communication channel.

Sally, whose request to Bob set all this in motion, hasn't heard a thing, because Bob forgot to cc her on his original note to Richard and Ellen. And now, as fate would have it, Sally leaves the company. How will Peter, her successor, learn about the status—or even the existence—of Bob's project? There's plenty of documentation, but it's scattered across a half-dozen mailboxes. All are inaccessible to Peter. None contains a complete transcript. Each holds one view of a group discussion, along with quoted bits of some other views. In theory you could join all these views to reconstruct the complete transcript; in practice nobody has the time, skill, or motivation to stitch the whole quilt together. It goes without saying that there's no way to perform a full-text search across the set of documents related to the project.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

For years, groupware vendors have touted structured solutions to these communication problems. Often these solutions do leverage email but harness it to software that:

Coordinates the flow of messages according to some model of a business process
Relates messages to roles and activities defined within that model
Stores messages in a central database

These are great ideas, and in certain situations they can be usefully applied. What characterizes those situations? Well-defined workflow, clearly understood roles, agreed-upon milestones, and fully specified deliverables are what pave the way for successful business process automation. Every enterprise has at least a few mainline business processes that qualify. And then there's everything else—the ad hoc, amorphous, fast-paced buzz of communication that weaves in and around the mainline processes. Teams form and split, plans change, training occurs, documents evolve, communication flows across the corporate border to and from vendors, subcontractors, and partners. All this stuff, happening all the time in real time, is what really defines the daily reality of a modern knowledge worker. It's messy and highly idiosyncratic. Software systems that impose order on this chaos just don't exist. Could they? Yes, but to support a corporate culture with a groupware system deeply attuned to that culture requires serious customization. In Part III, we'll explore ways to customize and extend the standard Internet communication tools. Here in Part I, we'll focus on how to use them more effectively.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Is there a middle ground between the flood of email and the drought of structured groupware systems? Yes. That middle ground is conferencing, a term that is unfortunately so overloaded that it's crucial to explain, for the purposes of this book, what conferencing is and is not. Here are some examples of what I mean by conferencing:

A Usenet or private newsgroup, accessed by way of an Network News Transfer Protocol (NNTP) newsreader
A Lotus Notes discussion database, accessed directly using the Notes client or indirectly through a Domino server by way of a web browser
A Microsoft Exchange public folder, accessed using the Exchange client
An Internet Message Access Protocol (IMAP) public folder, accessed using an IMAP email client
A web-based discussion system, accessed using a web browser

These modes of conferencing share the following characteristics:

Documents accumulate in a central data store visible to all participants.
The primary medium of discussion is written text.
Discussion is typically threaded, exhibiting a treelike structure of statements and responses.
Text messages may be augmented with binary attachments—spreadsheets, programs, images.
Participation is asynchronous. I might post a message at noon today; you might read it at midnight; you might then reply at noon tomorrow.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The Web was invented so that people could use computer networks to collaborate—that is, exchange documents, discuss them, learn from one another, and create new documents that express the collective knowledge that emerges from this collaboration. It was, in other words, supposed to be a groupware application.

Despite the astonishing popularity of the Web, it has yet to fulfill that original mission. Today's Web is more like a combination of electronic publishing and broadcast television than it is like groupware. The Usenet is, for better and worse, the Internet's most compelling groupware application.

A central theme of this book is that we can, and should, draw a sharp distinction between the idea of online communities involved in threaded discussions and its most familiar implementation—the Usenet. That institution, at once a crowning achievement of our species and a sprawling mess, will evolve (or not) according to its own rules, in its own way. My message here isn't that we should reinvent the Usenet (although I think we should), but that its model of collaboration—and its existing, proven tools and technologies—can also serve other vital purposes. On public web sites, on extranets, and on intranets, NNTP conferencing today can support just the kinds of collaboration that the Web has, thus far, failed to deliver.

What we collectively know, in organizations, is expressed in the documents that we write and exchange. Although a new protocol called WebDAV promises to turn the Web into an authoring environment (I'll say more about this in Chapter 3), we're not there yet. The Web, for the vast majority of users, is a library in which we read, not a bulletin board on which we scribble. The Internet application that we do use for scribbling—endlessly, prolifically—is email. But as we've seen, email alone can't do everything we need. It operates in interpersonal spaces, not in group spaces. The value of conferencing is that it enables us to write documents as easily as we can with email and to share them in group spaces as effectively as does the Web.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You can create a pool of shared documents by using any of the kinds of conferencing I've defined. For example, what Lotus Notes does best, right out of the box, is conferencing. The original and still most essential Notes application is the discussion database. Like NNTP newsgroups, Notes discussion databases are threaded sets of messages with attachments. A Notes discussion can also present views other than NNTP's Author:, Subject:, and Date: views. Notes users can easily tweak the discussion template, adding new fields to the underlying database and corresponding new ways to view the discussion. Notes deeply integrates email and conferencing, using a single data store for both activities. That integration solidifies Notes' position as the premier solution for users who frequently work offline and must synchronize between local and central data stores.

Notes has a whole lot going for it. I rate it as the Cadillac of conferencing systems. Why, then, don't I use Notes? Well, I don't drive a Cadillac either; I drive a Honda Civic. I regard NNTP-based systems as the Honda Civics of the conferencing world. They're cheap, they're widely available, they're less complicated and more reliable than you may think, and they do the basic job well.

What about purely web-based conferencing systems? There are lots of them; see David Woolley's summary page at http://www.thinkofit.com/ for a current list. In the long run, I think today's standalone mail- and newsreaders will likely become browser-based applications. But that presumes a generation of browsers with richer user interfaces, and much more robust local data stores, than are available to today's browsers. It's true that some users, even corporate users, are beginning to adopt "thin" web-based email. Most, though, still prefer "fat" email programs that exploit native Win32/Mac/Unix graphical interfaces and local storage mechanisms. These programs are faster and more capable than browser-based alternatives and are likely to remain so for a year or two.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The Network News Transfer Protocol (NNTP) was zipping messages around the Internet long before the Hypertext Transfer Protocol (HTTP) arrived on the scene. The NNTP-based Usenet that still thrives today predates the Web and is built on a very different foundation. Circa 1985 there were relatively few full-time Internet nodes. A store-and-forward technology, Unix-to-Unix Copy (UUCP), enabled intermittently connected nodes to access the Internet. The first incarnation of the Usenet was therefore, of necessity, a discussion system based on data replication. News servers would form pairwise connections, feed each other batches of articles, then disconnect. A complex topology of interconnections created the illusion of a network that was simultaneously accessible to far more nodes than could actually connect in real time to the Internet.

A decade later the World Wide Web catapulted the Internet into the mainstream. But it was a very different kind of Internet. Now end users, from their home PCs, for $20 a month, could access growing numbers of web sites in real time. A user in Tel Aviv could connect directly to a web site in Boston, or anywhere else, at any time. There was no need—and given the Web's explosive growth, there would have been no practical way—to mirror the Web onto servers local to that user in Tel Aviv. It's true that caching web servers mirror parts of the Web. But the Web never had to rely on replication to move data.

Meanwhile, the Usenet, now riding the coattails of the Web phenomenon, continued to grow. People who signed up for ISP accounts found that their Netscape client included a thing called a newsreader. They learned that the newsreader could connect to the ISP's news server, which nightly was fed thousands of newsgroups from the Usenet. They began to participate in virtual communities that operated independently of time and space and were defined solely in terms of shared interest:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Since Version 2, Netscape Navigator has included a newsreader that could access not only a default news server (typically, your ISP's) but others as well. Moreover, it could keep track of your interactions with multiple news servers, remembering for each which groups you subscribed to, and which messages you read. To show why this matters, Netscape deployed its own news server as a standalone that did not mirror the Usenet. On that server, Netscape's newsgroup hierarchy, which would have taken forever to develop if it had to follow the social and political rules that govern Usenet newsgroup formation, appeared overnight. The Netscape news servers soon supported a huge online community of technical people committed to using and extending Netscape's client and server products. To these folks, secnews.netscape.com, and later, news.mozilla.org, became unique destinations on the Net, bookmarked in the same way that AltaVista and Lycos were. On its news site, Netscape built mind share, enabled users to provide one another with technical support, and conducted a massive ongoing focus group.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Following Netscape's lead, other high-tech companies began hosting site-specific newsgroups. One of these was BYTE, where I launched a news server that enabled BYTE's widely dispersed staff to meet and converse with its even more widely dispersed readership. That server, which was the standard InterNet News (INN) 1.4 included with my Caldera Linux kit (see the following tip), immediately paid us a huge dividend. I was planning a cover story for the magazine, a process that for me typically involved weeks of telephone interviews with vendors and users whose perspectives would shape the story. The real challenge had always been simply to find the right people to interview. This is a classic networking problem, in the social sense of networking. We use the people we do know to find the people we don't know. But isn't the Internet the ultimate power tool for social networking? To test that proposition, I started a thread in one of my newsgroups, outlining my plan for the cover story and inviting discussion of it. Then I advertised the thread on our home page.

Setting up your own news server is a lot like setting up a web server—install the software, configure some settings, create a directory structure, and turn it on. See Chapter 13, for details on doing this with various kinds of NNTP servers, on both Linux and NT.

The latest servers from Microsoft and Netscape come with GUI administration tools that turn most of this stuff into a point-and-click exercise. Why don't more people know this? Traditionally, news servers have been used solely as Usenet nodes, and setting up the server-to-server newsfeeds was a complex and arcane chore. When you run a site-specific NNTP server that doesn't replicate with the Usenet, though, you eliminate almost all the hard stuff. The rest is, as I've said, no more difficult than setting up a web server.

In the discussion that ensued, a NASA software engineer mentioned his work using Java to distribute data visualization across an intranet. This was exactly the sort of real-world example that the story required. We conversed online, then by telephone, and what I learned became the centerpiece of the story. What's most remarkable is that my traditional research method never would have found this person, but with the help of Internet groupware, he found me. It was a transforming experience for a journalist, and I think the focus-group technique can apply in other fields as well. The purpose of a corporate web site is not to entertain your customers and business partners but to engage them. Newsgroups or other forms of Internet-based discussion, properly deployed, will help you do that.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Let's look at how this works today at Microsoft's site. Suppose you're interested in Extensible Markup Language (XML), and you land on Microsoft's XML home page (Figure 2.1).

Figure 2.1: Microsoft's XML home page

Note how the third paragraph in the right hand frame includes a link labeled microsoft.public.xml. Although it looks like a normal http:// link that leads to a web page, it isn't. Instead it's a news:// link that leads to an NNTP newsgroup hosted on Microsoft's news server, msnews.microsoft.com. When you click the link, your newsreader starts up. If you've never visited this news server before, it's automatically added to the list of servers tracked by your newsreader, and you're automatically subscribed to the newsgroup whose name was encoded in the link's address. As we'll see again in Chapter 13, this shortcut is a terrific way to catapult visitors into the midst of a discussion. The alternative procedure, which involves manually attaching to the news server, viewing its list of available groups, and subscribing to one or more groups, is cumbersome and hard to explain to visitors not already familiar with NNTP conferencing.

What is a newsreader? It's a client application that connects to news servers, retrieves lists of newsgroups, reads and posts articles (messages), and displays messages in several ways. Like the mail and web components of the standard Internet client, the newsreader talks to its own kind of server using its own protocol. But in the Netscape and Microsoft implementations, the newsreader appears to the user as a facet of the email client. See Figure 2.2, which shows my Netscape messaging environment.

Figure 2.2: Microsoft's XML newsgroup

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Big companies like Microsoft and Netscape don't have to try very hard to reap the rewards of maintaining online discussions. Their developer populations are large; critical mass is virtually ensured. What if you want the same dynamic to work for your smaller company? It's often not enough just to create a newsgroup (or a web-based bulletin board), throw open the doors, and wait for a vibrant community to form. In this game, critical mass is, well, critical. Experienced discussion operators know that for everyone who posts, there may be a hundred or more who lurk.

This doesn't mean your site can't attract a community of users interested in your company's products or services. It just means you have to work the process a little differently. One of the best strategies is to use web pages as portals into your discussions. You want to do more than just keep a record of those discussions; you want to enhance them. The key point is that every online discussion, whether NNTP- or web-based, generates a raw document database, or docbase, to which you can (and should) add value.

What's a docbase? Mail folders, newsgroups, and web archives are all examples of docbases. That is, they're collections of files, stored in directories, containing text that's structured according to some rules. For mail and news messages, the rules are preordained and specify a set of colon-delimited headers (e.g., Subject: Tuesday meeting) followed by a message body that's just more text (which may exhibit internal structure, such as attachments encoded using MIME, or Multipurpose Internet Mail Extensions). For web archives, you need to invent the rules. HTML pages don't require headers, for example, but applications can easily create and use them; Part II is full of examples that show how and why to do that.

A discussion docbase, no matter what its underlying format, provides various ways to navigate its messages—for example, by thread or author or date. But it can't create views that summarize the discussion, or rearrange it, or guide it. Users of the discussion tool confront a raw message stream; it's up to them to separate the wheat from the chaff.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Newsgroups are nifty, and people who appreciate their value tend to prefer them to web-based alternatives. But there's no point in being a newsgroup snob, either. Many people really would rather converse using a browser. Fortunately this doesn't have to be an either/or choice. Make everyone happy, and run a discussion system that plays to both audiences at the same time. I did that with my BYTE newsgroups, mirroring news messages into a parallel web archive. Some commercial news servers, such as NetWin's DNEWS, include web gateways that do the same thing. Conversely some commercial web-conferencing systems, including WebCrossing and WebBoard, offer NNTP interfaces so newsreaders can hook into them.

This hybrid approach isn't so important in an intranet setting, where it's easier to expect everyone to use a single method of access. But public newsgroups should reach out to the widest possible audience, excluding no one unnecessarily. Remember: it's all about getting to critical mass. Don't turn away anyone who can help you get there. Note that for some people, a web interface isn't merely a preference, it's the only possible mode of access. Not all corporate firewalls allow users to attach to external news servers. For these users, the Web may be the only way to use your discussions.

There's another very important reason to create an HTML interface to your public discussions, regardless of whether the underlying engine is web- or NNTP-based. When expressed as HTML, the discussion docbase can be indexed by AltaVista, Excite, and other search engines. That boosts the Web's awareness of your company's products or services, and—here's that feedback loop again—it draws more people into your online community. Some search engines can index NNTP servers directly, but most can't or won't. So even if all your users prefer newsreader-style conferencing (and that's unlikely), it's still a good idea to present the discussions as HTML too.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Every business's customers have something in common: they all use the products or services provided by that business. For example, I bought a bread machine a few years ago. When I lost the recipe book that came with it, I was happy to be able to download a new one from the company's web site. But Internet groupware opens up new realms of possibility. Other owners of the same model of bread machine have doubtless come up with all sorts of recipes that aren't in that book. And they've also, collectively, learned a lot about how to use and maintain the machine. Why not create a home online for that collective knowledge?

Think of online discussion as a resource. Managed properly, it delivers all sorts of benefits. A Net-savvy consumer, faced with a choice between two otherwise comparable products, will tend to prefer the one that's supported by a vibrant online community. A Net-savvy company that successfully creates that community can enable customers to support one another, monitor customer satisfaction, solicit feedback on planned improvements, boost its web mindshare, and generate content that helps keep its web site lively.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Using public newsgroups as described in the last chapter, you can augment a corporate web site with Usenet-style discussion. These site-specific newsgroups work a bit differently from their Usenet counterparts. They can store messages much longer than Usenet newsgroups do—even indefinitely. That persistence creates opportunities to manage the message store as a pool of content that can be advantageously linked into a web site. But this is still a public mode of collaboration, one that ought to appeal to the widest possible audience. It's inappropriate here, as it is inappropriate on the Usenet, to use the full set of capabilities built into the Microsoft/Netscape newsreaders. Public newsgroups necessarily cater to the lowest common denominator: plain ASCII text messages.

On the intranet, it's a different story. Here you're not dealing with the public, only with your own staff. That means you can allow, and should encourage, the most effective use of Internet communication tools—that is, newsreaders and mailers. They can do much more than many people realize. For example, most people know that the Microsoft and Netscape newsreaders can post plain-text messages to newsgroups and can also attach MIME-encoded binary files. But relatively few people have used them to:

Compose and display HTML messages
Communicate securely over SSL
Authenticate using name/password credentials or client certificates (digital IDs)
Do full-text search of an indexed newsgroup (Netscape Collabra and Collabra Server only)
Exploit powerful synergies between email and newsgroups

When people discover and use these capabilities, intranet-based discussion can become even more powerful than Internet-based discussion. Why does this rarely happen? There are two reasons, one technical and one cultural. The technical reason is that although every intranet offers web and email service, few provide NNTP service. So there usually isn't a local environment in which to explore and master the kinds of rich collaboration that NNTP can enable. This obstacle, as we'll see here and in more detail in Chapter 13, is easily overcome.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

At BYTE we created a set of intranet newsgroups in which our distributed staff could privately converse, exchange the manuscripts and images that were the raw material of our product, and manage the flow of other documents. There were company wide newsgroups with names like bytestaff.operations and bytestaff.issueplanning, and departmental newsgroups with names like newmedia.operations and newmedia.design. Originally the NNTP server that hosted these groups was Microsoft's Internet News Server (INS). Later we used Netscape's Collabra Server. Chapter 13 is a basic tutorial on setting up and running these news servers and also the standard Unix INN.

Why didn't we run our local newsgroups on INN? We could have, but modern derivatives of INN, including both the Microsoft and Netscape products, are easier to use and more featureful. It's true ease of use, like beauty, is in the eye of the beholder. If you're good at command-line administration, you may feel that the GUI point-and-click interfaces to the newer servers are more trouble than they're worth. Nevertheless, these interfaces vastly enlarge the potential reach of NNTP. A Windows NT LAN administrator who may know nothing of Unix (never mind INN, whose quirks and crankiness are legendary) will find the Microsoft or Netscape news servers straightforward and familiar. It takes about an hour to install either of these servers, create some newsgroups, and begin hosting intranet discussions.

Eventually, I'll admit, I spent much more than an hour on setup. As we expanded our use of local newsgroups we needed better structure and more security. The structure that evolved was a system of what I'll call scoped newsgroups. Rather than present everyone in the company with a long list of newsgroups, we made the top level of the newsgroup tree visible to everybody and assigned subtrees to departments and project teams. We'll see later in this chapter, and in Chapter 4, why this kind of structure is important. And in Chapter 13 we'll see how to create it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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. 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The inventors of the World Wide Web were scientists who wanted a better way to collaborate with far-flung colleagues. They intended HTTP to work as a read/write protocol. Users of the Web wouldn't just consume hypertextual content; they would also contribute and aggregate it. As the Web went mainstream, though, it became more like television than groupware. The HTTP PUT method, a part of the protocol that enables browsers to upload documents and revisions, was rarely implemented in web servers.

Despite the Web's emergence as a mass medium, there remains an intense need for something like a read/write web server. As this book was being finished in the summer of 1999, a solution was in view. Web-based Distributed Authoring and Versioning (WebDAV, RFC 2518) extends HTTP/1.1 so that multiple WebDAV clients can annotate a shared document on a WebDAV server. The protocol also provides support for moving and copying collections of files. WebDAV requests and responses are expressed as Extensible Markup Language (XML) structures. Transporting XML over HTTP or HTTPS in this way is rapidly emerging as the standard Internet approach to distributed computing, and WebDAV is riding the crest of that wave.

Early WebDAV-enabled clients included MSIE 5 and Office 2000; servers include PyDAV, a Python-based WebDAV server, and mod_dav, an Apache module. What will WebDAV mean to the future of Internet-based collaboration? Prognosticators suggest that it could replace many current mechanisms, including FTP for file transfer, Concurrent Versions System (CVS) for source-code control, IMAP for server-based message management, and NNTP for conferencing. At the moment, though, nobody really knows whether, or when, or to what extent these predictions will come true. So I've chosen to focus this book on the current installed base of Internet browsers, mailreaders, and newsreaders and to explore their still-untapped collaborative potential.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

When the Microsoft and Netscape messaging clients display plain ASCII messages, they automatically activate URLs found in those messages. If I compose such a message, using a messaging client that's set to text mode (see the following tip), I need only mention the site http://udell.roninhouse.com/ in a message that I post to a newsgroup or email to you. Your message reader will render the URL's text as a clickable hyperlink. By merely reproducing a correctly spelled URL, we become—in a limited but important sense—hypertext authors. In the text-mode messaging environment, nobody has to know that the HTML representation of that link is

<a
href="http://udell.roninhouse.com/">http://udell.roninhouse.com</a>

. You can just type a URL, or better yet, cut and paste one into your message.

The Microsoft and Netscape messaging clients can compose either in text mode or in HTML mode. People are most familiar with text mode. It produces messages whose bodies are just lines of ASCII text, typically not longer than 65 or 70 characters. Alternatively these clients can operate in HTML mode. In Outlook Express, you turn on HTML mode using Tools → Options → Send → Mail Sending Format (or → News Sending Format); the choices are HTML and Plain Text. In Collabra, you use Edit → Preferences → Mail & Newsgroups → Formatting; the choices are "Use the HTML editor" and "Use the plain text editor."

It's true that results aren't always perfect. Long URLs, especially CGI-style URLs containing characters such as the question mark and the ampersand, often run afoul of the message reader's line-wrapping algorithm and fail to render as clickable links (see the following tip). Still, this method of URL autoactivation has made a huge impact on the world. Text mode is the lowest common denominator of Internet messaging. Millions of authors of simple ASCII email messages and newsgroup postings now routinely use live citations to other texts. To a literate person from an earlier era, or even to all of us just a decade ago, this would have seemed miraculous. Indeed it is. As we communicate in the context of the Web, we can create new views of it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

When a news server supports a user population guaranteed to be running HTML-aware newsreaders, everyone's a potential HTML author. This doesn't mean you're going to bring in hip, ponytailed web consultants to design your internal discussion pages. It does mean that you can use rich text, tables, images, lists, and color—where appropriate—to communicate more effectively. It means that you can use descriptive labels rather than raw URLs to refer to web pages or news messages. In the special case where the focus of discussion is an evolving web site, you can try out sets of alternative page designs using the newsgroup as a scratchpad web server that also happens to support conferencing. More generally, any product made of words and pictures—a book, a report, a newsletter—can benefit by exposing its raw materials to the production team in a conferencing environment.

The Collabra and Outlook Express message composers both come with integrated HTML authoring tools. In Netscape-only environments, you can also produce a standalone HTML file using another tool, such as FrontPage, HotMetal, or HomeSite, and upload that file as an attachment to a news message. However, the Microsoft newsreader won't display these HTML attachments inline, as the Netscape newsreader will. In any case, the problem with this approach may be that this class of authoring tool is overkill. You don't want to invite users to waste too much time on formatting and layout. Unless the matter under discussion really is a complex web page intended for a production site, it's best to keep things simple. The newsreaders' HTML composers are well suited for their intended use—quick and easy enrichment of discussion content that merits no fancier treatment. With that in mind, here are some guidelines for effective use of HTML in the NNTP environment.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Creators of web sites constantly seek the right balance point in their use of HTML. Some sites take a lowest-common-denominator approach to ensure equal access even to users of Lynx, a text-mode browser. Others adventurously exploit dynamic HTML, catering to users of the latest browsers from Netscape or Microsoft (but not both at the same time!). The most advanced sites deploy browser-detection scripts that adapt to the capabilities of each client. It's hard enough for professional webmasters to stay on top of this complex and fluid situation. Authors of informal newsgroup postings can't afford to spend time thinking about this stuff. Here are some guidelines to help you use HTML in the most inclusive way:

Even if you set the bar fairly low—say at the level of the 3.x Netscape or Microsoft browsers—your postings can communicate far more effectively than if you reject HTML entirely and stick with line-oriented text. The lowest common denominator includes labeled hyperlinks, tables, font control, and attached images. In practice almost all the benefit of HTML messaging flows from the ability to use just these core features.

On some intranets, either Netscape's or Microsoft's browser is considered the standard. It's not necessary to choose one, especially if you stick to the lowest common denominator. But it can be helpful. HTML authoring is new to many people. With a standard newsreader/composer—and from this perspective it doesn't matter which kit you choose—everyone learns how to do the same things in the same ways.

It's embarrassing to make mistakes in public, and you're going to make mistakes until you get familiar with HTML messaging. Make liberal use of the scratch newsgroup—usually called test or junk—that most news servers provide for experimentation. If you want to, you can even cancel your trial postings after you've viewed them.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

When we collaborate online, we find, receive, and create documents, we store them, we reorganize them, we communicate them to individuals and groups. From a groupware perspective, we need to ask ourselves: Who will benefit from my storage or transmission of this document? Does it merit the attention of individuals or a group? If it should be directed to a group, then which one? From an information-management perspective, we need to ask a different set of questions: In what form should I gather documents? Where do I store them? How should document collections be organized?

We collaborate most effectively when we ask and answer all these questions. Admittedly that requires an open and interdisciplinary mindset. This chapter explores ways to add value to the kinds of things we do every day—participating in discussions, sending email, gathering feedback. These routine activities produce all sorts of documents that, collectively, represent a lot of what we know. Organizing that knowledge into useful forms is an enormous task that can never be fully accomplished. But we can make progress in the right direction by developing good habits. The techniques shown here exemplify what I mean by good habits. They cluster into three categories: understanding and using scoped zones of discussion, effective packaging of messages and threads, and strategies for collecting feedback.

Object-oriented programmers spend a lot of time thinking about the right ways to package the parts of the systems they design. This packaging discipline combines functions with the data they create and use. It also defines interfaces that show what packages contain and how they can be used, while at the same time hiding the functions and data that don't have to be visible. The inherent contradiction between showing and hiding, which can never be perfectly resolved, mirrors the contradictory need to both share and withhold information in business organizations. To do our jobs well, we need to transmit and receive the right flows of information. Too much withholding makes people dangerously ignorant and resentful. Too much sharing erodes our ability to focus and prioritize. When we communicate in groupware environments, we make constant demands on one another's attention. A little thought given to the scope of such communication can go a long way toward helping groups work better.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Object-oriented programmers spend a lot of time thinking about the right ways to package the parts of the systems they design. This packaging discipline combines functions with the data they create and use. It also defines interfaces that show what packages contain and how they can be used, while at the same time hiding the functions and data that don't have to be visible. The inherent contradiction between showing and hiding, which can never be perfectly resolved, mirrors the contradictory need to both share and withhold information in business organizations. To do our jobs well, we need to transmit and receive the right flows of information. Too much withholding makes people dangerously ignorant and resentful. Too much sharing erodes our ability to focus and prioritize. When we communicate in groupware environments, we make constant demands on one another's attention. A little thought given to the scope of such communication can go a long way toward helping groups work better.

Figure 4.1 illustrates the set of collaborative scopes that was available to editors at BYTE.

Figure 4.1: Multiple collaborative scopes

As a member of the new media team, I could discuss things with my own team (in the new media newsgroups), with the whole editorial staff (in the BYTE intranet newsgroups), with readers, vendors, and other site visitors (in the BYTE public newsgroups), with Netscape- or Microsoft-oriented developers (in those companies' corporate newsgroups), and with everyone on the Usenet. How to create and manage layered discussions on an intranet is a question I answer in Chapter 13. At issue here is why and how to use this kind of layered discussion environment and how it relates to other collaborative spaces such as public corporate newsgroups and the Usenet.

Let's start with why. If I am seeking or sharing information, why do I need to be able to address a group of 3 (my team), or 300 (my company), or 300,000 (my company's customers), or 300 million (the Usenet)? At each level, I encounter a group that is larger and more diffuse. Moving up the ladder, I trade off tight affinity with the concerns of my department, or my company, for access to larger hive-minds. But there doesn't really have to be a trade-off, because these realms aren't mutually exclusive. You can, and often should, operate at many levels.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

When we create and use scoped discussion zones, we're dealing with the information architecture of the conferencing environment as a whole. Now let's switch lenses and focus more narrowly on information architecture as it relates to individual messages and threads. This may strike you as odd, but if you think in engineering terms, a message is really a kind of object that stores some data and presents an interface that gives users access to that data. Many of us are comfortable with the idea that software objects should properly package their data. But we rarely stop to think that message objects should too.

The techniques for packaging messages aren't difficult, but neither are they automatic. Our messaging tools don't force us to write effective titles, compartmentalize messages, choose appropriate scopes, or layer the information we present. Why should you develop these habits, then? Again I invoke the principle of enlightened self-interest. Quite often a document that I mail or post is also intended for my own future reference. It's to my own advantage to package it in a way that will aid retrieval. Of course, the document is also an effort of communication, invested in hope of some kind of return—a useful reply, a request honored, or simply good will. You can regard good packaging as nothing more, and nothing less, than a calculated bid to maximize your return on an investment of communication effort. Here are some guidelines for packaging mail and news messages.

Subject headers are the titles of mail and news messages. When you scan the contents of an inbox folder or a newsgroup, or when you scan the results of a search of an email archive or a newsgroup, message titles are your best clues about what messages contain. For example, my Sent mail folder at this moment contains a number of months-old messages between me and Mark Stone, an editor at O'Reilly. When I need to refer to the one in which I raised an issue about my contract for this book, I want to see a title like "contract issues" rather than one like "re: re: re: more stuff."

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In groupware contexts, information management doesn't just mean doing a better job of organizing mailing list or newsgroup discussions. It also means using these communication tools creatively to add structure to otherwise free-form interactions. Polling to discover a group's consensus on an issue is, as we'll see in this section, something you can weave into the flow of email or newsgroup messaging.

How often have you sent out a message asking people's opinions about some topic, waded through dozens of responses, and at the end of the process still not been sure what the consensus opinion was? In this section, we'll look at two ways to turn an email query or a newsgroup posting into a mini-application that conducts a poll.

The first method relies on a special kind of mailto: URL that anyone can include in an email message or newsgroup posting. It also relies on simple client-side email filtering, a feature that's available in many popular mailreaders, including Netscape Messenger, Microsoft Outlook Express, and Qualcomm Eudora.

The second method assumes that there's a web-based polling application running in your groupware environment. I'll illustrate the concept using a Java servlet that implements a very simple kind of web-based polling (see Chapter 10), but the same idea would apply to any polling application that expresses votes as URLs that can be sent as email or posted to a newsgroup.

In both cases, the strategy is the same. Much of the information we consume reaches us in the form of messages. Effective groupware recognizes the primacy of the messaging environment and seeks to populate it with applications. Admittedly, mail and news messages offer few degrees of freedom, but they can include URLs, and those URLs can link not only to documents but also to applications. The trick is to take a flexible and pragmatic view of what an "application" can be in this context.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

We like to imagine that IT departments manage information. In fact they manage very little of the information that flows through a modern company. People, communicating with one another, create most of the raw materials of the knowledge base that every company wishes it could capture and use. The painful truth, unfortunately, is that the IT department cannot deliver applications that will reliably channel all this free-flowing communication. Collaboration is inherently fluid and will not survive if forced into a strict rows-and-columns data-management discipline.

Much of what we collectively know is expressed in the form of messages—email conversations, forum discussions. We create this body of information all the time, every day, message by message. As individuals and in groups, we need to understand why and how good communication habits are not merely a matter of etiquette but, equally important, a way to collectively transform information into knowledge.

When a group relies on electronic messaging, every mistitled or misdirected message, and every poorly organized discussion, is a small act of sabotage. Conversely, every message that is carefully packaged and properly targeted, and every well-organized discussion, adds to the sum of the group's knowledge.

So ask not what the IT department can do for us. Ask, instead, what we can do for ourselves. We use the Internet's standard communication tools to enact what we do as groups. The value of the message bases that we create isn't an IT responsibility; it's ours. Groups that collaborate most effectively will be those that understand the common-sense principles outlined in the last few chapters and strive to make messages carry more signal and less noise.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The pillars of Internet groupware are email, news, and the Web. Each comprises a server application, a client application, a protocol spoken between the two, and finally a data store. The Internet owes much of its dramatic success to the simplicity of these elements. Protocols are expressed as human-readable ASCII text. So are data stores. Simple rules define the protocols and data stores. Those rules guarantee predictable and regular structure. That makes server and client applications relatively easy to build and maintain.

To make this concrete, look at the protocol that a newsreader uses to post a message to a news server as shown in Example 5.1.

Example 5.1. Posting a Message to an NNTP Server

$ telnet localhost 119
200 localhost Netscape-Collabra/3.51 11202 NNTP ready
mode reader
200 localhost Netscape-Collabra/3.51 11202 NNRP ready (posting ok).
post
340 Ok
Newsgroups: test
Subject: test
From: udell@monad.net

This is the body of a sample message.
.
240 Article posted

I've illustrated this protocol using telnet, a command-line application that opens a TCP/IP socket to a server, sends lines of ASCII text to it, and receives lines of ASCII text in return. Internet veterans know that many socket-based Internet servers can be "driven by hand" in this way, just as a news server can. And they know that Internet client applications, behind their pretty graphical faces, send and receive the same kinds of ASCII texts. If I connect my newsreader to a news server and use a network analyzer to watch the packets exchanged between the two, I'll see the same sequence of commands and responses.

Programmers who write communicating programs can do so more easily, and more effectively, when they themselves can read and write the protocols those programs must use. Programmers can write lots of these communicating programs, quickly and cheaply, because almost any programming language—including many script languages—can produce and consume text-based protocols. Programmers can debug these communicating programs readily because, once again, the programmers themselves can easily produce the inputs and interpret the outputs. These facts account for much of the Internet's power, flexibility, reach, and resilience.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

What Internet old-timers knew all along, and what Microsoft and everyone else found out a few years ago when the Web went mainstream, is that distributed computing is actually not so hard. Protocols that people can easily read and write are one major simplification. Another is data stores that people can easily read and write. Like Internet protocols, Internet data stores are utterly simple. Example 5.2, for example, shows the data file produced by the NNTP transaction we saw in Example 5.1.

Example 5.2. Contents of an NNTP Message

Path: localhost!not-for-mail
From: Jon Udell <udell@monad.net>
Newsgroups: test
Subject: sample message
Date: Tue, 06 Apr 1999 22:20:56 -0400
Message-ID: <35760488.F61E274@monad.net>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.5 [en] (WinNT; I)


This is the body of a sample message.

In this case, since the news server was Netscape Collabra Server, running on my deskside Windows NT Server, the file's name is C:\Netscape\SuiteSpot\news-udell\spool\test\376. The file divides into two parts: a set of headers and a message body. The

Table of Contents