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.
Figure 4.1 illustrates the set of collaborative scopes that was available to editors at BYTE.
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.
To make this concrete, let’s see how one project of mine played out in this environment. My task was to create a subscriber-access version of the BYTE web site. A crucial subtask was to apply HTTP basic authentication in an unusual way. I began by summarizing my view of how authentication works, and sketching out my proposed implementation, in a document that I posted to my departmental newsgroup. Why there? Partly to alert my team to the existence and status of this project, and partly just to store this research document in a central, searchable repository.
Although I could have posted it to the entire editorial staff, I chose not to. Why not? I knew that while some of my colleagues might find the summary useful, that didn’t warrant placing a demand on the attention of the whole group. Had there been a companywide scope, I’d have skipped that one too. A matter too technical to discuss with the editorial staff would have been inappropriate in a companywide forum that included sales and marketing people.
But the outer layer of my own site’s onion was crucial. Here I could reach people who were my counterparts in other companies, who might find my summary useful, and who might in turn comment usefully on my plan. As it turned out, several did. Other places to find such people include the Netscape newsgroups (e.g., news://secnews.netscape.com/netscape.servers.web), the Microsoft newsgroups (e.g., news://msnews.microsoft.com/public/inetserver/iis), and the Usenet (e.g., http://comp.www.servers). Since I was lucky enough to have a critical mass of savvy developers in my own newsgroups, I usually went there first. Otherwise, I’d have targeted this kind of message to one of these other communities.
It’s always tempting to post a message that asks: “Does anybody know how HTTP authentication works?” But you owe your intranet colleagues (and yourself) more consideration than that. And in wider contexts, this kind of naive plea will be ignored, if not actively ridiculed. Instead, summarize what you know already, cite supporting evidence, clearly frame the issues at stake, and ask specific questions. Here’s an example of what I mean.
“I’ve been researching HTTP authentication in order to solve the following problem: <PROBLEM>. Along the way, I’ve learned some useful things: <LIST>. Based on this information, it seems to me that this plan will work: <PLAN>. Comments and clarifications are welcomed and appreciated.”
There is of course no guarantee that qualified people will respond helpfully. Nevertheless, people often do when they’re interested in the issue you raise and especially when your posting adds to their store of knowledge on the subject even as it seeks to further your own knowledge.
What if nobody responds? If nothing else, the act of writing a thoughtful posting is intrinsically valuable. It helps you to think things through more carefully. But there can be subtler secondary effects too. When I posted this message in our public newsgroup, I alerted several different audiences to the status of my project—colleagues in other parts of my company and potential collaborators outside my company. Anyone who followed that newsgroup learned about my problem and my plan to solve it. As I’ve said, several outside collaborators did respond immediately and helpfully. But even if they hadn’t, the posting planted a seed that might germinate at any time. Weeks later, a staff colleague or an outside collaborator might have run across an idea, or a person, or a tool relevant to my project. Knowing of my interest in the matter creates the possibility of connecting me to that idea, person, or tool. These connections may seem serendipitous, but really they aren’t. People make connections to you based on what they know about your interests and activities. Conferencing can expand the number of people who know what you’re up to, and increase the likelihood that people can help you.
When you’re trying to solve a problem, you never know who might be able to help you solve it. Broadcasting to a discussion medium (newsgroup, listserv, etc.) is an appropriate way to seek help, provided you do so in a thoughtful and informative manner. It’s also appropriate, very often, to address this kind of message to specific people who might be able to help or who should be informed about the matter. And sometimes it’s appropriate to hold a meeting to discuss the matter. In this situation, it can be useful to launch a discussion thread and then invite selected colleagues to join that thread.
In the last chapter we saw how to
address individuals and groups at the same time by using a mixture of
email and conferencing modes. There, we focused on using the
newsgroup as a kind of email archive. Here, we’ll focus on
achieving a different result—drawing an email recipient into a
newsgroup discussion. The technique is the same. You simultaneously
post a message to a newsgroup and address it to an email recipient.
Both newsreaders—Netscape Collabra and Microsoft Outlook
Express—can do this. Collabra is more flexible, enabling you to
specify multiple email addresses using To:,
Cc:, or Bcc: headers. Outlook
Express permits just a single Cc: header.
From the perspective of the email recipient, the resulting hybrid
mail/news message works as a newsgroup invitation only in the
Netscape mailreader, Messenger, not in the Microsoft mailreader,
Outlook Express. The reason is that Messenger presents both newsgroup
headers (e.g., Newsgroups: webteam.planning) and
email headers (e.g., Bcc: Jon Udell <udell@monad.net>). What’s more, when you read
this kind of hybrid message in Messenger, the
Newsgroups: header is not only visible, but
clickable. It’s wired to a news:// URL that launches the
newsreader and focuses it on the indicated newsgroup. That’s
what I mean when I say that a message of this type can invite people
to join a discussion.
Outlook Express unfortunately
doesn’t work quite the same way. When you use it to view this
kind of hybrid message, it ignores the Newsgroups:
header. So an email recipient can read the message that was posted to
the newsgroup but can’t use the message as a springboard into
the discussion.
Subtle issues arise when you use Collabra to mix email and conferencing modes in this way. For example, although I can invite my extradepartmental colleagues into one of the staffwide discussions on our intranet server, I can’t invite them to join my own department’s newsgroup if it’s configured—as it should be—to admit only members of my team. Nothing prevents me from trying to do this. When I post the message to my project newsgroup, I can cc an extradepartmental colleague. That person will receive the hybrid email/news message and can read it. The email thus successfully notifies the recipient about the contents of the message. But in this situation it’s inappropriate to have invited someone lacking access to my project newsgroup to join in a discussion there.
What happens if I do issue this
kind of invitation? If my project newsgroup is properly configured to
refuse access to nonmembers, clicking the newsgroup name in the
message’s Newsgroups: header will produce an
NNTP authentication dialog box. Lacking access to the newsgroup, my
extradepartmental colleague will be confused and frustrated by this.
But something else happens here that shouldn’t. The existence
of my project team’s newsgroup, which we’ve said proper
scoping should hide from the rest of the company, is revealed.
What if I cc this posting to someone outside my company? In that
case, I reveal the existence not only of this newsgroup, but also of
the server itself. The fact that my company may be running a private,
Internet-accessible discussion server is nobody else’s
business. However, the Newsgroups: header is not a
fully qualified news:// URL. It contains only the name of the
newsgroup (e.g., http://news:webteam.planning) and not the address
of the server that hosts that newsgroup (e.g., news://udell.roninhouse.com/webteam.planning). So if I inadvertently send an email with an intranet
newsgroup’s name in a Group: header,
I’ll reveal the existence—but not the name or IP
address—of my intranet news server. That’s not
disastrous, but it’s not good either. Operating in multiple
scopes is powerful, and as always, the flip side of powerful is
dangerous.
Here’s the upshot: under certain
circumstances, Collabra enables you to use
Newsgroups: headers in email messages to achieve a
simultaneous push/pull effect. For example, I might want to alert
someone in the company, perhaps outside my department, to a thread
that I’m starting in a staffwide newsgroup. If everyone follows
that newsgroup regularly, there’s no reason to do this. But
people won’t always be following all the intranet newsgroups
you think they are or at any rate not as regularly as you expect. So
it’s useful to be able to focus attention on a thread by means
of an email invitation.
This technique can work across multiple scopes on an intranet server. If I want to raise an issue of interest to my team, but also of interest to extradepartmental colleagues, I can post to a staffwide newsgroup and cc the colleagues whom I’d like to invite. What I can’t do, though, is reach even wider scopes using this technique. Suppose I start a thread on my company’s public news server. There’s nothing secret about that server or the messages on it, so security isn’t an issue. But though it’s tempting to do so, I can’t use this simultaneous push/pull technique to send a hybrid news/email message that both starts a thread and invites selected attendees to join. There are two reasons why not. First, even if Netscape’s messaging client were the standard email program in my company, it’s not likely that everyone outside my company will be using it. Second, the news:// URL is not fully qualified. It assumes that my company’s news server is the default news server, and that won’t be true for anyone outside my company.
Suppose I’ve started a thread on my company’s public news server. I can alert outsiders to it by placing the following fragment on a web page, in an email message, or even in another news message:
I’m researching a problem related to HTTP basic authentication. If you want to learn more or can help, see the thread at <news://udell.roninhouse.com/public.webteam> that begins with a message entitled “HTTP basic authentication techniques.”
Note that a news:// URL of this form leads people to the newsgroup, not to the individual message. In theory you should be able to do better than that. The recipient of your message shouldn’t have to scan the newsgroup to find the thread you’ve announced. You can cite the news:// URL of the thread’s initial posting in your message, and this ought to join the recipient directly to that thread. Unfortunately, although the current newsreaders enable us to try this interesting maneuver, they can’t yet quite deliver on its promise. Like the transition from web space to news space, the transition from email space to news space isn’t as smooth as it needs to be.
Will these kinks be smoothed out in the next generation of Internet mail/news clients? I’d like to think they will, but at the moment (summer 1999) the future of these tools is unclear. Netscape’s vision of Internet groupware produced, in Communicator, a profound integration of mail, news, and the Web. But few people ever discovered the full extent of that integration, and Netscape never adequately explained what had been accomplished or why it mattered. Will next-generation Internet groupware continue to weave the SMTP, NNTP, and HTTP strands more tightly? Or will a single uber-protocol (e.g., WebDAV) subsume them, as advanced browser technology (e.g., dynamic HTML) renders today’s standalone mailreaders and newsreaders obselete? I wish I knew, but my crystal ball is cloudy.
No matter which way the wind blows, today’s tools offer us another way to implement this push/pull mechanism. As we saw in the last chapter, discussions can (and should) present a web interface, whether or not the underlying engine is NNTP-based or HTTP-based. When that’s the case, an emailed invitation to join a thread can work more reliably. To do this requires a web-based discussion system that uses fully qualified http:// URLs to represent messages. Here are some examples of web discussion URLs:
The DejaNews URL shown in the previous list is particularly interesting. This http:// URL is stabler than the equivalent news:// URL. If my company receives a newsfeed that includes the newsgroup in which that message was posted (comp.groupware) and yours does too, then I could direct you to that thread by emailing you the URL news://news:3651AB74.71070E54@top.monad.net. It’s not a fully qualified URL, but if both of our local servers receive comp.groupware, then it will mean the same thing to both of our newsreaders. But not for long! The message will expire soon, and that makes transmitting news:// URLs that refer to Usenet postings a quixotic effort. In the DejaNews realm, though, the equivalent http:// URL will remain useful for a year or more.
This creates an interesting opportunity to rendezvous with other people on the Usenet. The DejaNews “Mail a Friend” service encourages you to do just that. If you start a Usenet thread and then use this service to invite people to join you in that thread, the link at the bottom of the email message those people will receive works quite cleverly. It refers not merely to your posting but to the entire thread—which might include your original posting and one or more replies.
If you’re working on a problem, odds are that someone else is working on the same or a similar problem. That person might work in your department, elsewhere in your company, or in a department like yours in another company halfway around the world. Vital collaboration can happen within any of these scopes. A public discussion space for users of your company’s products or services is an excellent way to build a brain trust. Usenet newsgroups and email lists can also gather valuable brain trusts.
There are, of course, limits to what you can say in public forums. Nobody should give up a competitive advantage by sharing the wrong kind of information. Nevertheless, collaboration among competitors is not a bizarre or unrealistic idea. Clearly you don’t want to divulge company secrets, but not all information is competitively advantageous. You and I might both be working on proprietary applications that exploit certain features of HTTP basic authentication. We needn’t reveal details about our respective projects in order to clarify our mutual understanding of how authentication works.
Nor need we collaborate altruistically. As in the case of open-source software, the guiding principle can be enlightened self-interest. The benefit of sharing information, measured in terms of the value of information received in turn, can outweigh the cost of sharing, measured in terms of the effort of collaboration and any competitive exposure that it entails.
Some people think that a culture of collaboration was one of the driving factors in the success of Silicon Valley. In a recent televised documentary, several high-tech executives noted that in the San Francisco Bay area, unlike Boston’s Route 128, engineers from different companies tended to congregate after hours to drink, socialize, and compare notes. Thanks to this collaboration, these executives theorized, Silicon Valley functioned more optimally than Route 128. Companies learned enough about each other’s successes and failures to avoid charting collision courses and to minimize redundant and wasteful effort. This assertion can probably never be proved, but it’s certainly provocative.
Finally, note that you can limit competitive exposure by forming another kind of scope. Consider a transcorporate discussion zone that is private, secure, and accessible by invitation only. Here a coalition can meet without revealing that it exists or what it discusses. In this era of merger mania, Internet groupware can be a simple, low-overhead way to build a temporary virtual community that can complement face-to-face visits during a courtship phase.
Get Practical Internet Groupware now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
