Recent Blog Posts

What do you lose?

What do you lose when you try to make your mobile web site the same as your desktop web site? Lots.

Let's assume that you apply as much diligence as possible in designing your site. You consider that the mobile site will have slightly different needs than the "regular" web site. You use a tool like Oracle's Application Server Wireless or MobileAware. You know that your mobile users will not have a keyboard, so you design your navigation and search to minimize the need for text entry.

The problem lies with the core assumption that the mobile web site is a subset of the desktop web site. It oughtn't be if you are really targeting your mobile users. This assumption is pervasive in the internet world - after all, technologies such as Javascript and Flash lag in the mobile space.

In some key ways, desktop capabilities are a subset of mobile capabilities. Consider the following features that are completely or partially lost when designing a desktop site:

Mobile FeatureUseDesktop EquivalentExample
SMSUsed when the users identification needs to be confirmed or when the user needs persistent information on the deviceEmail (not appropriate for many mobile devices)Sites that send URLs to phones so the user does not need to type; sites that send turn-by-turn directions to the phone, applications that are implemented with text alone
LocationHighly localized informationIP address (gives partial and inaccurate approximation)Tracking my child's whereabouts
Voice channelSwitch to voice browsing or voice input when usefulnone reliableName that tune (Shazam) (SMS application)
Usually presentCommunicate with the user at any time, as the device is usually on and with the userCertain market segments are at their computers almost full-timeAlerts (traffic, weather, stock, soccer practice cancelled)
CameraUse visual input and server-based image recognition (or just post pictures)Uploading pictures from a separate cameraPaperclick takes a picture of a barcode and routes to an appropriate web page

Tags: DesignMobile web, Permalink | Comments (0) July 25, 2005

The Dangers of Being a Pipe

Internet Service Providers (ISPs) discovered several years ago that users largely wanted access to the Internet, and didn't care about how they got there. AOL has been the primary exception to this rule, and their claim to fame surrounds user experience. Mobile operators should be learning from this example, but don't appear to be.

Recently, NTT DoCoMo's CEO Masao Nakamura gave an interview discussing their stagnant growth, and identified a key driver for growth: data. That's good as far as it goes, but he believes that the key driver to data growth is video conferencing and streaming.

This is what I call "pipe thinking". Get more stuff going through the pipe, and we'll get more revenues.

Users don't pay for bandwidth. Users pay for things they value.

Will users pay for mobile television when they have Tivo at home? Some will, but most won't. Why bother paying for something you get for free? Live sports and news are obvious exceptions; these, of course, are available at bars, restaurants, airports, and myriad other locations. It's tough to avoid sports and news. So perhaps only the most avid will pay for phone presentation for media content.

Okay, videoconferencing. Mr. Nakamura understands that businesspeople are not using their phones for videoconferencing, which matches with my multi-national experience. But he's trying to increase videoconferencing by making more phones have video capabilities; NTT has even invested in the development of a bi-directional video codec intended for cross-device videoconferencing. While the design of their videoconferencing system is slick, I've yet to use videoconferencing for any business reason whatsoever, even when working with teams scattered across 3 continents.

Instead, users may pay to send a videoclip of their child to their parents. They may pay for a lot of things.

NTT DoCoMo has been the poster child for such services. We now find out from Mr. Nakamura's interview that only 20% of DoCoMo subscribers use the much-vaunted iMode service for anything more complex than messaging. While iMode's penetration is far higher than WAP penetration, please keep in mind that iMode includes SMS and email, whereas SMS is separate from WAP. Thus you can compare iMode's 20% of 60% of Japan mobile users (that's 12% for those of you keeping score) to WAP's roughly 15% of UK and 12% of US. DoCoMo does not have much of an edge, if any.

I'm picking on DoCoMo here not due to the Japanese company, but due to American and European carriers' spending a great deal of money and executive time attempting to learn what the Japanese are doing right. Apparently one major thing they did right was define their terms correctly. The US and European carriers then made their own mistakes.

I'm calling on all carriers to get out of pipe thinking, or at least to get heavily into the business of supporting MVNOs - that is, being an actual pipe. Give users what they want, not what will run up your volumes. You'll find that you can make more money that way.

Tags: BusinessCarriers, Permalink | Comments (0) July 18, 2005

MVNO experience

MVNOs (Mobile Virtual Network Operators) are sprouting like flies recently. Virgin Mobile's MVNO is doing well for both Virgin and Sprint, and is targeted at teenagers and young adults. ESPN announced plans quite a while ago for their own MVNO; parent company Disney announced they were doing the same this month. Amp'd Mobile is starting without a brand but is closely targeting teenaged males, putting themselves in competition with Virgin Mobile.

What I find fascinating about all of these MVNOs is that it is currently possible to have completely distinctive user experiences with the same network. To the user, the network is become more and more just a pipe, unless you happen to have a dead spot in your house for a specific network. Upcoming technologies such as Qualcomm's UI One (as detailed in operator-defined user interfaces) will allow segment targeting to go beyond faceplates, ringtones, games, and advertising.

If you compare Virgin Mobile against Sprint, for example, more than just the advertising distinguishes the two companies. Virgin specifies its own handsets, has a completely different "off the rack" phone distribution model (you have to talk to a saleperson to purchase a Sprint phone), has use plans tending towards pre-paid, and has different advertising and content.

I'd expect an ESPN, Disney, or Amp'd MVNO to go even further. Each of them, I imagine, will select not just different devices but go with the option for a personalized user interface.

Obviously ESPN users would have the option of downloading a UI (front screen, pre-loaded games or applications, menu reorgnization, ring tones, front-screen text content, wallpaper, etc.) focusing on a specific sports figure or team. A Tiger Woods UI would have a picture of Tiger completing a swing, latest Tiger news, PGA standings, hole-by-hole coverage for any ongoing tournament, a Java golf game, and perhaps even a golf sound effects ringer option. All of this would be available both on a ruggedized sports-phone, as well as on a high tech (looking) phone.

Disney has a slightly more difficult proposition, as they have to target (with different UIs and phones) both kids and parents. They've done a fabulous job at that with their Disney vacations, so they may bring that sort of experience over to the mobile space. Parents' phones would have the ability to track their kids' locations and to track and control their kids' usage. Of course Disney would offer family plans with free Disney-to-Disney calling. Kids phones would likely have a more typical Disney appearance, with favorite characters.

ESPN might add a service to provide live sports coverage via video, a service that could be greatly enhanced by some special camera-work and video enhancement. Disney might add a family calendar, so that everybody in the family knows when Ashley is going to soccer practice and who is going to pick her up. These applications are not yet designed and not of particular interest to more traditional operators, so they are an opportunity for the MVNO to excel.

In many ways, Amp'd has an easier time, without a specific brand to extend to the mobile. They can lure their target market (teenage males) with any sort of game, any sort of sport, and any sort of image that appeals to them. Amp'd can readily serve the kid who likes games and anime as well as the kid who likes sports and cars. They can create a cafeteria-style build-your-own UI -- as long as the kids can get their parents' approval.

Sun’s major failures with J2ME

Sometimes I wonder whether Sun is serious about supporting J2ME MIDP, as they have made the mistakes that they must have learned from when first releasing Java 1.

Most recently, I learned that many device manufacturers are unaware of user interface issues when implementing a KVM (kilobyte virtual machine, the runtime environment on the phone). These issues are clearly outlined in Sun's MIDP 2.0 Style Guide, so it's not a mystery. (shameless plug: but if you want to design MIDlets, my book, User Interface Guidelines for MIDP 2.0 is better)

Sun has done an atrocious job of communicating these requirements to device manufacturers and KVM implementers, as evidenced both by the lack of awareness I found with my projects as well as the poor implementation in certain situations. The result: J2ME MIDlets are harder to use than necessary, reflecting poorly on Java.

Second, and more pervasive, is Sun's decision to provide an incomplete reference implementation. Their implementation was not in any way optimized (particularly for speed), but they provided it and then said that implementers should not use it. Of course, KVM implementers used it as a shortcut to writing their environments and only added a feature or two. The result: first and second generation J2ME devices, and all applications that run on them, are unbearably slow. A small application might take 45 seconds to launch.

What should Sun have done differently?

First, manage their licensees better. Ensure that implementation guidelines are placed in the hands of people doing implementation (not, as it is now, in the hands of carriers who then purchase devices who then purchase KVMs).

Second, either provide no reference implementation, or a fully optimized (without hardware) and tested reference implementation. They could even charge KVM implementers extra for the right to use the reference implementation, thereby offsetting the cost of the extra development effort. Further, the effort to implement the myriad JSRs (candidate feature addtions to J2ME) into the reference implementation would have slowed down the adoption of JSRs while increasing the consistency across devices, thereby making developers more able to write applications that can run across devices.

After all, that's what Java promises: cross-device compatibility. Let's see Sun be more serious about making it happen.

Tags: BusinessDesignJava ME, Permalink | Comments (0) July 13, 2005

Product Concept: Truly integrated contact management

Road warriors could be better served by their mobile devices, even if the focus these days is on music, cameras, and youth.

Think about users of Goldmine, Act!, and similar software, even Outlook. These people are spending a lot of time on their mobile phones, and a lot of time away from the office. They're either using a separate PDA, or an integrated phone/PDA (I've seen both).

The experience: Road Warrior ends a call. His phone allows him to record a quick voice or text memo about the conversation. The date, time, duration, type of call (in, out, missed), pointer to the contact, phone number, type of number (office, mobile, ...), and any memo is saved. The next time Road Warrior syncs to his computer, this data all gets populated into contact manager of his choice.

The benefit to Road Warrior: Effortless contact management, including voice notes, integrated with existing high-powered software. Less time recording notes and more time available to do business - or even relax. A call record available where it matters most.

The benefit to an operator who can create this application as a web application: stickiness for your highest-volume users.

The benefit to a device manufacturer or OS manufacturer who creates this: additional loyalty to your OS.

Caveat: you'd have to have access to the OS to develop this program. You'd therefore need to be in BREW, Palm (with full understanding of how the phone app works, which varies from device to device), RIM, Mobile Windows, Symbian, or something like Qualcomm/Trigenix's UIone.