Recent Blog Posts

Lately I've started using Life Balance, a sophisticated task list that helps users understand where their time is going and keeps different aspects of their life in balance. It is available in Palm, Windows, and Mac versions, and the mobile version will synchronize with the desktop version.

There are lots of reasons why this software is becoming an intimate part of my life, largely surrounding the concepts of nested task items, prioritization, fuzzy task duration, and tasks that may be without due date, recurring every so often, or due at a specific date and time. However, this is a blog about mobile technology, so I won't wax poetic too much on the feature list.

What is amazing from the mobile front is that I am currently using a PDA (a Palm LifeDrive) - one without a phone in it - and I still find myself going to my PDA all the time. For me, it's a killer app. I imagine that others would find an excellent music player to be a killer app, but that's not me.

I look at my PDA maybe 50 times a day. This usage has spilled into other places - once I've picked up my PDA to look at Life Balance, I am likely to use one of the other applications on it. Because I'm going to be carrying the thing around, I bothered to load my daughter's pictures on it. I even loaded a toddler game on it for emergency entertainment. Now my daughter wants to look at my PDA when she sees me pick it up.

Perhaps carriers should take note: if you make the phone indispensible for a product or service that is not your money-maker, your other services will get a boost in use.

I'm in a meeting. My phone rings. I shut it up (volume button, end key) and put it away. 30 seconds later, it rings again, announcing voicemail. I'm embarassed twice.

So, a feature request: If I've dismissed a ringer, do not ring my voicemail. Switch to vibrate only. Do this for one call only. Only embarass me once.

Mobile user experience goes far beyond just how the application looks on the phone, even more than the "desktop" web user experience goes beyond what the user sees in the browser.

For every new phone feature, including cameras, mobile TV, video phones, downloadable applications, and ringtones, four pieces need to be developed:

1. how the new technology will behave on the phone (e.g., browser features, accessing the camera, the TV player),
2. how the device talks to the network,
3. how to develop content for the new technology, and
4. content for the new technology.

Carriers focus on the network, and hopefully several people focus on how the technology behaves on the phone. In the case of J2ME, Sun is the primary party focusing on how applications run, and carriers or device manufacturers focus on how to manage and launch applications. Third party developers can take more responsibility for device behavior by using the Canvas element rather than pre-built lists and forms, but at a cost of not knowing how the application will run on other devices.

When a new technology is deployed, frequently designers and developers use old practices for the new technology. For example, most people assumed that mobile television would be the same as regular television, only smaller. It's not. Not only can you not see the baseball flying through the air, you probably can't even see the outfielder trying to make the catch. These issues in content production for mobile multimedia are outlined in our mobile multimedia style guide.

However, the issues go beyond mere technology straight to user behavior. Few users will sit down and watch a 30 minute show on their mobile phone - they are too interruptible, it's too annoying, and they usually have other things to do. Fortunately, many Hollywood producers understand this - as do mobile advertisers - and much shorter content is being produced. In general, Hollywood understands user perceptions of their content, and adjust accordingly. Too bad other types of content developers don't do as well.

Little Springs Design has worked on projects defining how a new technology appears on the phone, core technology issues and how the device interacts with the network, how a particular application (content) works. These are all important. What we do better than anybody else is determine the rules for how to develop for a new technology.

When I talk about mobile users' needs being different, what are the implications? Let's consider a fairly simple example: a corporate expense reporting application.

The typical use at a desktop is to assemble an expense report from receipts and perhaps automatic items, such as travel expenses. The user creates and names an expense report, adds and categorizes expense items, and submits the expense report. The main page ought to have a list of open (unsubmitted) expense reports, a button to create a new report (or even a form right on that page), and a list or access to a list of submitted expense reports (most recent first).

The typical use from a mobile device is to enter whatever expense is currently being incurred. Other use will be a distant second. Thus the main page should be a form to enter a single expense, as easily as possible.

The user need not enter the name of the business, just the category picked from a list (the name can be added later at the desktop). The expense can be assigned to an existing expense report, or no report, or a new report (user will have to enter at least the name of the report on a subsequent screen).

At the bottom of the form is a button labeled "Save", which will take the user back to the same page with a success message at the top of the screen. The expense is saved either to a report or to the "automatic items" mentioned above.

Because a small percentage of uses will be for some part of the main site's functionality, this is provided via a link on the page.

Bonus feature for mobile: based on the user's location and the expense category, provide a list of possible businesses to be receiving the expense.

This design, based on the users' needs in different contexts, can not be achieved by simply indicating which parts of a page should be published to a mobile.