Recent Blog Posts

This has been bugging me for a while, but I wasn't sure until today whether it was me: There are too many mobile apps.

I don't mean in raw numbers, cause those are great. And I'm not complaining about pointless apps, and games or gimmicks no one uses after the first day. I mean by choice between a mobile (or mobile-compliant) site and an app, there are too damned many apps. And, again percentage wise, way too damned many iPhone apps.

We've discussed this in some detail, and while I cannot seem to find a place to link to it, we've said it a lot in presentations and training we offer. There are a series of choices when going mobile, and a key one is whether you can live with a website or have to live with an app. Neither is inherently better than the other, and your choice (even if it's "both") will always have a downside.

Today, within the last hour in fact, I saw a TV ad for a new iPhone app from Nationwide Insurance.

It's not a general insurance company app (unlike the USAA mobile site Barbara brings up a lot) but seems to be entirely focused on post-accident activities. (I don't have their insurance, so cannot be sure, but Googling presents only this app). So... who will download this? This strikes me as the perfect thing to make mobile, but also the perfect thing to make a mobile website. Why?

• Everyone has a car, not just iPhone users.
• Everyone has accidents, not just iPhone users.
• No one plans accidents, so why would they download this, even for free?
• If you have the presence of mind to remember the app you downloaded three years ago, you have the presence of mind to go web browsing instead.
• If you look at the helpful info on the insurance card, it could tell you to go to a website. Even if it told you to go download an app, the extra step at accident time adds a lot of friction.

Now, this doesn't mean a one-size fits all solution. A Barbara has dicussed here and elsewhere, you can offer multiple variations of that website. Hell, like I said above you can offer both an app and a site. But don't fall into any one trap to keep up with the Joneses, or because your new toy is really cool, so damn everyone else's.

In this case, it might well need a multi-faceted approach. Me? I'd be likely to add an option to the IVR when you call them that says we can let you do this through your phone, just press 7 and we'll send an SMS to the current number. Push message, click and launch a site without typing. Or, if you insist, install an app (unless you are on Verizon, et. al.). Sure, sure. Websites can't take photos generally, but I am sure if that's needed we can find a way for MMS to work.

Any way, think about your customers, or hire someone else to take a good, long, scientific and fact-based look at your customers, and decide on the right solution for them.

Ahh, the "One Web" discussion, again. Don't worry, there's new content here.

First, let's address the definition problem. I've seen several floating around, including:

1. The link works on any device
2. Thematic consistency
3. Same technologies on every web device
4. Same experience on every device

As you undoubtedly know, we support the first three definitions, and disagree with the fourth. Sure, it's fine for some sites, but most certainly not for all.

mobile web

I'm talking about this now, again, both because it remains a major topic of disagreement and because of a recent Razorfish presentation. So take a few minutes to view John Pettengill's slides:
Is this objectionable? I think mostly not; we are looking at the slide deck, not the full presentation. Some of the weaker points were undoubtedly discussed in greater detail. It's also a well-crafted presentation.

the counter-argument

But some technologists and strategists vehemently disagree, as evidenced by the discussion about this presentation at Forum Oxford.

Their points:

1. This leads to fragmentation and transcoding problems. Not really. Device rendering limitations and differences leads to fragmentation.
2. Users expect the website to work no matter what device. Yes. Let's make that happen.
3. Mobile versions are not always necessary or desirable. True.
4. We'd have to create hundreds of different site versions: day/night, Windows/Mac, iPhone/RAZR/other phone, nationality detection, etc. This is a straw-man argument that ignores the reality of design and development.

how do you want your brand perceived?

Let's be clear: we at Little Springs Design have put together similar decks with similar messages. And we have largely similar clients, so I'm not talking to blog owners investing in my services. I'm talking to brand owners.

Razorfish's points, repackaged:

• Do you want to plan how your brand is perceived on mobile, or leave it to the vagaries of mobile rendering and have it not work on some devices?
• Do you want to use a technological subset of your current web experience, or do you want to leverage the capabilities of mobile for greater interactivity and value?
• Design content, brand, and interaction for user context.

Let's step outside of web for a moment, and consider these questions in other environments, such as retail. Franchises want to deliver a consistent experience to their customers, and have significant process, structure, and branding rules to ensure that this happens. Despite this, successful franchises adapt their brand to fit in the current context.

Take a few minutes to go look at different McDonald's storefronts in this Flickr pool; they vary widely in their context. Even inside the menu and ordering process will vary by context. McPork, sweet tea, get your own drink, Pepsi and not Coke because of mall rules are all examples of differing experiences.

So what kind of consistency is important? McDonald's fries are as I expect them. The hamburger is how I expect it. I have an idea of what's on the menu. The Golden Arches.

What kind of consistency is important in mobile, or in web in general? Core value, primary personality. Access to my content. Access to full content.

But we should consider different contexts in our design. Is a web search while the user is lying in bed at night the same as at on the bus? Maybe we make different versions, maybe we make the same but consider both contexts in the design.

our approach

I've finally managed to consolidate our web design approach into something mostly clear:

1. Consider your user's needs, brand needs, user goals, contexts, target devices, technology capabilities, and so forth. Design one or more versions of your content and interaction.
2. Design for progressive enhancement (good experience for most devices, better for those with more capabilities) for each version.
3. Build a set of page tweaks (extra padding/size for touch screens, different image sizes, different layouts for horizontal screens, don't display access keys on smartphones, etc.) to automatically re-render each version appropriate to the device requesting it.

Or: Dynamic page content must go beyond picking content from a database. It must now include context intelligence, including mobility.

Anything else will result in a suboptimal experience with lower brand value for some large set of your customers. Which might be fine for many sites, but not for all. Many of the better mobile web companies out there are doing this, though perhaps just focused on versions for different device classes. How to select the number of versions and what they support is some of the tricky bit: should a widget version have the same experience or different? High end device with NFC, location, camera should be the same as desktop or different? Same as low end device, or different? We take a balanced approach.

I say that the "mobile version" should not be subset of the full version. Let's get past that.

The mobile experience should be appropriate to the mobile context. It might have fewer, more, or the same features. Let's just make sure they are the right features whether they are on the desktop or not.

After lunch at the Paleteria, and buying tomato plants, Alison and a friend decide to give up from the unpleasant Kansas City heat and spend the afternoon in the house. I am working away in the office here, and mostly ignoring them but then comes the phrase “How many computers do you need?” from Alison’s office.

We’re a little extreme, yes. There are…five working, running, computers in the house? I think. I might be missing one. Alison’s laptop, while in her office, lives on top of an /entirely other/ working laptop. So it looks pretty needlessly extravagant.

I respond, “Well I’m using three right now.” So they wander in, and I explain that I’m not cheating. The desktop is two monitors, but that’s just one computer. And really, I am hardly using it but to type, point and look at.

Aside from the stuff in the cloud, every document I am working on is coming from this window (which I can’t show you as it’s all secret client stuff), which is files off on the work laptop propped up in the living room.

Okay, that’s two. And the third is my mobile handset.

“No, that’s a phone.”

She, essentially, says that she knows it’s complex and microprocessor controlled, but it’s not a computer, it’s a phone. That’s why it’s called a /phone/.

Ah, ha. But besides the fact I have made maybe one voice call on it today (and have no wireline phone, so no cheating here), it’s a computer. I have SMS’d back and forth a dozen times today. I email or use the (well-synched) calendar alarms to keep on schedule even when I go eat lunch or have to persuade the dog to come inside because the lawn guy is here to spray.

I have a perfectly functional office suite, a PDF viewer arguably better than some desktop ones, can synch a Bluetooth keyboard for speedier input, and routinely plug it into the projector for meetings at work. Quality is mediocre, but we’re half a step from being able to dock and use it as a desktop computer replacement for every work task that is not about actually drawing interfaces.

I can even make it look exactly like the other computer here at home, and I open up the file system for the handset right on my computer desktop. I can, and do, trade files back and forth just like the laptop. And when I am playing with or testing UI, I’ll load graphics and take screenshots on and off it constantly. It actually /is/ being used essentially just like the laptop right now.

I spend a lot of time here saying crazy things like “mobiles are little computers” but amongst ourselves it’s easy. Getting called on it from others is interesting, and made me look at it somewhat differently, and maybe believe it a little more than I consciously had before. I’m not sure Alison’s friend is convinced just yet, though.

I frequently get asked, both by clients and by our mobile web design training attendees about how much scrolling is okay. The answer is that in general, scrolling is better than fetching another page. Consider the length of an address book.

But that answer doesn’t go far enough. There are technology limitations: some devices can only support a markup size of 10,000 bytes or so. And many pages would be perceived as being too slow if they had 30 links or 15 images.

And the user has to know that the content scrolls. Even if the device does have scrollbars, they are likely to go unnoticed as a cue. So you have to design your content for scrolling.

Scrolling Recommendations

• Limit markup size to what the device can comfortably handle. This sounds obvious, but the “comfortably” bit is important, too. We’ve seen web sites that would render on a Motorola RAZR, but were so heavy that the device didn’t have any capacity to spare for moving the cursor in a timely fashion.
• Ensure users have a reason to scroll. Make the top part of your page/screen compelling. Avoid closure, false bottoms. Create expectations that more is below. This is especially important on landing pages.
• Use just-in-time fetching for infinite lists. For applications and browsers that support Javascript, don’t fetch a new page at all; instead add items at the bottom of the list as the user nears it. You can remove items at the top if you run out of memory. The Gmail Java ME application does this very well.
• Provide accelerators for certain lists. Opera Mini uses left and right to page-scroll up and down in some modes. Openwave browsers support volume up and down for page scrolling. The iPhone Address Book provides letter shortcuts and handles the problem of the letter being too small by only using it to scroll to a spot, rather than filter. Some sites have within-page navigation.
• Reduce page length by:
  • Using only key navigation links (maybe just Home) rather than a full set on every page.
  • Providing the first few items of a topic area, like the first 5 comments, and linking to a full list of comments
  • Only putting the spacing needed for touch users on touch devices

You can also make compelling user experiences without scrolling, but they will tend to be applications and have a lot of screen states.

I was fortunate enough to speak at, and attend, this month’s Mobile Design UK meeting. We had great presentations from Google, Nokia, Yiibu, and Little Springs Design.

Younghee Jungand Joe Macleod of Nokia spoke about mobile gesture research and design, following a process similar to our research. (I don’t have slides, but the above link has a lot of information, including a video presentation from the designers.

I like what Bryan and Stephanie are doing with their XML + Processing rapid prototyping method; we’ll be investigating it ourselves. Bryan says:

I wanted to explain some issues about how the US differs from Europe with regards to mobile use, and look at Internet and Telco thinking and our class-based design thinking. The slides may or may not do it justice; I’ll be talking more about the latter two topics over the next couple weeks.

Click the image to play the clip (30 min, MP3 format)

Designer and Author Steven Hoober is interviewed by Christopher Nemeth about his new book, “Designing by Drawing: A practical guide to creating usable interactive design.” Duration: 30 minutes.

From Steven’s blog: “This is a book for designers, prospective designers or other usability professionals who find themselves designing interactive systems of any sort.” The innovative thing about Steven’s book is the “community commenting” feature of his book, that allows for readers to contribute their own annotations to the book itself, allowing the text to become a “living document” that will grow with time.

For more information on the book, to buy or to add your own comments, visit the page. It can also be purchased from Amazon.com.

Podcast: Play in new window
| Download (21.8MB)