Recent Blog Posts

Since I’ve introduced the concept of The Carry Principle, I’ve had a variety of feedback. I’d like to take the opportunity to address some of them.

First, the Carry Principle asserts that your personal communications device is the one device you won’t leave home without. As a result, it tends to evolve to include other functions, such as cameras, alarm clocks, music players, and so forth.

A PDA is an information appliance. Not so, at least with current definitions of PDA. An information appliance is a device that focuses on handling a particular type of information and related tasks. PDAs no longer focus on any particular type of information. Mine, for example, does address book, calendar, email, photos, music, books, pdfs, videos. It’s not that the definition of information appliance has changed, but that the term PDA no longer means “personal digital assistant” but “handheld computer”.

The Carry Principle appears to ignore wearable computing. Not so.. The Carry Principle does not preclude wearing other technology, or even the “carried” device. Wearable technology includes those integrated with clothing (Nike/iPod shoes) and those affixed directly to the body (a watch). Some of these will be single-purpose information appliances, but others will be more generic. If somebody makes a wearable personal communications device, its characteristics will be described by the Carry Principle. The chief difference is that the size will be limited by body dimensions rather than pocket/purse dimensions.

Device classification won’t matter when all applications are web-based. It depends on the evolution of the web. If all web sites are fluidly designed and ignore capabilities of the devices upon which they are displayed, then yes. More likely, I think, is that web sites will demand to use more and more of the devices’ features to enhance the sites. In this case, classification remains important.

Whenever a potential client comes to me and refers to “smart phones”, I make a point of it to ask about their definition of smart phones. The answers are variable, and many people don’t really have a good answer.

That’s a reasonable state of affairs since the industry as a whole doesn’t have a good definition. I just saw a piece of research that referred to “smart phones” as “phones with QWERTY keyboards”. This rules out the Blackberry Pearl and the iPhone, but includes the Danger Sidekick and the Kyocera Strobe. Does this make sense?

Earlier definitions of “smart phone” have included “phone that can download applications”, “MS Windows phone”, “phone with a web browser”, and “phone with a calendar” (2006, 2003, 2000, and 1998 respectively). The industry doesn’t know what it means.

If tracking phone sales, be sure you understand the definition.

Equally silly is the distinction between a smart phone and a PDA. The PDA is a smart phone without voice connectivity. I wonder whether PDA sales will “spike” when we have VoIP phones with Wi-Fi only. A piece of software could turn a “PDA” into a “smart phone”.

And then there’s the term “feature phone”. Do smart phones not have features? I prefer the term “mass market phone”. Sure it’s more awkward, but it makes more sense.

From a business perspective, we care because smart phones are known to have better data revenues. Being able to correlate precise device features with data revenues would be extremely useful. Alas, I don’t work with a carrier or an expensive research institution so I’ll have to hypothesize instead.

I define a smart phone as a handheld communications device with a named operating system, with the understanding that communications includes voice and named operating systems are those that an end user would recognize and perhaps use in the purchase decision: Palm, Symbian, UIQ, Windows Mobile, and Linux.

Alternately, a smart phone could be a communications device with approximately 50% of the capabilities of a laptop computer.

These definitions are far more stable than the feature-based definitions above. They robustly allow the iPhone to be categorized correctly without shifting the definition.

From a user perspective, a smart phone offers a degree of hardware independence, an ecosystem of third party applications (iPhone won’t …), and an integrated user experience. The device is presumed to do everything, and users paying lots of money for a high end device get angry when it doesn’t.

In contrast, a mass market phone offers size and price advantages, hardware loyalty, and no presumption that the device does everything.

Yes, Virginia, there is a mobile web.

Sometimes all a site needs is to be accessible via mobile devices. Maybe you want to do that with a handheld style sheet, or maybe you can just rely on the various browsers and gateways to do the job for you. I am currently working on a site and taking this approach based on the business requirements, user needs, and site functionality.

But sometimes, the site needs to incorporate the mobile context. Perhaps the site information needs to be reorganized into a different page layout. Or perhaps the site needs to exploit mobile capabilities.

Carriers, device manufacturers, and browser providers need to do more to support this. Specifically, scripting in the browser needs to have direct access to camera operation, on-device images, location, advanced text input methods, and the microphone.

This increased functionality could be accessed by way of extending the Browser Object Model (BOM). The BOM is the mechanism that Javascript and ECMAscript (and I assume other methods) use to control the browser and access information about it. Imagine a method in the BOM that got the current location and an object in the BOM that was the image library. A method in the BOM could get one image from the camera (activating the camera, allowing the user to take a picture) and another method could allow the user to choose between taking a picture or using one on the device.

Web developers are well-accustomed to “graceful degradation”, ensuring that if a function is not present the web page still functions acceptably.

Extending the BOM would also help in the desktop world as well. It could provide access to the microphone so a user could talk directly to a server.

Browsers have to do a bit more than providing access to these systems; they must also provide user controls. After all, a web page that captures voice, location, and surrounding images without telling the user would be a terrible safety hazard for the user, as well as providing a major cost in battery life and connection charges.

Browsers built in Java ME (are you listening, Opera?) have an advantage: many Java environments already provide access to some of these device capabilities using standard interfaces.

I started working on location-based services back in 1999. We identified different categories of location services, serving different user needs. It isn't all about driving directions and local search, nor is it all about high precision data. Useful services can be provide with a number of technologies, though GPS variants are mighty useful.

Back when I started, I railed against the pricing models, but agreed with the concerns about privacy. I certainly agreed that getting 911 calls located (meeting government mandate) was the top priority, but there were so many business opportunities.

Among other ideas, we identified:

• maps, directions
• traffic monitoring & dynamic re-routing
• very local weather
• "fencing" (providing an area outside of which the tracked phone should not venture)
• tracking (useful for many businesses)
• friend finding
• local search

The problems surrounded privacy and cost. Paying for each fetch of location data quickly makes any tracking application infeasible. Privacy is somewhat illusory; in the past few years we've had a number of reports of government agencies tracking traffic speed via mobile phone signal, using the mobile to spy on an individual, and lives saved because somebody and the operator could track an individual.

So the carriers left all the potential revenues from the above services on the table. Some operators steadfastly avoided implementing location services as much as possible, lobbying the government to delay requirements.

Sprint, however, has started building their LBS service offering, and now have a compelling mix. Most recently, they announced dynamic directions and maps, with local search built in. The screen shots from the service look very nice, and the pricing works for folks who only occasionally need help with directions: $2.99 for 24 hours use. If that helps me navigate on a vacation and get the most out of it, I will definitely pay that money. This comes on top of other services such as the apartment finder ($2.99/month) and Family Locator.

What is especially telling about the state of LBS in the US is found on the support devices portion of TeleNav's web site. Take a look at each of the top 4 carrier's supported devices:

• Cingular: 27 devices, only the Motorolas are mass-market phones, 22 of the devices need an external GPS receiver
• Verizon: 4 devices, all smart phones (i.e., a named operating system like Symbian, Palm, Windows Mobile), all requiring a external GPS receiver
• T-Mobile: 1 Blackberry requiring an external receiver
• Sprint: 26 devices, a healthy mix of mass-market and smart phones, only 4 of which require external receivers

The Sprint numbers don't include Nextel phones, all of which are made by Motorola and all of which have built-in location.

Based on this mix, it looks like TeleNav is using, among other technologies, Java ME MIDP2 (else it wouldn't work on my Sanyo MM7500). It also looks like some of the carriers are blocking location access (not implementing JSR 179 on their Java devices) or blocking location entirely, else the devices would likely be supported.

Given all of the above, I find it interesting to listen to my European counterparts, who are discovering all of the above for the first time. Business models, technology concerns, carrier roles. Perhaps this is an example of a case where the US is a little ahead of Europe? Due to the government?

This pattern is adapted and updated from Martijn van Welie's UI patterns with permission.

When users get deeper into mobile web sites they also need to be able to go back to important locations such as the home page or category page. The homepage is practically always relevant but the other locations depend on the context of the page.

Design

Create a consistent set of links to be displayed at the bottom of each page. Consider including links to:

• the site home page
• search
• home
• important locations

Unless you can support AJAX-like capabilities, the footer should be short, no more than approximately 5 links. Large footers will increase the load time of every page in your site.

Applicable Devices and Platforms

Web sites and other platforms that do not provide access to softkeys.

When Used

Use on all pages in your site.

Rationale

The footer is the place that is seen last when browsing a page. That is the moment when users have to decide what to do, if they haven't already done so. Home is an important element to have since it forms an always present link to a "safe location".

The design of developer program web sites almost never gets the same amount of attention that customer-facing web sites do. This makes sense, but companies should design the developer information intelligently.

Consider a developer site in which information is difficult to find, the site only works on some browsers, information is not available to users on Linux or Mac, and/or information is completely buried in 150MB downloads rather than being on the support site itself. What does this tell developers?

1. You do not think ease of use is important, so developers needn't either.
2. Hidden or buried information (like design guidelines!) is not important.
3. Information is static.
4. Users of your information all fit into the same category, so developers' users do as well.

Your site is leading by example, and it is not setting a good example. And your end users (you know, the ones who give you money) will suffer for it.

This is a site discussing end user experience, so presumably user interface guidelines are of interest to readers. Quick: go find user interface guidelines for Windows Mobile 5 at MSDN Windows Mobile section. Be sure to use the "up one level" link rather than the back button, else the frames get dissociated. I actually haven't found it through navigation and had to resort to search. So, here are the design guidelines for Windows Mobile 5.. I've had repeated experience with this search, because over the years, Microsoft changes the URLs for this type of information. Old links rarely work, despite periodic maintenance.

You'll have an easier time finding Windows Mobile developer documentation at the Palm Developer Network. Don't be fooled though: it claims the guide is for public access, but you'll still need to sign in. There's no need to protect your developer information that way.

Keep in mind that developers may not be users of your product directly. So they may think that your company web site has a link to any information available, and may not think to go to a completely different domain. So, developers for Blackberry need to go to blackberry.com, not rim.com. Now that I've gotten you that far, try to find design information at Blackberry developer site. There are some documents, spread between white papers and product documentation.

I really like Forum Nokia, despite rarely designing for Nokia devices. Click "Usability" in the left column, then get a bunch of user interface related topics. Want specific UI guidelines? Pick UI/Visual Guidelines at the bottom of the screen. No user names, no passwords, just rich data. Nokia's developers better conform to Nokia guidelines as a result

Openwave, Opera, and Sprint have freely available guidelines as well, though the information is a bit harder to get to, the information is limited to PDF documents, and the user interface guidelines are buried in a list. Again, is it important to you that your developers read and follow the documentation? I think so.