Practical Internet Groupware

Using Messages to Conduct Polls

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.

Method 1: Message-Based Polling with Parameterized mailto: URLs

It’s commonly known that a mailto: URL on a web page (or in a newsgroup posting or email message) will, when clicked, launch an instance of the Netscape or Microsoft message composer and put the email address encoded in the link into the To: field of a new message. On a web page, the HTML syntax looks like this: <a href="mailto:[e-mail]">contact Jon</a>. In a newsgroup posting or email message, you can simply write mailto:[e-mail]; the Netscape and Microsoft mailreaders will both autoactivate the URL and render it clickable.

Less commonly known is that the link can also carry other header fields, notably the Subject: header. This technique, coupled with mail filtering, enables users of Netscape Messenger or Microsoft Outlook Express to create simple but useful polling applications. This HTML fragment is the frontend of a survey application:

<h1>Udell Airways Hub Preference Survey</h1>

<p>We currently use Newark as our hub, but we must now decide between
Boston and LaGuardia. We'd like your feedback.

<p><a href="mailto:[e-mail]?subject=HubBoston">I prefer Boston</a>
<p><a href="mailto:[e-mail]?subject=HubLaGuardia">I prefer LaGuardia</a>

Notice that the mail address isn’t something like [e-mail]. This airline is a low-budget operation. It doesn’t have its own domain name or mail server, and it’s too cheap even to buy an extra mail drop. So the proprietor’s own personal email account at his ISP will handle the survey.

Now here’s the backend of the application:

• Two inbox folders entitled “Boston” and “LaGuardia”

• A mail filter that says: “If the Subject: contains HubBoston, then move to folder “`Boston’”

• A similar filter for the LaGuardia option

This trivial solution nonetheless solves two important problems: it counts the responses in each category (because mailboxes count messages in folders), and it enables review of the comments sent with each response. This ability to combine numeric and textual analysis of a data set is powerful. It’s surprising and delightful to find such a minimal solution. Figure 4.6 shows how to set up the Boston filter in the dialog box invoked by Messenger’s Edit → Mail Filters → New.

Figure 4-6. Mail filtering in Netscape Messenger

Note that you have to create the Boston folder first in order to be able to select it in the filter dialog. Also note that you don’t have to use the GUI dialog. The mail filters are recorded in a text file, which on my machine is called c:\Program Files\Netscape\Users\jon\Mail\rules.dat. Here’s the text equivalent of the Boston rule:

name="HubBoston"
enabled="yes"

description="Udell Airways Hub Preference Survey: Boston option"
type="1"
action="Move to folder"
actionValue="Inbox.sbd/HubBoston"
condition="(subject,contains,HubBoston)"

It’s actually easier to use the GUI in this case, but for complex jobs it’s nice to know that you can write the rules directly.

In Outlook Express, you access the filters from Tools → Inbox Assistant → Add. Here too, you have to create the target folder first. Then you can specify the rule, as shown in Figure 4.7.

Figure 4-7. Mail filtering in Outlook Express

The advantages of this approach are twofold. First, it’s something anyone can do. If you have a web page, you can post parameterized mailto: URLs there. If not, you can still include such URLs in email messages or newsgroup postings. Second, it combines numeric and textual analysis. When you conduct this survey, the anecdotal responses from people are often at least as significant as the numbers of responses in each category. The filters do double duty. They count responses—again, just because folders count the number of items they contain—and they also make it easy to review the messages routed into each folder.

Method 2: Message-based Polling Using a Polling Application’s Web API

One of the main themes running through this book is the notion that web sites, and the applications that run on them (e.g., CGI scripts, Java servlets), have a dual nature. From the perspective of a person running a browser, a web site is an interactive application. We think of a URL as an address that produces a web page. From the perspective of a script—specifically, a web-client script that programmatically uses the HTTP protocol—a web site is a software component. In this case the same URL acts like a function call, possibly parameterized, which yields a well-defined result. When you use a web site or one of its applications this way, it’s useful to think of it as implementing an application programming interface (API).

A few years ago I wrote a Java servlet called Polls (http://udell.roninhouse.com/download/Polls.zip). Like GroupCal, a group-calendar servlet that we’ll see in Chapter 10, Polls makes a Java data structure readable and writable by browsers (or by HTTP-aware scripts). The details aren’t important here. What matters is only the web API that Polls presents to browsers or scripts.

Here is a URL that creates a new poll, called Picnic99, with three choices for the date of a company picnic:

http://host/Polls?name=Picnic99&1=Sat+June+12&2=Sat+June+19&3=Sun+June+20

Here is a URL that records a vote for the June 20 date:

http://host/Polls?name=Picnic99&vote=Sun+June+20

And here is a URL that asks for a tally of votes:

http://host/Polls?name=Picnic99&tally=

With the Polls servlet running in your environment, you can create a poll by plugging the first of the previous three URLs into your browser. The servlet responds with a web page that announces: “Poll Picnic99 created.” Users of the poll can vote using the second URL; in this case the servlet responds with a page that announces: “Vote received.” Finally, you can view results using the third URL; the servlet emits an HTML table that lists the choices and number of votes for each choice.

This mechanism works easily for users, who need only click on URLs that appear in email or newsgroup messages. But it’s not so convenient for a poll creator. To make a new poll, you have to compose and issue the long and complex URL that tells the Polls servlet to create a new poll object with the set of choices you specify. Then you have to write the URLs that users will click to vote for each of the choices or to view the tally. Nobody’s going to want to type all this stuff, and nobody should have to. The mechanism can be packaged up more neatly. Suppose, for example, that a user who wants to create a new poll can fill out a form like the one shown in Figure 4.8.

Figure 4-8. Web form to create a poll

The user of the form types in the name of a new poll and up to five choices. The handler for this form—a Perl script that uses methods we’ll explore in great detail in Part II—constructs the URL that creates the poll, and transmits it to the server that is hosting the Polls servlet. Again, we’ll see how this kind of thing works in Part II. For now, it’s enough to note that when the script uses the servlet’s web API in this way, the servlet creates a new poll called Picnic99, with slots to record votes for the three dates.

Next, the script manufactures URLs used to operate the poll. And these URLs are, in fact, the output of the script, as shown in Example 4.1:

Example 4-1. URLs Manufactured by the Poll-Creating Script

Here are the URLs for voting in the Picnic99 poll:

Choice: Sat June 12
<http://host/Polls?name=Picnic99&vote=Sat+June+12>

Choice: Sat June 19
<http://host/Polls?name=Picnic99&vote=Sat+June+19>

Choice: Sun Jun 20
<http://host/Polls?name=Picnic99&vote=Sun+June+20>

Here is the URL for viewing the tally:

<http://host/Polls?name=Picnic99&tally=>

You can paste this text into an email message that you send to the group that you want to poll. Or, if there’s a newsgroup frequented by the members of that group, you can copy the output into a message that you post to that newsgroup. Either way, by email push or newsgroup pull, you present the group with a web API to the polling application. And you present it in a context that reduces the desired input to clicks on hyperlinks, which will be autoactivated in either a mailreader or a newsreader.

What about really long URLs? In this case, as we’ve already seen, URL autoactivation in a plain-text message can break, so an HTML message is the best approach. Unfortunately, you can’t just take HTML output, which a script such as this one might generate, and paste it into a freshly composed message. Even though you can set your message composer to work in HTML mode, HTML text that you paste into the composer won’t be rendered as HTML. Rather, it will be flattened into its textual representation. The solution, shown in Part II (see Example 6.13), is to have the script both compose and transmit a complete HTML message comprising a special header (Content-Type: text/html or Content-Type: multipart/related) and an HTML body.

To sum up: this approach relies on the fact that a set of URLs can create a formless, transportable interface to a web application. It’s true that HTML-aware mailreaders and newsreaders support full-blown HTML forms, and you can mail or post such forms. But empowering end users to build and distribute such forms is a tall order. In any case, for a quick poll like this one, an HTML form might be overkill. Formless URL-driven data entry is a lightweight, practical alternative.