Recent Blog Posts

Last week, I hypothesized that it should be possible to take a picture of business cards with the mobile and have the data added to your contacts in a variety of ways. I was told this does indeed exist, and a quick search found scanR. Unfortunately, when Steven tested it on his N75, it didn’t work. He could recognize the text in the picture, but the OCR (optical character recognition) failed. I look forward to further improvements in the area.

A similar – and technically better – solution was reported by NPR this week. This one adds optical technology and recognition software directly to the device; it is targeted at helping the blind navigate their world.

“Taking picture … detecting orientation,” a digitized voice from the phone says. “Processing U.S. currency image, please wait … $20.”

This is on a full-featured Nokia device, and is a further example of Nokia serving various special needs populations. But as we see from the business card reader, it would be trivial to convert the reader to the larger population. If it can process text to be able to read it, then it can process text to save text. A scanner in your pocket.

Once we have this engine in a device, a new array of physical-virtual world integration products become possible.

Last week, I was a bit upset about Yahoo’s incomplete local search results. More recently, I was looking for a hotel in Oakland for a couple of nights. After refining my search, I had 15 results; you can see all of them on the map:

Our best guess is that somebody switched latitude and longitude for hotel #15. I do wonder what such a transposition does to their sales.

Again, serving your users means having data of an appropriate quality level, that users can rely on.

There are three terms flying about the industry that are differently understood by different parties: “one web”, “mobile web”, and “widgets.” The different understandings of these definitions affect everything from coding to strategy.

Mobile Web. Definitions range from “some type of access of data off of a web server from the mobile device” to “web sites accessible from mobile browsers” to “mobilized web sites”. The first definition includes email clients, instant messaging, maps, directions, and so forth. The second definition isn’t helpful, and the third definition is pretty silly. I don’t have a good answer here, and avoid the term entirely. I’ll use “mobile web sites”, “widgets”, “downloaded applications”, and so forth. I define “Mobile Internet” with the first definition.

One Web. The W3C definition is nice, but not terribly useful. It simultaneously says to make the same information available and not to make the same information available. More and more companies are taking the desktop web, shrinking it, and displaying it on a mobile device: “one web”. Opera, at least the various Opera people I’ve spoken with, tend towards writing one web site and maybe using different CSS files for different devices: “one web”.

It’s these latter definitions of “one web” that make more sense to me. Many long tail sites will use one or the other of these options to deliver desktop sites to their mobiles. Other long tail sites will just go with a mobile-friendly site for all their users. But these options come at a cost. The user experience is not as good.

You can get a good feel of what the user experience cost is in yesterday’s Mobile Web USA presentation, now available online.

Why might different CSS files not work? First, the differences in layout can be profound, resulting in very large CSS files and lots of computation (if it can be done at all). Second, the too-large XHTML file still has to be downloaded to the mobile, slowing the user down. Finally, I frequently want to put some of the content on a different page entirely, and CSS can’t do that. Do correct me if I’m wrong, but the comeback will be that CSS1 can’t do that.

Mobile Widgets. I think the most prevalent definition is “small applications created using web technologies and delivered on the mobile device.” This is a good definition, but there are numerous categories within this definition. In our widgets white paper, we focus on widgets available at or near the standby screen. This does include Celltop by Alltel, but does not include Opera Mobile 9 widgets, Nokia Widsets, or Yahoo Go widgets.

At the Mobile Web USA conference, Yahoo bravely did a live demo of Yahoo Go 3.0. They did a sample oneSearch based on the conference location for “sushi.” (what is it with mobile search demos and sushi?) Three results were returned, in order of increasing distance, with others available beyond the cut.

The closest result was listed at 1.2 miles from the conference venue. They then got directions to the restaurant, and the drive distance was 4.5 miles. On my 0.5 mile walk back to my hotel from the conference, I passed 3 sushi restaurants.

How do we learn to trust results like this?

In my last post, I developed a new definition of quality: a positive user experience. As with many of the other definitions of quality, this depends on context of user expectation. Users of poorly designed intranets, for example, will have a positive experience with minor improvements. Apple and Nokia have a higher standard to achieve.

One quality problem in the mobile industry notorious with developers is user agent strings that lie. A device might claim to handle a larger web page than it actually does, might claim to be a different device, might neglect to define certain values, and so forth. As a result, a web site causes the device to crash, an application that should work doesn't, images are the wrong size, softkeys work unexpectedly, and many other problems.

I saw this problem back in '99 with devices from several manufacturers. One device claimed it could support 1492 bytes, but could only support 1300 and would crash with anything larger. One device provided its maximum size in hexadecimal where every other device provided the number in decimal. The list goes on, and the entire device description repository industry (such as WURFL, Volantis and DetectRight) is an answer to the problem being even worse today.

The end customer then sees applications and web sites that do not work quite right or perhaps not at all. Developers who struggle to deliver a good user experience eventually discover that they can not trust the user agent string, and then turn to a device description repository. The cost of delivering a mobile application escalates, and the user experience degrades.

In the scope of designing, building, and debugging a phone, these errors are tiny. On the other hand, finding the errors and fixing them is very easy. These problems arise due to a combination of industry players. Device manufacturers do not attend to the problem under very tight production schedules. Operators, if they find the defect at all, assign such non-operating bugs a very low priority. Anyone who has worked in commercial grade software development knows that the low priority bugs never get fixed. (Apple's broken search engine is an example of this)

While the customer sees that the web site is of low quality, some of the problem rests in the hands of the browser provider, device manufacturer, and operator. In the past, at least in the U.S., the operator was blamed. More and more now, the web site provider is blamed.

Operators and device manufacturers need to do a lot more to support developers. After all, operators' revenue comes from device usage, which is driven in part by good applications. Device manufacturers can expect to upsell to better devices and retain customers who have a good experience with web sites and applications.

A brief list of low-cost ways of supporting developers:

1. For each device, invest the 1 hour of QA and 1 hour of development to make the user agent correct.
2. Designate a person to provide accurate data to existing device description repositories.
3. Use that same person to monitor the quality of the data in existing device description repositories.

   Tags: Business,  Carriers,  Devices,  Java ME,  Mobile applications,  Mobile web, Permalink | Comments (3)

While preparing for a recent interview with a member of the Japanese media, I struggled to articulate why user experience and usability are important. Leveraging the Japanese quality culture of the recent half-century (and my own training in industrial engineering), I realized that user experience including usability is precisely analogous to quality of design in physical products.

Further investigation revealed the majority of defintions appear to have customer experience explicitly included. Definitions selected from the Wikipedia entry:

• Philip B. Crosby in the 1980s - "Conformance to requirements". The difficulty with this is that the requirements may not fully represent customer expectations; Crosby treats this as a separate problem.
• Joseph M. Juran - "Fitness for use". Fitness is defined by the customer.
• Noriaki Kano and others - A two-dimensional model of quality. The quality has two dimensions: "must-be quality" and "attractive quality". The former is near to the "fitness for use" and the latter is what the customer would love, but has not yet thought about.
• Gerald M. Weinberg - “Value to some person".
• Genichi Taguchi - Taguchi's definition of quality is based on a more comprehensive view of the production system, and he relates Quality (or, more precisely, the lack of it) to "The loss a product imposes on society after it is shipped".
• American Society for Quality - "A subjective term for which each person has his or her own definition. In technical usage, quality can have two meanings:
  1. the characteristics of a product or service that bear on its ability to satisfy stated or implied needs.
  2. a product or service free of deficiencies."

Customer expectations and perceptions are squarely considered in the above definitions. The entry explicitly notes, “The quality of a product or service refers to the perception of the degree to which the product or service meets the customer's expectations.”

Do keep in mind that in these definitions, “customer” is not necessarily the person on the street. Indeed, extracting that person's requirements is challenging, and a task performed by marketers and user experience professionals. Further, the person on the street does not typically have the knowledge to measure highly technical aspects of quality.

While the person on the street does not experience many of the individual features & bugs that make up a product, she does experience the product, interaction, features, support, feel, sales, and even disposal process as a whole. Thus, fundamentally, user experience is quality.

All the players in the mobile industry work, only sometimes in concert, to deliver the user experience. Consider:

• The iPhone would not be nearly as good with a pay-per-megabyte from the operator.
• UK phones support internet, but the process for setting it up with the operators is arduous.
• Applications work well, but the device displays frightening messages about their safety (at the behest of the operators).
• The device reports its characteristics via the user agent string, the operator passes it through, the developer incorporates it into the application or web site design. More on that later this week.
• The device reports its type via the user agent string, but a gateway strips it out and replaces it with data unrelated to the device.

Let's improve user experience. Let's improve quality. Our users deserve it, and so do our profits.