1. Introduction

Good design:

1) Fulfills its function.

2) Respects its materials.

3) Is suited to method of production.

4) Combines these in Imaginative Expression.

These words of wisdom were salvaged from a curator in the 1940’s at the New York Museum of Modern Art. They are still the prevailing wisdom for the design of manufactured objects; I believe that they can also be used to inform the design of software systems:

· A chair should be comfortable to sit in, a software system that is intended to get you a stock quote should get you a stock quote.

· You wouldn’t make a chair out of thin silk. You shouldn’t try to display huge amounts of graphic data on a five-line monochrome display or send wordy messages in a medium that only supports 160 characters at a time.

· It should be inexpensive to manufacture designed objects; software systems should scale easily to meet increased demand.

· People would rather use an object or an application that is fun and imaginative than one that is not – as long as it fulfills its function and respects its materials.

In this paper, I look at wireless applications with the above guidelines as a background, and point the way to what works today, what does not, and make some suggestions for how to improve things.

2. What is meant by “Wireless”

First, let us define what is meant by “wireless applications”. Wireless has come to mean everything from fixed wireless, a point-to-point microwave connection between two geographically fixed locations (e.g., a home and an office), 802.11b, a medium-range local area network protocol that provides a wireless replacement for Ethernet, Bluetooth, a short range wireless protocol initially meant for cable replacement between keyboards, printers and computers, or headsets and cell phones, to any variety of cell phone protocols, and beyond.

In this paper, I focus on cell phone protocols. In particular, I focus on the Short Messaging Service (SMS) protocol. I choose this because it represents the most widely deployed protocol, the protocol that is implemented in the devices that people are carrying today. I will purposely ignore WAP, CDPD, ARDIS, et al; even though they are popular with large portions of certain types of users, they have not realized any large market penetration when compared to SMS.

I am also putting off, for the time being, the great and glorious world that is promised by 2.5G and 3G protocols, when every phone will be on the Internet. When the carriers and handset manufacturers actually build it, let’s talk again.

For now, I want to talk about what’s in the hearts and minds and pockets of people right now. And that means SMS … and voice. I hope to convince the reader that this combination is much more powerful than commonly thought, if only attention is paid to the design of the applications that use it.

3. Where we are and how we got here

It can be argued that the United States is far behind the rest of the world (with the exception of South America) in cell phone technology. Europe standardized on a single protocol, GSM, in approximately 1994. This has given the Europeans seven years to think about how to use the SMS features that came for free with their GSM handsets, and for GSM carriers to make the serendipitous discovery that consumers enjoyed typing short, abbreviated messages with their thumbs, that asynchronous messaging has a place in the spectrum of person-to-person communication, and that this kind of messaging is addicting – especially for the 16-to-24 year old demographic.

The small community that lived on the Internet before “the Web” made its debut understood this, about email. As the Web became more popular, especially in the US, so did email. But more than email, the Web offered its users a rich, multi-media experience including color photos, sound, and eventually streaming video and 3D models that can be “flown” through in real time. Email was always in the background, but it has been somewhat overtaken by instant messaging – in the old days, no one much cared about instant messaging, because email delivery was instant! But as the nets have grown, and have grown slower, email delays have also grown. Instant messaging (IM) has grown in popularity as the “quick” way to reach colleagues and friends.

The US cellular carriers were and are still struggling with three digital formats and one analog format, none of which is compatible with the rest of the world, and none of which routinely include two-way SMS messaging (apparently because carriers believe that no one could possibly want that!)

Europeans were (and are) slowly adopting the Web.

Slowly, in the late 1990s, two things happened:

1. Cellular handset designers looked at the rich user experience provided by the web with envy, and tried their hand at building their own version of it. This resulted in WAP, a pale imitation of even the earliest Web experience at 14.4kbps. There is no color and only text. Each carrier exercises tight control over the sites that a consumer sees on his or her home page, giving prominent placement to those sites that pay the most. There is little or no content – and what content is there has often been poorly repurposed from existing HTML content. WAP has been a flop, so far – and I would argue that it could be traced to not paying attention to the design “rules” in the introduction. (A similar argument can be made about other browser-based devices, including the current implementations on wireless Palms.)

2. Cellular providers in the US noticed that this email thing was popular, and recognized that they might improve their ARPU (Average Revenue per User) by allowing consumers to send email to their handsets, in imitation of pagers. Unfortunately, pagers are cheaper to buy, have more text capacity, and have a flat rate for the end consumer, so the pager replacement idea never really took off. In addition, most cellular handsets that have been deployed are receive-only, negating almost all the value of having a text communication device in your pocket. A few carriers started selling phones with two-way features, but didn’t deploy enough infrastructure to make the service reliable or fast. They just didn’t get it.

The RIM Pager made a change in that – it provided a device with two-way email that is tied to the enterprise that has a decent revenue model. It moved back to the revenue model the US carriers understood – selling large buckets of service features to business users. This seems to have pushed the cellular carriers over the edge into offering two-way email on new phones, and encouraged them to explore the vagaries of exchanging messages between users of different carriers.

We’ve started to see pre-pay solutions in the US, targeting the 16-to-24 year olds. Soon, we might only have two network technologies to worry about.

Browser-based mobile applications are still being built as stripped down versions of their large-scale brethren. Web-based apps have just gotten more and more heavyweight as Moore’s Law has increased the availability of CPU cycles and memory on the average business user’s desktop computer, and broadband connections have increased the average bit rate to the home consumer.

Unfortunately, WAP phones haven’t gotten bigger or faster, so the user experience has just gotten worse. And carriers don’t seem to be getting any smarter: in announcing their 2.5G service and pricing in Seattle, AT&T Wireless indicated that a stock quote would consume about 10Kbytes of your data quota – when the information in that quote can be comfortably presented in less than 160 as an SMS message.

4. Who uses wireless applications?

The techniques and applications discussed in this paper are not aimed strictly at the mobile worker – but rather at anyone who is willing to carry a wireless device and wants to do something other than engage in conversation with it. That said, mobile workers are the explicit targets of the more involved example applications, because they tend to have more involved requirements.

4.1. The mobile worker

The mobile worker is trying to solve a very complex problem, which is not simply addressed by the commonly held goal of access “anytime, anywhere”. Key to this is the identification of four key factors in mobile work: the role of pre-planning, working in “dead time,” accessing remote resources, and monitoring the activities of remote colleagues. Mobile technologies for mobile workers are intended to give back control over when and where they can work.

Mobile work is not just about the primary purpose of the trip but also the activities that occur in “dead time”. Mobile workers are away from their desks, but that does not mean that their every day work disappears – they are often fighting a growing pile of accumulating paperwork and need to deal with it before it becomes unmanageable. Pre-planning what documents are on their mobile (but not necessarily connected) devices is part of this, as is contact with remote co-workers.

Information “access” is not simply about having the ability to pull an appropriate document from a remote network. From the perspective of the mobile worker, access needs to be extended to include how information is used and whether it can be easily read or interacted with. Current data enabled devices appear to provide poor facilities for this.

Simple data-enabled mobile devices and miniaturized desktop technologies will not by themselves create more effective workers. Unlike the futuristic expectations of a “road warrior” carrying a range of technologies around with them, we see a leaner individual, more adaptable to the changing circumstances that they encounter, and using their skills at manipulating the environment and collaborating with others to carry out their work. This is a very different vision of mobile technology to that advertised of “always on” connectivity.

4.2. Everyone else

A key premise of this paper is that the majority of users only want to carry one device. Certainly there are those who happily carry the role of mobile worker over into the rest of their life and have three or four gray gizmos clipped to their belts, but we believe that they are in the minority. They may be the paying minority, or the minority that the carriers understand how to sell to, but I think they are in the minority of the addressable market.

If most users had to choose only one gizmo to carry, it would be their phone. Some would argue that they value their calendar, their contact list, to-do list or their shopping list more highly than their phone. We would counter that, without a phone, those items are less useful – and that a phone with two-way SMS can substitute for them adequately, if not perfectly.

There are certainly times when it is desirable to use a laptop, PDA or palmtop in concert with a phone to make a data connection. This is difficult to do in the US, somewhat easier in Europe. But when going out for the evening or on the weekend, there is no wish to carry a palmtop – but there is a desire to have access to the data that run one’s life. So the phone has to do the job.

Of the four key factors in mobile work listed above, pre-planning is non-existent in “mobile life”, and there are precious few requirements for monitoring the activities of remote colleagues (but more about that later). Mobile life is mostly about dealing with “dead time” and accessing information – either on-demand or implicitly, via alerts.

5. Example techniques

The following sections outline what we’ve learned about building useful applications on ordinary cell phones. Many, if not all, of these applications can and have been built on browser-based wireless devices – the point is not that these applications are particularly novel, but that they can be usefully built on the humble SMS-capable phone.

5.1. Alerts

The first, most obvious kind of “application” for a wireless device is notification. Our lives are busy enough that it’s preferable to have an “external memory” – and, honoring the somewhat facetious comment that “if you’re five feet away from your desk, you’re mobile”, the mobile worker needs/wants to be reachable. Perhaps that should be restated as “the mobile human needs/wants to be reachable”.

That said, many people prefer not to give out their cell phone number because taking a voice call can be intrusive, impolite, or just plain inconvenient. Long-time users of email understand the value of asynchronous communication; your recipient doesn’t have to be available when you are. You don’t have to pay immediate attention when you receive a message. SMS messages mimic this very well.

In addition, voice messages are fleeting – if there is important information in the message, one must find a pencil and pad of paper to note it down. An SMS message can be saved in the phone and referred to again for as long as it is needed.

There are many application areas that come to mind, and many of them are already deployed in different parts of the world:

· Banks and credit card vendors are sending alerts about balances, suspicious activity bills that are due, cleared checks.

· Delivery services are providing notification when a package has arrived at its destination

· Television networks are sending alerts about episode details; sports services are sending alerts about results

· Brokerages are sending stock alerts, order fulfillment notifications and margin calls

· CRM, ERP and other business process software is sending alerts when notable events occur

· Email systems are sending notification of “important messages”

· Airlines are sending flight status notifications

· Calendaring systems are sending reminders of meetings about to start

· Cities are sending flood and tornado warnings to residents

· Transportation agencies (and others) are sending out traffic alerts.

5.2. Two-way communication is better than one way

As useful as these alerts are, many of them are made considerably more useful if it is possible to reply. For example, a stock alert message might offer the ability to act upon the stock (buy, sell or talk to your broker). A flight status notification might offer to rebook on a different flight. An ERP system might allow you to approve a purchase order while on the go.

Security is obviously an issue here. That is, authentication and identification are obviously an issue here – if you’re going to approve a purchase order or stock trade, there should be a reasonable degree of certainty that you are you and you are authorized to do so.

Traditionally, identification and authentication measures have centered on one of three things: something you know, something you are, or something you have. These typically translate to “passwords”, “biometrics”, and “access tokens”. A good system uses two of these things together. Paranoid systems use all three.

The cell phone in your hand (or, rather, the caller ID information associated with it) is a suitable access token. A password that only you know, and send back with the desired action, provides the second item. This combination should be adequate for most transactions that might be completed in this fashion.

There is certainly a non-zero chance that a cell phone will be lost or stolen. This is an issue for one-way alerts as well as two-way alerts – what if sensitive information is to be transmitted in an alert? There are two ways to address this:

· Don’t do that. That is, if you are transmitting sensitive information, transmit it in such a way that it is meaningless to someone other than the intended recipient: truncate account numbers, don’t use customer names in full, use simple code words.

· Require authorization before sending the information. Send an alert that indicates that a sensitive alert is available. The recipient replies with another piece of information as authentication; only then is the sensitive alert released.

The voice portion of the phone can be put to good use here: instead of the user returning a password via SMS (which might be snatched out of the air and used in a replay attack), the alert message could contain a phone number to be called. The called system would then use voice identification (biometrics, above) to authenticate the caller, along with the caller ID information. To be truly paranoid, the caller would be requested to speak her password.

5.3. Unplanned access

Most of the alert examples listed above require that one visit a website, register, and set up the alert from the web page. This certainly brings a more powerful user interface paradigm to bear on the problem, but is not terribly convenient when one is on the go. Consider setting up an alert for an airplane flight – one must do so in advance, when near a computer, after navigating a website and typing in one’s phone number and other details. In some parts of the world, web access is not in every home; cell phones have higher penetration than personal computers. What are those customers to do?

Two-way communications can provide access to data, not just response to an alert directed to your phone. It is fairly straightforward to build an interface that accepts a simple SMS message, extracts some keywords, and returns data from a web page, database or corporate directory. The returned data needs to be tuned to the size of an SMS message, but one can be fairly expressive in 160 characters, if focused.

For sensitive data or expensive operations, a system might wish to have a whitelist of authorized users, based on their caller ID information. This would require a one-time signup at a website (or be based on a corporate directory that already contains that information). After this initial setup, all that is required is to send an appropriately worded SMS message to a known address to access the information.

For example, consider the above airline alert. Instead of visiting a web page, send an SMS message containing FLIGHT AA 1234 to a publicized “short code”. The computer system that extracts the message would inspect the caller ID information, possibly determine if you are authorized (though American Airlines would presumably want to provide this service to everyone, they might start by only providing it to members of their frequent flyer program), determine the status of the flight and return an SMS message with that information. A particularly clever application would try to determine if you’re interested in arrival or departure information, based on your location.

In addition, that system could register your phone for updates regarding this flight’s status, so that you don’t need to poll it for changes in the flight’s gate or arrival time; that registration would expire when the flight arrives.

Some airlines are might use the caller ID information to determine if you are authorized - though airlines would presumably want to provide this service to everyone, they might start by only providing it to members of their frequent flyer program. A few airlines have already linked their frequent flyer databases to their reservation systems, and automatically register alerts at reservation time.

As an extension to this, FLIGHT AA SFO JFK could return terse schedule information about flights today from San Francisco to New York – and could be further extended to book a reservation for frequent flyers who have registered their phone number, credit card and seating/meal preferences. This is probably at the very edge of usability for a simple cell phone.

5.4. Abbreviation

“Typing” SMS messages on a cell phone is tedious at best, even with the latest predictive input software. Systems that are based on SMS inputs should use abbreviation aggressively – allow users to abbreviate commands and keywords everywhere, sending only as many letters as are needed to be unambiguous.

This adds the requirement that the system must provide reasonable feedback about ambiguous abbreviations. If I send a message that is ambiguous, I should quickly get a response that tells me exactly what was ambiguous, and what the valid completions (but not all the choices) are.

For example, in a train schedule access system we have built, there are stations SanFrancisco, SanMateo, SanCarlos, SanAntonio. Abbreviations exist that drop the “an” from the first “word”, but not all users know this. It is not uncommon to get “San” as an input station, at which point we return the four possible completions, instead of the “obvious” message that would include all known stations.

It may also be valuable to use Soundex lookups to do keyword matching, in case your target audience is not made up of spelling perfectionists.

5.5. Customized behavior

There is typically a lot of computing power behind these systems. It is valuable to allow users to customize their experience. This doesn’t all need to be done from the phone – a web page can be used to specify the customization. A simple example is setting up short custom aliases for oft-repeated commands from the phone.

Another example is a simple application that watches a basket of stocks. Each user has their own definition of this portfolio, managed from the phone – the caller ID information is used to determine which set of stocks to get a quote about when a user sends PORTFOLIO.

5.6. History

History is a specialized form of customization. SMS-driven systems typically take messages that contain a verb followed by a number of keywords. In some cases (stock quotes, horoscopes, status applications that don’t have any alerting function), the user will want to poll for the same information many times. It is tedious to form the same message over and over again (some phones don’t provide a good mechanism for this, either). The back end system can do it easily, by keeping a table of the last arguments that each user supplied for every verb, and using those if a bare verb arrives.

5.7. Speed

Speed is always a desirable property of a computer system. Access applications that are based on SMS (and the communications networks that support them) need to be particularly fast to maintain the illusion of interactivity. If the system is fast enough that the user can maintain mental context, it is reasonable to build sets of hierarchical menus that can be navigated to provide very complex interactions with very simple messages.

By the same token, it is important to provide speedy error and help messages. If I don’t remember exactly how to do something but I know I have done it in the past, I need to be reminded of how to do so as quickly as possible.

These help messages are most likely going to be directed at “power users” – terse but complete. Novices will be better helped by extensive web pages.

5.8. Location-based information

The technology exists today (though not many carriers have deployed it) to triangulate the location of an individual telephone. In the US, the E911 requirements will make this more-or-less universal, either via triangulation or embedded GPS chips. Some carriers in EMEA have deployed these systems and are building applications on the resulting data:

· Send a message containing RESTAURANT ITALIAN (or Indian, or Japanese) and get information about the three closest (or post office, ATM, or coffee shop)

· Get driving directions from your current location to a specific address

· Keep track of a predefined buddy list and get an alert when one of your friends is within five blocks

· Set up a location-sensitive “to do” list that reminds you to pick up your cleaning when you are near by.

There are a number of privacy concerns in this area – many of them are addressed by requiring users to opt-in before their location information is revealed in any specific way. Retailers will certainly want to use this kind of system to send location-specific coupons (“drive in now and get 50% off a Venti Frapuccino”) but it might be a really bad idea.

Until carriers make this information available by triangulation, one can build applications that take your current location as input – with, say, the name of the cross streets at which you are standing, along with the town. This may require a fair amount of disambiguation and a generous mapping database.

6. Example applications

In this section, we present some more detailed examples that combine the above techniques, hopefully in Imaginative Expression.

6.1. WebMail might not be such a good idea

It is very popular at the moment to sell systems that allow users to access their email from a (typically browser based) phone. In the SMS world, this appears to be a horrible idea – 160 characters will barely allow you to see the From: and Subject: information, much less any meaningful portion of text. Attachments and rich media are right out.

That said, it can be useful to link some form of phone notification to one’s phone. For example, a rule that notices the arrival of urgent mail in your inbox and sends you an SMS with the sender’s name and phone number, so you can easily call her to find out the message is really urgent.

Summarization engines are appearing (see, for example, Mirador’s offering) that may make it possible to get terse but meaningful summaries of messages and even attachments in an SMS message.

It is unlikely, however, that today’s cell phones can substitute for a RIM pager.

6.2. Portfolio, including voice alert with transfer

We outlined a very simple portfolio status application above, to get the value of a basket of stocks. A more realistic one would be tied to an online brokerage site: an online customer visits the broker’s website and registers her phone and sets up a number of alerts – potential sales, limit orders, a watch list, news reports. These are fairly straightforward – but an interesting twist is to have an alert, either by voice or SMS, offer the option to transfer the user to a human broker (or, at least, the broker’s IVR system) that provides a richer set of interactions by phone.

6.3. Traffic alerts

It is possible today to subscribe to traffic alerts via wireless email/SMS; typically this involves registering at a website, describing the streets of interest and the time of day you travel those streets.

In the real world, people don’t commute at exactly the same time every day, they travel a different path to work than from work, they make trips to other places on a semi-regular basis and want to know about traffic conditions on those paths.

A more realistic system would allow a traveler to use a web page to define a number of trip profiles, and activate one via an SMS message: TRIP HOME, TRIP WORK, TRIP AIRPORT would get immediate status of the roads on the named trip profiles, as well as register for updates for a specified amount of time (specified by the traveler, presumably based on the expected travel time).

6.4. Phone info, to do lists, schedules

Most of today’s cell phones don’t have any mechanism for synchronizing an address book, even though they have extensive internal contact managers. With a little work, an SMS message can trigger a query of a contact list and return the name, phone number, email address, and whatever other information is stored there. An ambiguous query (PHONE JOHN) returns all possible matches. Most cell phones make it possible to call a number in an SMS message with a couple of clicks. This allows access to anyone in a particular directory, not just those that the user remembered to enter in the phone.

To do lists are similarly accessible in most online calendaring systems. A hierarchy of menus may be useful here: if TODO returns

1. Dry cleaning

2. Birthday card

3. Groceries

then TODO 3 would return the detailed grocery list, and TODO DONE 3 would delete the item from the to do list. TODO ADD OIL CHANGE would create a new item at the bottom of the list.

Schedules provide more opportunity for hierarchical data access. If SCHED TODAY returns

29 Dec 2001

a. 0730-1030 Joel

b. 1100-1200 Weekly Staff Meeting

c. 1230-1530 Vendor

d. 1600-1700 Project status

e. 2200-2230 Connectors

then SCHED B would return details of the meeting’s location and organizer, including email and phone number. It is important to format the returned information to provide a view of the entire day – at a high level, the busy/free information is likely the most important. The details can be discovered when drilling down.

The history feature would keep track of the date being used, to avoid the need to enter it with every command. SCHED NEW would create a new appointment, returning an updated schedule for the date. SCHED A INVITE CAK would invite the user named CAK to meeting A.

Such a scheduling system would also generate SMS alerts for any meetings that are marked to include a desktop reminder. Remember, “If you’re more than five feet from your desk, you’re mobile!”

6.5. Driving directions

There are several websites that provide detailed mapping and turn-by-turn directions between two addresses, but the formatting is only good for on-screen inspection. Printing the directions results in a page that is encircled by logos and banner ads, with the turn-by-turns nestled in the center of all this visual noise in a small font. If you don’t have a printer, you are reduced to copying out the directions, which may lead to notes that are difficult to interpret while underway, solo, at night.

In contrast, the cell phone has a backlit display that is designed to be readable in a wide variety of lighting conditions. This seems like an obvious match!

It is, unfortunately, not so easy. The first hurdle is entering the endpoints via SMS – the simplest we’ve come up with is something along the lines of DIR 130 EL CAMINO/94306/475 ALMA/94302 (that is, street address and ZIP code for both endpoints). This is less than ideal – how do you know the ZIP code of a random address? City boundaries are likewise not always obvious, and mapping databases are fairly exacting in their input requirements. Perhaps it is better to specify the addresses at the web site and have the turn-by-turns sent to the phone.

This reveals the next hurdle. A long driving path will have many directions – certainly more data than will fit in an SMS message. Fine, send each segment as its own SMS message! Indeed, this is very convenient – most phones have a quick navigation to “read next message”, so the driver is looking only at the direction that is currently applicable, and is not required to retain much mental context about “which step am I reading now?”

This usually works. But networks are unreliable in their ability to deliver SMS messages in strict order. The messages could be tagged with an indication of their intended order, but phones don’t typically allow sorting. Nor are they likely to have a “read previous message” that is as easily reached as “read next message”.

This may not be a good application after all, despite much apparent promise.

6.6. Salesperson in his car

This example takes a different approach – one where voice is king, SMS an adjunct, the combination more powerful than either. The system is built for a power user, someone that interacts with it every day.

When driving, it is distracting if not illegal to interact with a screen and keyboard. Consider a salesperson in his car, driving to work, interacting with a computer system that will support his day’s activities:

Salesperson: “Phone CRM”

Phone: dials

Computer: “Please say your password”

S: “Rosebud”

C combines caller ID information, voice analysis and password lookup

C: “Good morning, John. You have three appointments today; the first begins in 27 minutes. There’s a traffic jam on 101; would you like an alternate route?”

S: “No. What’s the contact?”

C: “Sam Spade, 891 Post Street, Number 401, 415 775 3274”

S: “SMS”

C: “OK, I’ve sent that information to your phone”

P: beeps – message arrives with contact information

S: “Status?”

C: “The last order was placed two weeks ago, and shipped yesterday.”

S: “bye”

C: “goodbye, John.”

Later in the day, John needs a copy of the customer’s latest order. Instead of calling up the IVR system, he sends an SMS message: ORDER LATEST FAX 408 555 1111. The system looks at his calendar, infers the name of the contact, digs out the order, and sends it to the indicated fax number.

7. Conclusion

The humble cell phone is a very capable, multi-modal device. It can connect humans to humans or humans to computer systems using a rich tapestry of techniques – many of which seem to be ignored by current systems in favor of mechanisms that are poor imitations of the Web. By starting fresh, designing applications for the cell phone with the cell phone in mind, a great many things can be accomplished that might otherwise be thought to require a different device and/or a continuous network connection.

8. History Page

Role	Name(s)
Author	Christopher Kantarjiev
Principal Reviewer:	Vito Salvaggio
Secondary Reviewer:
Proofreader:
Walkthrough #1
Walkthrough #2
Mgmt. Priority Approval
Inspection


Revision Date	Comments
15 January 2002	Version 1.0

Team Hard E-Mail E-Mail
Distribution List Member Copy Copy Notice

Wireless Applications for Today's Devices

Table of Contents