Adding Wireless Users To Your Community

an obsolete former chapter of Internet Application Workbook
This old chapter is here for people who need to program for old (circa 2000) systems that use the WAP/WML standard. A new version of this chapter is available at http://philip.greenspun.com/seia/mobile/.

Among the principles of sustainable online community in the planning section of this workbook, notice that the following are not mentioned:

  1. means of waiting for machines to boot up
  2. means of chaining users to their desks
  3. means of producing repetitive stress injury
Though the alternatives vary in popularity from country to country as we write this chapter (April 2001), there is no reason to believe that desktop computer programs such as Netscape Navigator and Microsoft Internet Explorer are the best way of participating in online communities.

In this chapter you'll learn how to open your community to users connecting from small mobile devices.

Be the user

If you were to close your eyes and visualize a person participating in your community, what would it look like? The users you've considered thus far would probably be sitting at a desk with their hands keyboarding 60 words per minute and their gazes set upon a 21-inch CRT screen. By contrast, a wireless user might be walking along a busy street or looking down from a mountain top. Their screen will be a few inches across, and they may only be able to type five or ten words per minute. What kinds of content and means of participation will best suit this second class of users?

Exercise 1

Either using your phone or one of the emulators discussed later in this chapter, use the wireless Internet to For each task, write down how long it takes you to accomplish the task. Then repeat the tasks with a desktop HTML browser and write down how long each task takes.

Exercise 2

Come up with a list two or three services from your learning community that will be valuable to mobile users. You may find the following guidelines useful:

The Wireless Application Protocol

We will assume in this chapter that you are developing your applications with the Wireless Application Protocol (WAP), whose standards making body is http://www.wapforum.org. You can serve WAP content to wireless devices with a standard Web server:



After the WAP Architecture Specification, Figure 2.

The cell phone connects to your Web server through a service provider's gateway. The gateway translates encoded requests from the phone to standard HTTP GETs and POSTs, fetches the results, encodes the results, and returns the results to the phone. Data are passed between the gateway and cell phone in a compressed binary format, using a WAP-specific set of protocols (i.e., Internet Protocol is not used between the phone and the service provider). The gateway also manages the relatively unreliable network connection to the phone.

WAP content is delivered in Wireless Markup Language (WML) format. WML supports a somewhat different set of user interactions than HTML, and adheres strictly to the XML standard. To serve a user on a WAP device, the Web server needs to recognize that the request is coming from a WAP device and return WML with the appropriate HTTP headers and tags:

bash-2.03$ telnet www.photo.net 80
GET / HTTP/1.0
User-Agent: UP.Browser
Accept: text/vnd.wap.wml

HTTP/1.0 200 OK
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Content-Type: text/vnd.wap.wml; charset=iso-8859-1
MIME-Version: 1.0
Date: Sun, 22 Apr 2001 15:29:35 GMT
Server: NaviServer/2.0 AOLserver/3.2+ad12
Content-Length: 1179
Connection: close

<?xml version="1.0"?> 
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">
    <wml>
    <head>
    <meta http-equiv="Cache-Control" content="max-age=0"/>
    </head>  ...
The text in bold (above) is what the programmer types, simulating a WAP microbrowser request. Note that in the returned headers and deck from the photo.net server are three "don't cache me" incantations. Your phone and your phone company will take every opportunity to cache a WAP screen, by default for as long as 30 days. Reloading at 10 Kbits per second isn't much fun. As you're developing a service, however, this caching becomes a curse.

Here's a simpler return result, of a WAP deck short enough to print in its entirety:


HTTP/1.0 200 OK
MIME-Version: 1.0
Content-Type: text/vnd.wap.wml

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>
 <card>
  <p>We're not in the 1970s anymore.</p>
 </card>
</wml>

  

WML documents are designated by the text/vnd.wap.wml Content-Type and must all be prefaced with tags indicating the XML version and document type definition. WML documents consist of any number of discrete page views, or cards. A complete document consisting of several cards is referred to as a deck. The main distinction between a deck of cards and a collection of HTML pages is that the entire deck is loaded atomically. This provides a better user experience on browsers with small displays on slow, unreliable networks.

Exercise 3

Summary. Paste the example above into a file called first-page.wml on your Web server and load the example into a WAP browser. We recommend that you place this file in a /wap/ subdirectory underneath your Web server's page root.

Step 1 -- headers. Your Web server should provide a means of setting the Content-Type header for the outgoing response. If you are lucky, the .wml extension on your source file will be sufficient to alert the server that the correct content type is text/vnd.wap.wml. If not, you will either have to register this rule with the server or explicitly set the headers in a script or servlet responsible for returning the markup.

Step 2 -- telnet. Test your handiwork by issuing a GET request for first-page.wml using telnet. With the possible exception of extra output headers, the server response should exactly match the example highlighted above.

Step 3 -- emulator. Install or locate a WAP emulator, either a PC microbrowser emulator or Web-based tool. See the links at the end of this chapter for popular emulators. Load the page again, this time using the emulator.

Step 4 -- phone. Find a WAP phone with wireless Web enabled and load the page again. While expensive, this mode of development has the very important characteristic of realism. Ideally, your development environment will use a mixture of PC emulators and real microbrowsers. [hint: most microbrowsers contain a "Go To" function for typing in free-form URLs.]

More WML

The deck in the "first-page" example contains just a single card with a static message. Here is a more elaborate example:

HTTP/1.0 200 OK
MIME-Version: 1.0
Content-Type: text/vnd.wap.wml

<?xml version="1.0"?> 
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
  
<wml>

 <!-- This is the first card. -->
 <card>
  <do type="accept" label="Answer">
   <go href="#card2"/>
  </do>
  <p>What is your name:
    <input name="Name"/></p>
 </card>

 <!-- This is the second card. -->
 <card id="card2">
  <do type="accept" label="Answer">
   <go href="#card3"/>
  </do>
  <p>What is your favorite color?
  <select name="Favorite">
   <option value="red">Red</option>
   <option value="blue">No, blue!</option>
  </select></p>
 </card>

 <!-- This is the third card. -->
 <card id="card3">
  <p>Name: $(Name)<br/>
    Color: $(Favorite)</p>
 </card>

</wml>

  
What it might look like on your phone:

First Card

Second Card

Third Card

This deck consists of three cards. The first two prompt the user for input and the third displays the results. Results are passed between cards using the document-level variables Name and Favorite. Variable substitution is effected by prefixing variables names with a dollar sign ($) and enclosing them in parenthesis. Navigation between cards is handled with go tasks inside card-level do elements. The do element provides a general mechanism for users to act on cards. The type attribute indicates what kind of action to associate with the do. An "accept" action occurs when the user hits the OK button on her cell phone. The go task plays a role similar to the HTML form element, containing a target URL and optionally query data and method type. The notable difference here is that user interface code appears outside the go task.

Exercise 4

Write a single WAP deck which prompts for an email address (or screen name if you've decided to ignore the sociologists' advice about anonymity) and password, then POSTs these to a target on your server. Refer to the WML specification at http://www.wapforum.org. The server's response should print back the email address entered and the first character of the password, followed by one period for each subsequent password character. We recommend that you place your code so that it is accessible via URIs starting with "/wap/".

Exercise 5: Authentication via Subscriber Number

Every phone contains a unique "subscriber number" ID that should be transmitted with every WAP request. Here's an example from a Sprint PCS phone:
x-up-subno=yMrSkytUzuPxQs01_up2.upl.sprintpcs.com
A PC emulator will very likely try to construct a subscriber number using the hostname of your machine. Here's one recorded from a session with an Unwired Planet emulator:
x-up-subno=nobody_laptop.grumet.net

What kinds of personalization can you support using this method of authentication? Could you use subscriber number authentication to manage a shopping cart? Are there any security risks associated with this method of authentication? What is the disadvantage to the user, from a convenience point of view, of a WAP service that uses only this method of authentication for personalization, etc.?

Exercise 6: Authentication via Cookies

The phones and gateways in the US that we've tried have supported HTTP cookies, including persistent cookies, in the same manner as standard Web browsers, with one exception: a comma in a cookie value breaks everything. (Note that commas are in fact illegal in the strict HTTP specification but desktop browsers are typically permissive.)

For authentication via cookies you need to go back to the form built for Exercise 4 and back it up with a script that generates a Set-Cookie header with an authentication token. We recommend that you make this cookie persistent as typing a full email address is pretty painful on a numeric keypad. Note that on an organization's intranet site you can autocomplete the "@foobar.com" or "@yow.org" portion of the email address for most users.

Exercise 7: Linking to a phone number

Check http://www.arsdigita.com/asj/wireless/, http://www.wapforum.org and http://developer.openwave.com (requires free registration) for information about Wireless Telephony Application Interface (WTAI). Write a WML page entitled "mom.wml" that serves a link anchored by the text "Here is a dime; Go call your mother, and tell her there are serious doubts as to whether you will become a lawyer". When this link is followed, the telephone should dial your mother's phone number. We apologize for the inappropriate length of this hyperlink anchor but just in case you end up in an organization where self-esteem is valued more than achievement, we thought it would be good to remind everyone what life is like at Harvard Law School.

Background: The Paper Case (1973).

Exercise 8: Build a Pulse Page

You're walking around and someone expresses skepticism that your online learning community is worthwhile. You whip out your phone and go to the "pulse" page on your server. This returns, in WML, the following information:

Exercise 9: Build the WAP interface to your community

Now that you've mastered the fundamentals, build the WAP interface to your community. Keep in mind that The WAP interface should be accessible to the mobile user who types only the hostname of your site, i.e., the WAP user should not have to type in the "/wap/" subdirectory. This is typically accomplished by an if statement in the index.adp, index.pl, or index.tcl script at the top level of your Web server's page root.

Exercise 10: Client Signoff

WAP is a little too outré for many clients and thus you can't ask them for WAP ideas without first showing them something that works and that is relevant to their users. Show your WAP interface to the client, ideally in a face-to-face meeting where you use a real phone. If you can't arrange that, have a face-to-face meeting where you use an emulator. If that isn't practical, try to work through the interface in a conference call, during which the client uses either a phone or an emulator.

Write down the client's answers to the following questions:

Watch for Opportunities to Push

Depending on the user's wireless service provider, there may be opportunities to push text messages and WAP decks out to your user as interesting events unfold within your community.

The Future

WAP has been a failure with users and a failure commercially in most countries worldwide. By contrast, the very similar iMode system has become the dominant means of Internet access in Japan. Both systems entail small screens. Both systems force the user to wait for an agonizingly slow connection (around 10 Kbits per second). Why then has iMode succeeded where WAP has failed? We think that two reasons explain iMode's relative success: always-on connectivity and revenue opportunities for publishers.

A WAP session is sort of like using an old-style modem-based ISP. User explicitly connects. User waits for connection. User views WAP screens, all the while aware that every second of operation is running up the bill. If the server is slow, the user pays more for the same information. If the user is a slow typist (not too hard to imagine when typing letters on a numeric keypad), the user pays more for the same information. iMode, by contrast, is always-on, like a wired-in computer on a university desktop or a home computer connected via cable modem. A user can leave an iMode page on the screen, follow a link 15 minutes later, and pay the same per-byte charge that would have been paid if the pages had been requested in immediate succession.

In WAP systems, the phone company decides what sites are going to be interesting to users and places them on a set of default bookmarks. The phone company often charges the site publisher to be promoted to its customers. The result? Every WAP system in the US makes it easy to connect to amazon.com and shop for books. A user can type in "www.photo.net" and get a WAP update on the community but it is tedious to type and, though the phone company is raking in 10 cents per minute, the publishers of photo.net are getting nothing. What incentive do the programmers at photo.net have to improve the WAP version of the service? In the HTML world, a commercial publisher can at least take comfort from the idea that every page requested means the opportunity to sell a banner advertisement. But in the WAP world, it would seem the only the phone company and etailers have any opportunity to sustain themselves. DoCoMo, the Japanese company that runs the iMode service, takes a different approach. DoCoMo decided that they weren't creative enough to figure out what consumers would want out of the mobile Internet. They therefore came up with a system in which content providers are more or less equally available. Content providers can earn revenue via banner advertisements or by charging for premium content. When a provider wants to charge, DoCoMo handles the payment, taking a 5-9% commission.

The combination of always-on and non-starvation for content providers has created an explosion of creativity on the part of publishers. The most popular services seem to those that connect people with other people, rather than business-to-consumer amazon.com-style ecommerce.

Is there hope that WAP systems will eventually become as popular as iMode is in Japan? The first ray of hope is provided by General Packet Radio Service (GPRS), being rolled out worldwide in 2001. GPRS takes advantage of lulls in voice traffic within a cell to deliver a theoretically maximum of 160Kbits/second via unused frequencies at any particular moment. GPRS requires new handsets that are equipped to listen simultaneously on both the dedicated circuit-switched connection in use for a voice call and also monitor GPRS frequencies for incoming packets. In practice, GPRS may provide only three or four times faster throughput than existing WAP systems. More important is the fact that GPRS delivers an "always-on" experience similar to that of iMode or a hardwired desktop computer.

As noted above, with GPRS the wireless Internet will become a place that supports simultaneous voice and text interaction. For example, the following scenario can be realized:

Notice that voice prompting and recognition are convenient when a user is choosing from among hundreds of alternatives, e.g., the world's airports. However, voice becomes agonizing if the user must listen to a long list of detailed choices--prompting with text may be much better when more than 2 or 3 choices are available, especially if each choice requires elaborate specification. Keep in mind "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" by George A. Miller (The Psychological Review, 1956, vol. 63, pp. 81-97; http://www.well.com/user/smalin/miller.html).

There is no evidence that the phone companies outside Japan will wise up to the power of revenue sharing. However, with the introduction of GPRS the wireless Internet will become something better than a novelty. See http://www.rysavy.com/Articles/GPRS2/gprs2.html for more on the subject of GPRS.

More

Overview: General WAP/WML information:

SDK's and WAP-enabled browsers are available from

Web Application Programming tools


Return to Table of Contents

aegrumet@alum.mit.edu