Little Springs Design. 2001 – 2010.

Even if you disagree with my definition of smart phones as those with named operating systems, I hope you agree that a named operating system is a frequent characteristic of a smart phone. Symbian, Palm, Windows Mobile, Linux, and RIM are the big players.

I see smart phone purchasers as having one of two goals:

• "I want all the features"
• "I want to do a specific cluster of tasks and also do PDA stuff"

Michael Mace has looked at that second set, noting that it is divided into three groups: communications, entertainment, and information. He has a very nice visual map of the space, including the Zone of Death -- devices that try to do everything.

Mace hasn't talked about the first set. These are the people who are upset when their new fancy US$700 device doesn't support streaming video/Java/whatever. It might seem that these folks want, precisely, the Zone of Death devices, they don't. Folks have different notions of the definition of "everything", and carriers and device manufacturers need to better understand that. A solo practitioner dentist who uses his phone for scheduling told me he wants video content on the latest Treo, that he paid top dollar and wanted all the features. A fencing master told me he wants a good Java environment on his Treo, for a broader array of applications. In fact, all of the Treo owners I've talked to (except those in the industry) expect their devices to do everything. Interestingly, the same is not true for the Blackberry owners I've talked with.

So what is a smart phone maker to do? How does Palm, Microsoft, or Symbian differentiate from the Sony Ericsson Z750?

Currently, the key differentiator is the presence of the operating system. This enables for the user:

• downloadable applications
• integration and consistency: native and third party applications look and feel like they belong, and have major capabilities
• knowledge that applications and user interface will continue to work on a future device

Is the operating system really sufficient to differentiate for the user? Not if Samsung or Motorola were to put together a superb user experience on the device. Java ME, despite its myriad problems, is attacking all three of the above differentiators. Counting on one's competitors to avoid improving user experience when that is a major topic in mobile does not sound like a profitable idea. Were I in charge of developing a mobile operating system right now, whether it be Linux, Windows Mobile, Symbian, Palm, or Blackberry, I would:

1. Embrace Java, and regularize it.
   • Expose device APIs to the Java environment.
   • Ensure that Java ME applications designed for lesser devices ran acceptably on my device (especially dealing with softkeys)
   • Create a standard Java environment such that an application that runs on one of my devices runs on all of them, unless the application requires hardware that is not present (like Nokia)
   • Allow Java applications to take over the standby screen (with access to the built-in standby screen)
2. Integrate better
   • All applications should have access to most user data, especially PIM (contact, calendar, etc.), messaging, and multimedia
   • Focus on data, not applications
   • Improve reliability of the OS ... reduce crashes and oddities
3. Provide functional and visual customization
   • Widgetize the standby screen, with open access, providing views and controls on user data and online data ... push key UI elements onto the standby screen
   • Allow a "standard mode"
   • Provide the ability to hide or even remove built-in applications (critical APIs would have to remain)
   • Provide a customer support mode, allowing a remote user to have the device do key tasks
4. Bonus: track frequency of use of different data types and application types to feed into an application suggestion engine upon user demand

There would be lots of design work to make the above actually function well, particularly with managing customization. That is, however, a manageable task.

After I started writing this, I learned that Blackberry is exposing some of its deeper APIs. This enables third party developers to do almost anything that RIM can do on the device short of core device security tasks. Third party media players, access to the microphone, web access, and PIM access. RIM now has access to the entire Java community of developers to create native-level applications for its devices.

This entry was posted on Monday, April 2nd, 2007 at 11:12 am and is filed under Business, Design, Devices. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.