Recent Blog Posts

Retailers such as carriers, Motricity, and Handango are fairly good at selling ring tones, wallpaper, and similar content. They are not as good at selling applications.

One key difference between the categories of content is the ability to sample the content before purchase. Many stores allow a ring tone sample, a wallpaper preview, or even an MP3 sample. Each also has a description and other meta data. The application has as much information as the wallpaper: a splash screen preview and a brief description.

Purchasing applications is different from purchasing wallpaper. The customer has to figure out whether the application is easy to use, has the desired features, and will fit into her life. When she is faced with a splash screen and a 12 word description, she can not make these assessments.

So she decides not to purchase anything.

Downloaded applications enable incredible functionality on phones, allowing users to play games, keep up with news, check their favorite email, upgrade their browser, and so forth. But the architecture embedded in most mobile retail stores presents a barrier to obtaining applications. Put another way, the very structure that is supposed to promote sales is, I believe, inhibiting them.

So here is a call to all application sellers: give users better information to make their decisions. Learn from the desktop shareware industry. Learn from the folks giving their applications away for free, such as Opera and Google. Learn from folks selling complex products online, such as Zappos and Amazon.

Specific ideas:

• Allow free trials. Let users try out the application.
• Create a user community to review applications (don't forget to account for device types).
• Build a recommendation engine for applications. Users can see what their friends are using or specifically push an application to their friends.
• Provide screen shots of key screens.
• Create an easy and easy to find return process. Barriers to refunds are barriers to purchase.

I've looked at a number of stores, but certainly not all of them. And I can't really get excited about most applications using them ... and I'm an application junkie.

Maybe they were trying to move forward into the 21st century. Or maybe they were trying to reduce costs. Or maybe they were trying to improve customer experience.

If so, they failed.

It looks more like they were trying to place hurdles in front of people trying to use their rebate. Which, of course, is typical. It's just that normally the hurdles are done after you fill out the form and mail it in. Not this time.

When they sent a debit card with my rebate funds on it, I was happy. One less step to using the money! Terrific!

Wrong.

Specific issues with the cards:

• Not all places that take debit cards can take these cards. Any low-end device that doesn't have an explicit debit/credit user interface path rejects the transaction.
• Any transaction for more than the amount remaining on the card will also be rejected, and there is no way to tell how much would be valid.
• To find out how much money is left on the card, you must either call a phone number or go to the web site. The web site is poorly designed, and requires the user to remember a 4 digit PIN that was not created by the user. Nor was there any indication that the PIN would be necessary in the future when the user first activated the card. Hint: the PIN is the last 4 digits of your phone number. Not that the web site bothers telling you that before your number of entry attempts expires.
• You can't use the card to get cash at an ATM.

If you get one of these cards, go immediately to the grocery store and use it for a purchase equal to or greater than the amount on your card. Don't carry it in your wallet. Don't try to use it at a restaurant. And don't try to use it for multiple purchases.

What I really wanted was ATM access. That would have been fabulous.

Tags: Business,  Carriers, Permalink | Comment (1) April 24, 2007

My recent discussions of smart phone evolution and defining smart versus feature phones have left an obvious question: what should feature phone manufacturers do to compete?

To be clear, I am talking about devices with voice, text, web, and application (Java ME, BREW, etc.) capability. These devices typically have a user interface unique to a single manufacturer, a third party web browser, and a Java environment. The devices are subject to the desires of the more assertive carriers (including DoCoMo, Sprint, Verizon, Telus Mobility, and Virgin Mobile), though some device manufacturers resist.

Alas, the carriers' requirements frequently are inconsistent with how the balance of the device is designed. Consider the Motorola RAZR. The unlocked GSM version is actually quite nice, and enjoyable to use. It certainly has a number of problems, but it is middle of the road in terms of how it works. The Verizon version is profoundly broken. Verizon had shifted the UI and had no way to simply launch the browser except by using the left arrow on the rocker. Cingular's design is better, but quite muddled in terms of architecture. Oh, and one device has a "center soft key"; the other doesn't and users have to instead know to use the select button to pop up a menu.

On device applications (browsers, Java environment, media players, and sometimes others) are designed and developed by independent vendors. There is little consistency in user interface, and no integration of data. It is as if the user had simply acquired software for a naked device. In many ways, that would be better because then the user could understand what is the native device and what is layered on top.

On the other hand, feature phone manufacturers have some key strengths. Nobody is expecting a feature phone to do everything new that comes along, so it can focus on a smaller number of tasks. Further, the lower price makes for higher volumes and hence economies of scale ... if the manufacturer can avoid major customization costs.

The existence of platforms like Java, BREW, and Flash Lite provide the feature phone the opportunity to compete with smart phones without the extra expense. Sure, application launching may be a little more awkward and features may be missing, but that special application could still be downloaded. Lower end processors are not that much less capable than smart phone processors, particularly when the device needs streaming video capabilities.

If I were running a "feature phone" product line, I would:

• Regularlize software across devices, particularly with regards to user experience (more like Nokia, less like Samsung)
• Take control of the user interface. Ensure that vendor applications are consistent with the native user interface; this is particularly a problem for Java.
• Accelerate launch times for Java, BREW, and other applications. Ensure that the application environments are optimized, not simply functional.
• Create an abstraction layer for softkey management so complying with carrier requirements is simplified.
• Expose the API. Allow Java and BREW applications access to device data and hardware such as the camera, the music lists, and the calendar.
• Keep the voice emphasis. If the user wants a device with web focus, she'll probably be getting a smart phone anyhow. Thus make voice calls and messaging easy to do.
• Create different software loads for the same hardware, based on user needs. This software load might be more information focused; that one might be more music focused. Consider modularizing so that users can download desired features ... perhaps for additional cost.

What is mobile commerce? My definition is:
commerce-related activities using or aided by your mobile phone

This suggests segmenting the mobile commerce space by commerce task: research/compare, purchase, delivery/pickup. These commerce tasks can be done using the mobile, using traditional physical processes, or using the desktop. In the table below, we ignore the desktop as it is a relatively small subset of the capabilities of the mobile (as long as the web site works on a mobile).

	Physical	Mobile
Research & compare	Go to different stores Look at shelves Ask sales person	Physical options and ... Voice or web search for related products/prices Web search for product specifications Image recognition of products "in the wild" 2-d codes such as Kaywa Reader QR codes or Shot Codes
Purchase	Cash Credit & debit cards	Proximity payment (credit or debit) Paypal Mobile Obopay Suica, etc.
Delivery & pickup	At point of purchase Fill out form for shipping	Physical options plus ... Tickets & reservations to phone Digital content to phone Digital content to email Schedule or alert for pickup

So a given transaction can have a mix of physical and mobile components.

The banks also talk about mobile commerce in the form of account management. While this to me appears to be a web service, it is financially related. Again, there are obvious physical and mobile options for account management ... and lots of companies creating mobile applications to support banks who want a mobile presence.

I've seen too many people talk about just one piece of the above table as "mobile commerce". Back in 2000 (at least in the US) the entire transaction had to be mobile to qualify as mobile commerce, in no small part because the integration with the physical world was non-existent. Amazon.com and Barnes & Noble let you browse content, add it to the cart, purchase it, and have it shipped to your house all on the mobile phone. Nice, but of course the experience was lacking (particularly due to data speed and somewhat due to screen size).

These days, using the mobile phone as a payment instrument is a popular space. Visa and Mastercard are in the picture; technologies include RFID or near-field communication chips to allow the device to talk directly to a reader. The big shortcoming with this solution is the lack of integration between the phone and the chip. The phone really just has a chip attached to the case. This is important for folks who might want to use more than one card; expect competition for residence on the chip to be fierce.

Several providers allow delivery of content directly to the phone. Ringtones should of course be delivered directly to phones; music purchased on the phone should be shipped directly to the phone unless the user specifies otherwise. Note that you could make a physical or desktop purchase and have the content delivered to your phone.

While purchase and delivery are key, I think that the research process provides the most opportunities for entrepreneurs.

• Location-based: Where can I find the cheapest gas nearby? Where can I find the cheapest ATM? What hotels are available within one hour's drive from here ... while I head north on this highway?
• Comparison-based: How do the specifications of this camera compare with that camera? Can I find the camera cheaper nearby?
• Environment-based: Where can I get that scarf? What more information is available for the product on that billboard? Can I get a discount at this restaurant? What reviews are available for this album?

I watched Engadget’s video of the Prada phone with great interest, especially with the compliments about the user interface. The user interface is built in Flash, and operable with a finger.

The UI is as beautiful as you would expect with Prada branding. There are some niceties, like the ability to move the clock on the standby screen just by dragging it. Changing the clock’s time has a fun UI. Of course the entire UI is skinnable. When you enter a screen, a subtle animation of title and sometimes icons adds visual appeal and a feeling of quality. All very nice, all reinforcing the emotional experience.

It looks like these niceties are the extent of the focus on details necessary for a good user experience. The phone menu system matches that of almost any scroll-and-select device such as Nokia Series 40 and Motorola RAZR, even where it doesn’t make sense. They don’t make use of their nice touch screen, and rely basically on softkeys. Even the music player does not have all of the controls touch-enabled.

Where they had to develop something new, they did fairly well. The camera user interface looks likely to be good, though I haven’t used it. It projects translucent buttons on top of the viewfinder.

I suspect that as people use the device over a long period of time, they will become less and less enamored with it based on the little sources of friction included in the UI.

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.