Recent Blog Posts

Have you noticed that using your laptop on public wi-fi is a somewhat less than seamless experience? Certainly, if you are reading this blog, the answer is yes. In our small midwestern city the wi-fi coverage is not consistent, but that's obvious.

For larger cities, I keep hearing phrases like "ubiquitous wi-fi" and of course "municipal wi-fi". But I find that the experience in larger cities is even worse. All of these visible networks may look present, but poor network design, overloaded access points, semi-secure networks, arbitrary passwords, and more get in our way. I've sat in a hotel lobby with 15 access points available (all public), but not a single one useful for actually getting my online data.

My slow but well-engineered 1xRTT or EDGE network is far more reliable. This, of course, is the brilliance behind devices that can use either network. The rule is simple for most users: use the free/fast network if available and reliable; the other network if not. For other users it's also obvious: use the secure network that's faster/cheaper. Too bad more devices don't get this right.

At home I have an excellent connection ... unless somebody is broadcasting locally in the relevant band. Our friends have an excellent connection ... unless the weather is bad. This sort of issue appears to be more and more common.

So it seems that web storage continues to have problems for several types of data. Local storage will never go away.

If you haven't seen C. Enrique Ortiz's page on mobile context, you really should do so, especially if you are a designer or developer.

User and device context is the key differentiator between computer-based applications and mobile-based applications. What is the user doing? Where is the user? Is the user available or not? Which device is the user using? Who is nearby? Is the space quiet or noisy?

Sure, we can develop devices that render "the one web" adequately while mobile. And sure, for the majority of sites this will be the best answer. But there is a large number of sites - most anybody with a user experience team, for example - that need to consider the mobile context.

My best evidence that there will be a mobile web is the ever growing number of sites targeted just at the iPhone. Here is a device with the best current web rendering available, that even pushes the boundaries. Nevertheless, developers and users seem to want a contextualized user experience.

I get asked this question a lot due to our extreme industry + discipline focus, so I thought I'd answer it here.

Business is going great, with accelerating growth. This appears to be due to four factors:

• US mobile data critical mass appears to have been reached. Since a large portion of our work is in various forms of mobile data, this is important to us.
• Mobile industry usability focus has greatly improved, even before the iPhone effect. More and more companies are contacting us to help with version 3 of their products, where they've not focused on user experience before.
• The iPhone effect. Now folks are playing catch-up. We're also getting calls about designing for the iPhone.
• Designing the Mobile User Experience has been released for a few months and is communicating the level of complexity involved with mobile user experience.

This is an exciting year, and we are growing. In fact, we just hired a new senior interaction designer, Steven Hoober, whose web expertise will definitely help us grow.

Imagine walking into a nice hotel, having a very easy time checking in, being greeted by name, and even being given a cookie. You have a very positive impression of the hotel.

That impression can get worn down by the details. Not just the cleaning staff, but from work done long ago by somebody with no investment in your brand whatsover: construction workers.

The sink controls have hot and cold on the wrong sides, causing you to drink warm water for a while.

The tub faucet is designed in a way that suggests it is a lever, but actually it requires that you brace yourself and pull straight out. The shower curtain rod is crooked on the square tiles.

The television remote has a nice large button at the top right, which does not turn on and off the television. (a small button at bottom does that instead).

The free in room wi-fi only gets into your room sometimes, and only in one corner of the bed.

You learn that your credit card data is stored on your room key.

You don't finish the Starbucks coffee brewed in the room due to the aftertaste created by an uncleaned coffee pot.

The exercise room is not open 24 hours, despite being separated from all guest rooms.

Every time you enter the room, it takes two tries to open the door -- even though the LED indicates success on the first try.

The business center does not seem to have a way to print from your laptop without installing print drivers, at 99 cents per minute (charged to credit card, not room).

The toilets in the public restrooms are "conveniently" close to the side of the stall the low-placed toilet paper is on. This configuration requires a bit of contortion to actually reach the paper when you need it, and requires larger patrons to have to twist to use the toilet at all.

These details are busy degrading the hotel's brand, and they are mostly out of the control of the current management. These are the same types of details degrading your brand, but they may be more under your control. And I recently had an experience with all but two of the above aspects; the other two were elsewhere.

I can guarantee that the architect did not envision toilet contortions, and quite probably had more human specifications for the actual layout. The folks doing the actual installation didn't have that vision; they were just showing up for a day's work.

Maybe the specifications didn't make sense, maybe the workers thought they knew better (perhaps because they had to "fix" other parts of the specification), maybe they were just lazy.

Developers do this too. They have to, for the same reasons the construction workers do. But their expertise is in building things, not in designing an experience, so some of their fixes won't be right, and your customer may suffer. But remember: developers want to do a good job.

Increasing the details of your specification only helps if you've been under-specifying your product. In most cases, more specification won't help. In software, if you fully specify the software you have essentially written the software but in the wrong language.

You will experience these problems more in environments where specifications go "over the wall" between product management/marketing into development.

Solutions:

• add a designer component to the QA process. By providing responsibility for product review on the design team, both specification misinterpretations as well as places where the specification was wrong or incomplete are caught.
• train developers on user-centered design. While their job is to build the thing, an increased awareness of how to translate user needs into design will help their "fixes" of the specification.
• include developers in the formation of the vision and design of the product. This increases buy-in, increases understanding of why things are as they are (for better "fixes"), and increases the likelihood that the envisioned design can actually be built.
• increase the flexibility of the development team. Take an attitude of prototyping, of the right to throw away code. Thus errors are not fatal or permanent. This is particularly important for open source teams.