Adding Mobile Users To Your Community

part of Software Engineering for Internet Applications by Eve Andersson, Philip Greenspun, and Andrew Grumet; revised February 2005
Among the principles of sustainable online community in the "Planning" chapter of this textbook, 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 strain injury
Though the alternatives vary in popularity from country to country as we write this chapter (February 2005), there is no reason to believe that desktop computer programs such as Mozilla Firefox 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 this participation look like? The users you've considered thus far would probably be sitting at a desk with their hands keyboarding sixty words per minute and their gazes set upon an 20-inch screen. By contrast, a mobile 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 be able to type only five or ten words per minute. What kinds of content and means of participation will best suit this class of users?

Exercise 1

Either using your phone or one of the emulators discussed later in this chapter, use the mobile 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 of two or three services from your learning community that will be valuable to mobile users. You may find the following guidelines useful:


Though the bits may be transported through a proprietary network, anyone can serve content to mobile devices with a standard Web server (figure 9.1).

Figure 9.1: Content to mobile devices goes from an HTTP server on the public Internet via TCP/IP and is sometimes translated into proprietary formats and protocols within a phone company's wireless network before reaching the handset.

As illustrated above, the cell phone connects to your server through the service provider's wireless network. Depending on the phone and network, the "Wireless Network" cloud may contain standard Internet Protocol (IP) routing, a standard HTTP proxy, or a WAP gateway. In the last case, the gateway and phone communicate using a special set of protocols that, among other things, compresses data before transmission over the wireless network. The net effect is that the phone's browser (sometimes called a microbrowser) looks to a public HTTP server like a standard Web browser issuing HTTP GETs and POSTs.
The mobile industry is consuming markup languages at a rapid rate. The progression has taken us from the Handheld Device Markup Language (HDML; 1997) to the Wireless Markup Language (WML; 1998) to the current recommendation, XHTML Mobile Profile (XHTML-MP; 2001). We can take heart from the fact that XHTML-MP is derived from XHTML, the World Wide Web Consortion recommendation for standard browsers. Gone are the bad old days when a developer had to learn a new markup language, and servers had to be configured to send new Content-Type headers, in order to deliver mobile content. We expect that XHTML-MP will thereby enjoy wider adoption and greater stability.

Content is delivered in "XHTML Mobile Profile", a strict subset of XHTML, which is an XML-conformant version of HTML. Here's a shell session resulting in the return of an XHTML-MP document short enough to print in its entirety:

XHTML-MP Example Document
% telnet 80
Connected to
Escape character is '^]'.
GET /seia/mobile/ex1.html HTTP/1.0

HTTP/1.0 200 OK
MIME-Version: 1.0
Content-Type: text/html

<?xml version="1.0" encoding="UTF-8"?>

<html xmlns="" xml:lang="en">

     XHTML-MP Example

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


Connection closed by foreign host.
The text in bold (above) is what the programmer types, simulating a microbrowser request. The exchange looks a lot like what we'd see for a regular HTML browser. The main differences are the inclusion of the XML declaration and document-type definition in the first two lines of the document, and the use of the namespace attribute, xmlns, in the opening html tag.

A server wishing to distinguish between desktop and mobile users could search the contents of the HTTP Accept header for the string application/xhtml+xml; profile="", which is supposedly required by the XHTML Mobile Profile specification ( By contrast, a desktop browser, if it lists XHTML among the formats that it accepts, will generally not refer to the mobile profile. Here's what Microsoft Internet Explorer 6.0 supplies as an Accept header:

image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/, application/, application/msword, application/x-shockwave-flash, */*
Mozilla 1.4a (the open-source Netscape Navigator) does promise to accept XHTML:

Note that Mozilla is making full use of the original conception of the Web in which the server and the client would negotiate to provide the user with the best possible file in response to a request for an abstract URL. The order of the MIME types in the Accept header is irrelevant. The browser indicates its preference with quality values, for example in the value text/html;q=0.9, Mozilla is indicating that plain vanilla HTML is less preferred than the three preceding XML types, which default to a quality of 1.0. To learn more about this system, see the section on "Quality Values" in the HTTP 1.1 specification, at

A second method for distinguishing between desktop and microbrowsers is examining the User-Agent HTTP header. Consider the following two shell sessions, in which the user-typed input is highlighted in bold:

No Extra HeadersClaiming to be a Palm
% telnet 80
Connected to
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 200 OK
Date: Tue, 22 Apr 2003 01:20:53 GMT
Cache-control: private
Content-Type: text/html
Server: GWS/2.0
Content-length: 2691

<meta http-equiv="content-type" 
  content="text/html; charset=ISO-8859-1">

Connection closed by foreign host.
% telnet 80
Connected to
Escape character is '^]'.
GET / HTTP/1.1
User-Agent: UPG1 UP/4.0 (compatible; Blazer 1.0)

HTTP/1.1 302 Found
Date: Tue, 22 Apr 2003 01:37:18 GMT
Content-Type: text/html
Server: GWS/2.0
Content-length: 156

<H1>302 Moved</H1>
The document has moved
<A HREF="">here</A>.

Connection closed by foreign host.

Though neither request indicates a preferred media type, Google's server recognizes the "Blazer" browser that ships with Handspring palm-top devices and redirects the browser, via the response lines HTTP/1.1 302 Found and Location: Sadly, there is no centrally maintained registry of user agents and therefore success with this method is largely a matter of programmer diligence.

Exercise 3

Summary. Paste the XHTML-MP example document above, starting with the <?xml ...> declaration and running through the closing </html> tag, into a file called ex1.html on your Web server and load the example into different kinds of browsers. We recommend that you place this file in a /mbl/ subdirectory underneath your Web server's page root.

Step 1 — mobile browser. Load the page into a mobile browser and admire your handiwork. If you do not have access to a Web-enabled phone, install or locate emulator software, either a PC microbrowser emulator or Web-based tool. See the links at the end of this chapter for suggestions. Suppose for a moment that you had placed the document at /mbl/software-engineering-for-internet-applications/examples/example1.html. Would that affect the amount of time required to complete this exercise?

Figure 9.2:

Step 2 — desktop browser. Now load the page into your favorite desktop browser program. Marvel at the cross-browser compatibility of your document. Compare your subjective experience of the content in the two cases, then answer the following question: In a world where desktop browsers and mobile browsers can parse the same markup syntax, do we need to distinguish between the two, or can we serve the same document to every type of user?

Keypad Hyperlinks

Let's look at a page with hyperlinks:
<?xml version="1.0" encoding="UTF-8"?>

<html xmlns="" xml:lang="en">

     Student Life
      <li><a href="calendar" accesskey="1">Calendar</a></li>
      <li><a href="/academics/grades" accesskey="2">Grades</a></li>
      <li><a href="urgent-messages" accesskey="3">Urgent Messages</a></li>
      <li><a href="events/frat-parties" accesskey="4">Fraternity Parties</a></li>
      <li><a href="" accesskey="5">News</a></li>


Figure 9.3:

A numbered series of choices is presented in a list, with each choice hyperlinked to the appropriate target. We take advantage of the anchor tag's accesskey attribute to improve usability by letting the user link to any of the choices with a single keypress.

Exercise 4

Forms and server-side processing work the same way for mobile browsers as they do for desktop browsers. Write an XHTML-MP document that 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. 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 "/mbl/".

Exercise 5: Authentication via Cookies

The phones and gateways in the U.S. 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 illegal in the strict HTTP specification, but desktop browsers have typically been 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 since typing a full email address is pretty painful on a numeric keypad. Note that on an organization's intranet site you can autocomplete the "" or "" portion of the email address for most users.

Exercise 6: Linking to a phone number

Check and (requires free registration) for information about the Wireless Telephony Application Interface (WTAI). Write a page entitled "mom.html" 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 Chase (1973, dir. James Bridges).

Exercise 7: 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 XHTML-MP, the following information:

Exercise 8: Design and Build the Mobile Interface to your Community

Now that you've mastered the fundamentals, design and build the mobile interface to your community. Keep in mind that The mobile interface should be accessible to the mobile user who types only the hostname of your site, i.e., the user should not have to type in the "/mbl/" subdirectory. This is typically accomplished by an IF statement in the top-level script of your Web server's page root.

This is a good opportunity to be creative. Browsing from a phone can be slow, expensive, and painful. Every line of information has to be critically important to the user. To get you started, here are a few ideas:

Exercise 9: Client Signoff

Mobile interfaces are a little too outré for many clients, and thus you can't ask them for ideas without first showing them something that works and that is relevant to their users. Show your mobile 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

Thus far we've considered the synchronous request/response model, brought over to mobile devices from the world of desktop Web surfing. In another common form of communication, the user receives asynchronously from a server robot or a fellow community member. Desktop users will recognize email alerts and instant messaging as applications of this mode. Two key requirements for asynchronous, user-bound communication are (a) the user must be addressable, e.g. by an email address or a screen name, and (b) the user must be running software that is listening on their behalf, e.g. a mail server or an instant messaging client. These capabilities are known collectively as push to the wireless industry.

Depending on the user's wireless service provider, there may be opportunities to push text or multimedia messages out to your user as interesting events unfold within your community. Many mobile phones, for example, can receive short text messages through the email system. The phone's "email address" is formed by appending a provider-specific domain to the phone's voice number. So if John's Verizon Wireless phone number is 617-555-1212, we can alert him by sending email to

The Future

In most countries the mobile Internet has not lived up to expectations of wide success. The standout exception is the i-mode system, which has become the dominant means of Internet access in Japan. We think that two reasons explain i-mode's relative success: always-on connectivity and revenue opportunities for publishers.

Western mobile Internet systems typically involved a dialup and sign-on delay of as long as two minutes for the first page; with the always-on i-mode system, the user gets consistent performance and relatively quick results for initial requests. Early Western mobile systems charged per minute, which was painful for users who typed text slowly on numeric keypads and received pages at 9800 baud. Always-on systems such as i-mode tend to charge a per-byte or flat per-month rate for access, which greatly reduces the possibility of a huge end-of-month bill.

In most mobile Internet 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 early system in the U.S. made it easy to connect to and shop for books, which turned out not to be a popular activity. DoCoMo, the Japanese company that runs the i-mode service, took 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 percent commission.

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

Is there hope that the mobile Internet will eventually become as popular as i-mode is in Japan? The first ray of hope was provided by General Packet Radio Service (GPRS). 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 can, in theory, deliver an "always-on" experience similar to that of i-mode 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 two or three 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;

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. For more on the subject of GPRS see Peter Rysavy's "Emerging Technology: Clear Signals for General Packet Radio Service" in Network Magazine, December 2000 (


Standards information: Software development kits ("SDKs") and WAP-enabled browsers are available from General Packet Radio Service (GPRS): The old WML standard:

Time and Motion

Each member of the team should work through the basics, Exercises 1-6, individually and expect to spend roughly five hours doing so.

The team should plan to spend one to two hours together designing the mobile interface, but may divide the work of prototyping and refining the mobile interface. A reasonable scope is eight to twelve programmer-hours.

The time required for client signoff will vary depending on the client's level of interest and familiarity with the mobile Web. Plan to spend at least thirty minutes on the signoff.

Return to Table of Contents,,