Recent Blog Posts

Quality assurance (QA), and its associated development process, has a major impact on user experience (UX).

In every large software project I've experienced, various bugs don't get fixed. Developers and project managers focus on high priority bugs, usually defined as bugs that prevent the system from working. Lower priority bugs are left for later releases. In many organizations, the previous version's bug list isn't even reviewed for the next release.

Taking a few notable companies to task:

• Apple's search system in OS X has been broken since at least 10.2. I have a large PDF file, created entirely in OS X, that still has only one hit for the search term "css". The punchline: it's a 190 page web style guide that has an entire chapter and an appendix on CSS. Mail search is similarly broken. They then built Spotlight search services on top of this broken system.
• Cingular phones cause speakers (computer, headphones, speakerphones, and even my doorbell) to emit bursts of static when a data connection is made.
• While all mobile phones report certain characteristics in their user agent strings, application and web providers can not rely on them. They lie. The device name may not be accurate, the screen size might reflect full screen or screen available to applications, and many other inaccuracies. I've seen problems with Samsung, LG, Nokia, and other manufacturers.

I think the problem for mobile phone testing is worse than it is for standard software testing. Margins are tight, carriers demand different software loads, and product managers focus on making the core systems work. A bug in how the browser renders certain CSS properties will only be fixed if it crashes the browser or management provides strong leadership and incentives to have the problem fixed.

An organization putting out a desktop browser has significant incentive for the rendering engine to be great. A device manufacturer has very little incentive to get the browser rendering great or even good enough, as feature phone users will not consider this function when purchasing.

I prefer browsers built by third party companies to those built by the device manufacturers, but this introduces its own set of issues. The browser user interface may not be compatible with the device user interface, and the software is not closely integrated with the rest of the device. Both add-on browsers like Opera Mini and built-in browsers like Openwave have these problems, albeit with different intensities.

The problems created by these "low priority" bugs have profound ongoing impact on user experience, the more so for mobile. I don't trust Apple search and may never do so. Cingular phones seem cheap with their built-in wireless connection monitor. And browsers and application environments can break the way my preferred web sites and apps work.

In the mobile industry, these "low priority" bugs are significantly inhibiting data usage, both from a user perspective and a developer perspective. Improving the quality of the software development and testing process would likely result in increased revenues for all parts of the mobile value chain.

Last year I put a new phone on my Sprint account. I was replacing a phone maybe 18 months old, but Sprint didn’t pay for the new phone at all. I acquired it through separate channels. They told me that this would extend my contract. I was irritated, but I went along with it. They also told me that the contract time was not the same as the time until I was eligible for a discount on a new phone.

So why did they reset my time until a new phone discount? Basically, they claimed $150 from me, non-consensually.

Well, the new phone was “Power Vision”, not “Vision”, so I had to update my plan. $15 extra per month for my unlimited data, whereas before it was $10. Unlimited data was all I wanted, the television just wasn’t interesting. Fuming, I signed up for the extra charges.

Then I needed to take a phone off of my plan, and transfer the phone number elsewhere. The person who was using that phone had neglected to tell me that it didn’t work at home. Sprint was unimpressed, and charged me the $150 to transfer before the end of that contract. Sure, they were within the contract but ticking off a long time high value customer doesn’t seem like a good idea.

At the same time I took another line off the plan. This one was eligible for a new phone. I didn’t look closely enough, and it was another 60 days until contract renewal. So I could upgrade my phone but not end the contract. Another $150.

For the final straw: last month, I did significantly more text messaging than usual: 140 messages. And I got charged $0.15 for each one. When asked when text messages were removed from my all-you-can-eat data plan, I was told, “last March, when you upgraded your phone”. Yes, that’s right: I pay an extra $5 per month and I no longer get text messages.

I am furious.

I can’t believe that I did this, but I just made my Sprint phone voice & text only. For everything else, I’m using my Cingular/AT&T phone or pay the $0.03/kB for this phone.

At this point, I will likely switch carriers at the end of my contract. This is a strong statement, since Sprint is a major customer of mine. That’s fine, I’ll make them provide me devices for the duration of the relevant projects.

We’ve been working for a while on our site. There have been a lot of content updates, with new pages for specific customer types: carriers, device manufacturers, mobile web providers, and mobile application providers.

We are working on building a mobile design resources page. This is very much a work in process. In the meantime, our old links continue to work.

Check it out at http://www.littlespringsdesign.com (link provided for all you RSS readers).

I often hear brand owners talk about wanting a consistent user experience across devices, including computers and interactive televisions. They cite transferability of user knowledge, support costs, and brand identity.

Please know that “brand” is more than just a logo and color scheme. The US flag, its logo if you will, has seven red stripes and six white stripes and a blue field with fifty stars in a particular arrangement. Is that all that “American” is? Hardly.

Definitely control the presentation of your logo, but definitely do not impose artificial constraints on the experience of your total brand based on different user interfaces.

Consider the iPod and iTunes. Both present the same information (excluding the store), but they do it in very different ways. One is a simple menu structure with fast scrolling; the other is a multi-paned window with sophisticated controls. The user data is arranged in the same ways, but its presentation is different.

Why then should a web site look the same on mobile and desktop? Or between a Nokia E91 and a Motorola RAZR?

They shouldn’t. It doesn’t make sense for your brand, and it doesn’t make sense for your users. If it is necessary for your support desk, you need to reengineer your support system.

A brand that looks exactly the same on devices that don’t act or looks the same ends up looking brittle. Further, this forces a “least common denominator” approach to design; an internet watch device would either force you to reduce features across the board or instead not support the watch. Either way your brand looks more brittle, and your users are not fully supported.

Some applications can reside entirely on a mobile device, with no ongoing server or personal computer data storage. This is about all the other applications. Email, games' high scores, social networking, calendar, presentations, messaging, media.

A key architecture decision that affects user experience is where to store data and application logic. Traditional web sites store both on the server only. AJAX enables a small local cache, mostly of application logic; the Gmail client does the same. Some applications, such as music players, stores a subset of the data locally, usually with access to the complete data online. Finally, many on-device applications are basically local applications with some server or desktop connection. Examples include Nokia Wallet, which stores receipts on the device only.

This architecture decision impacts three key aspects of user experience:

• interaction flow, or the rhythm of user reaction and system response
• data freshness, or the confidence that the data being viewed is the most up to date data available
• data availability, or the degree to which crucial data can be accessed across a variety of situations, including airplanes and coverage holes

To best make this decision, carefully consider the needs of your users and the capabilities of the devices and platforms. A stock price application clearly values high data freshness above all; calendar users need to reliably be able to glance at calendar data ... quickly.

	Server only	Local cache	Local subset	Local
Flow	Slow	Variable	Mostly rapid	Rapid
Data freshness	High	Mostly high	Medium	Low
Data availability	Risky	Risky	Variable	Safe*

• local applications keep data safe only if the device is intact or a good backup/sync program is in place.

It might help a little bit to understand this with an abstracted visualization. I've assigned numeric values to the above tables. Note the distinct trends, but no architecture is perfect.

So what we see is that local applications excel at rapid interaction (flow) and data availability, but have a risk of low data freshness; these applications are also subject to the storage limitations of the device.

Different platforms lend themselves to different parts of the data storage spectrum. Web sites can support server and transient local. Flash and Java excel at transient local, local subset, and occasionally local only. Native applications excel at local only but can theoretically support the entire spectrum.

Widgets of various flavors are good at displaying a subset of data; the balance of the data could be local or on the server.

Note that using SMS to interact with an application is an application with server only data, and ends up with the weaknesses of both local and server applications. This is actually acceptable for certain types of application, and the asynchronous nature of communications can even enhance certain user behaviors.