Mobilize, Don't Miniaturize

From MobileDesign

Too often, when companies decide to make a mobile version of their application, they take their desktop application or site, decide which features work for mobile, and then convert those features to a mobile language or two. Through this method we get flight times, stock prices, checking email, checking calendars, local weather, and several other useful but limited applications.

These applications do not fully meet user needs. To do anything in particular, the user has to visit several applications, one after the other, remembering data from application to application.

Contents 1 A Mobile Application? 2 Problems with Miniaturizing 3 Mobilizing Travel 4 Industry Status

[edit] A Mobile Application?

Consider a brief example: Jane has agreed to pick up Alex from the airport. Alex has emailed Jane flight information, and she has put it on her calendar. She is supposed to meet him at 5:21 pm later today, and it is about 45 minutes (normally) from her office to the airport. She puts the event on her calendar for 4:15, so she has some time to assess the situation before having to leave.

Jane is not at the office today, so she needs a few pieces of information: access to her calendar, flight information, and traffic conditions. Here is what she has to do at 4:15:

• Receive notification of her calendar entry (this assumes that the application makes this easy).
• Write down the airline, flight number, and time. Hopefully she has a pen and paper somewhere; if she has a PDA, she may simply remember the airline and highlight and copy the flight number.
• Go to the device or browser home page and launch the application or site for flight status. This may take some navigation.
• Navigate through the flight status information (usually several steps) and enter the airline and flight number.
• Determine whether the flight is currently on time.
• If the flight is not on time, figure out when to repeat steps 1-5.
• Go to the device or browser home page and launch the traffic application or site. This may take some navigation.
• Navigate through all the current incidents in the previously-saved city, determining the whether any of the incidents will affect travel time to the airport.
• Determine what time she has to leave, and leave at that time.

Of course, steps 2, 3, 4, 6, 7, and 8 are complex, and will take some of Jane's attention to complete. If she gets distracted by something, she may miss or forget something. If she were using a computer, she could look at more than one application at a time. But on a handheld device, she has to do one task at a time.

Now consider a different implementation, one that uses a task-based approach to application design. In this case, a content aggregator (perhaps the flight information provider) has decided that picking somebody up at the airport is something that happens a lot. When Jane agrees to pick up Alex, she pays the aggregator a nominal fee, perhaps US$1. She enters the flight information at this site, and may also enter it in her calendar.

In this case, this is what happens:

• The site monitors the current status of Alex's flight.
• If the flight is late, Jane is notified.
• The site monitors Jane's current location and expected time to get to the airport based on standard traffic conditions.
• Jane receives a notification when she needs to leave for the airport, and information about traffic conditions between her current location and the airport.

The application could notify Jane using either net alerts or SMS (short message service, or text messaging).

It's obvious which implementation is easier for the user. In one, Jane has to do a lot of work. In the other, the application almost serves as Jane's secretary.

[edit] Problems with Miniaturizing

Miniaturizing a web site or desktop application for mobile use treats the mobile environment and technology as a subset of the desktop environment. There's certainly an argument for this attitude: the mobile languages are mostly subsets of their desktop equivalents, the screens are smaller, the user input is more limited, and the connection speeds are slower.

Unfortunately, this attitude is what leads to the 9 gruesome steps Jane currently has to take to complete her task. It fails to consider many of the strengths of mobile:

• The mobile device is always with the user, and always on. A desktop computer is frequently not with the user, and a laptop computer is usually off and not connected.
• When the user is using a mobile device in lieu of the desktop, we know something about the user's context. If the application interacts with time-based data such as calendar or job schedule, we can infer that the user is either at the calendar event, or on the way. We can have as a primary focus delivering information targeted for that task. Example: a repair technician accesses the parts database while at Mr. Lee's house. Since Mr. Lee indicated a Whirlpool dishwasher, the parts database has a default view of only parts appropriate to that type of appliance. This speeds the technician's ordering task.
• Location-sensing devices give the application all sorts of context. Forget about mobile marketing (hey, I'm a usability expert, not a marketing expert); let's talk about trip planners, weather alerts, traffic warnings, and recommendations on where to go for lunch.
• Bluetooth makes the information on other devices potentially useful to the application. If I carry both a phone and a PDA (and I do, a personal preference), then I'd love to have my phone access the contact information on the PDA. But I could have any number of devices with all sorts of interesting data on them. Look for this to happen over the next few years.
• Push technology makes it easy for an application to communicate with the user, even when the user isn't paying attention.

All this technology is largely ignored when miniaturizing applications.

It's funny, in a way. WAP applications have a lot of useful content, and many of them are pretty easy to use. Usability tests prove this. So why do people think WAP applications are hard to use? Well, some of them are (usability tests also prove this). Many implementations (network plus browser plus device) make certain aspects hard or inconvenient. But mostly users can't find the information they need because they have to find the site that has it.

A colleague of mine using Sprint PCS Wireless Web decided that there was no people look-up information available because he didn't realize that InfoSpace meant "phone directory". Sprint PCS can't help this; they have to put the site name in the list.

[edit] Mobilizing Travel

Okay, so what is a mobilized application? A mobilized application is one that precisely targets mobile user needs, making best possible use of the technology. We should start with the user task, not with the company database. Information delivery should be made based on the user’s other tasks, such as driving. The design of the application logic should account for the user’s real-world tasks.

So let's consider a user situation that we know involves high amount of mobility and high information needs: travel. Let's limit it to business trips using air travel. Users need to schedule the trip, be informed of changes, schedule appointments with people and companies in the destination city, stay flexible enough to accommodate changes due to the vagaries of travel, navigate the destination city, find a place to eat, deal with emergencies like making extra copies, perhaps find entertainment, get to and from the airport, and find the hotel.

I'm proposing a multi-platform, multi-database travel assistant. Setup occurs when the travel plans are made, hopefully integrating with the user's calendar and travel planning service. Instead of selecting a departure, the user indicates when and where the first meeting is, and the system chooses a flight that will get the user to the client's facility on time. The return flight is handled similarly. Until the actual date of travel, communication with the user occurs via email. The night before travel, Alex receives a weather forecast for his destination city, as well as whether his hotel has a swimming pool.

Earlier I outlined some strategies for dealing with getting to the airport. The basic logic is the same, but the user needs to be at the airport an hour early, more if parking in a remote parking lot. While the user is in the lot, the application (sensing that Alex has arrived at the airport) prompts the user to type the parking location (e.g., h2).

As Alex navigates the airport, the application sends an SMS indicating gate and departure time. This information is available even when Alex is away from the monitors and will be updated as needed. Alex can now spend a relaxing time at the bookstore.

Upon arrival in the destination city, the application reminds the user where baggage claim is and where the taxi stand, rental agency, or bus stop is. Alex can request directions to his next destination.

While in the destination city, the application monitors Alex's location. When, based on current location, speed, and traffic conditions, it is impossible for Alex to be at a meeting on time, it displays a message indicating the problem, and the client's phone number.

At dinnertime, Alex can find nearby restaurants. The application may prompt Alex to enter the amount paid for dinner for expense report purposes.

The application can inform Alex when it is time to go to the airport to go home. This is especially important when traveling, because most travelers do not have the intimate understanding of a destination city's traffic patterns that a native does. And when Alex lands back home, he sees his parking location on his mobile device.

[edit] Industry Status

This has certainly changed since I first wrote this article. I deleted the original.