The Experience is the Brand

Three issues with all the Apple tablet predictions

Besides the obvious – that I will want one – I have a few thoughts about the tablet Apple will supposedly unveil tomorrow. There are three areas which I think deserve some attention:

The Case
An enlarged iPhone-like tablet seems troubling. The case and screen of the iPhone seem unlikely to scale well to three or four times their current size, the end result of which would be a device which seems somewhat brittle. iPhone screens seems to crack like a pile of dry leaves, so increasing the surface area by two orders of magnitude seems a recipe for continual breakage.

The Weight
Again, simply scaling the iPhone up larger isn’t going to work – especially if the display uses the same optical glass and the case materials are similar. Assuming that the intent is to provide a device which, at least in some instances, can be held like a paperback book or magazine, the device has to be lighter per square inch than the iPhone – and significantly so.

It’s simply a matter of ergonomics: while you cradle an iPhone in your palm with your fingers and palm wrapped around the four edges, the weight of the device is distributed through your wrist and into your forearm. With a magazine-sized tablet, you can’t wrap your hands around it that way – you have to pinch the device with four fingers on the back, and your thumb on the front. While this is easy enough to do for extended periods with a magazine weighing less than an ounce, just try it with a tablet weighing a pound or more. Which brings us to the third quandry:

The Input “Device”
There are a number of intriguing possibilities, but one thing is nearly certain: your hands are involved. Voice control is clever, but pointless: in the best case scenario, complete and instant voice recognition still leaves you with a low-bandwidth control channel which can’t be used very well in public. (Most people can only say one thing at a time.) And some sort of facial recognition system is very futuristic sounding, but baffling: exactly what facial gesture does one make to “check email” or “empty the trash” or “redo last filter”?

And for anyone who wants to suggest some sort of eye-tracking technology, let me put that one to rest: even the best systems (my company owns one) require calibration each time you sit down in front of it, and the triangulation assumes that the screen itself remains fairly stationary.

OK, so you’re hands are involved. There are a couple of issues:

If you’re holding the tablet in landscape mode, with one hand on either side, then the UI controls need to be arrayed up and down each side. Ditto in portrait mode:

That’s all well and good, but while you’re holding the tablet with both hands, what are you using to control the applications?

The other possibility is that you hold it with one hand, and interact with the other. There are problems with this, too: single-handed interaction with a multi-touch display limits the kinds of applications you can have, and each tap with your free hand increases the fatigue on the other hand holding the device up.

So what about putting the device on a surface? Well, this frees up your hands, which is great: fully interactive display, multi-touch, virtual keyboard – all of these things become feasible and reasonable. But there’s another problem – with the device on a flat surface, you’d have to be hovering above it directly in order to have a good, clean view of the screen. At an angle (even assuming you don’t lose brightness and contrast) the perspective is going to make interacting with any application rather frustrating.

So, what’s the solution?

One possibility is the integration of a laser-based projected keyboard, and an integrated stand for propping the screen up on a surface. The former is already widely available, and the latter could be accomplished with with a built-in “wing” that worked much like the flap on the back of a picture frame backing, or as an optional wrap-around case.

It will be interesting to see what solution Apple chooses.

Shocker of the Week: Mobile Usability is Hard

Aside from the more interesting data collection techniques used in the study, Jakob Nielsen has dropped a stunning bomb on the world of mobile web development:

Creating a useful and usable mobile experience is hard.

Of course, that’s only true if you are designing for the mobile experience, as opposed to redesigning a web experience for mobile. They’re different things.

Despite the prevalence of smartphones and iPhones and other mobile web devices, the reality is that, at least in the U.S., 85% of people still use a basic handset with a numeric keypad, and a 90 pixel-wide screen.

90 pixels wide: that is roughly the size of a large postage stamp. Those of you who have worked in the offline world, consider this comparison: you’ve been asked to take a full-page ad in USA Today and redesign it as a 6-line classified ad in Milwaukee Journal Sentinel. Or condense a 2 and a half hour film into 30 seconds.

These are not impossible tasks, but they are difficult. You’ve got to make some hard choices.

At The Archer Group, we’ve been hard at work on a couple of iPhone apps recently. Even on a richly interative, touch-screen platform with a screen as large as that, application development is largely a process of deciding what to leave out. Simplicity – both in terms of the UI but also at a deeper level of how information and functionality are structured, is essential.

On a postage-stamped sized screen, where input is limited to a 12-button keypad and semi-usable, at best, predictive-typing, there’s only one rule: if in doubt, leave it out.

If you find yourself overseeing the development of a mobile app, or the mobile view into your company’s existing online offering, consider this:

• The most popular feature among mobile phone users is voice. 100% of handsets can make phone calls.
• Assume that your audience is on a slow data network; graphics still take significant time to transmit, text is faster
• The mobile web is the Mathalon, not the Miss America Paegent; it doesn’t matter if you’re pretty, you have to be right.
• Of everything you offer your customers online, pick ONE THING to do on mobile. Do it extremely well.
  • After that, you can think about expanding your feature set.
  • Once you think about expanding your feature set, STOP, and DON’T DO IT.
• Go back and look at the one feature you built: make it work better and faster before you try to make it do more.

See, mobile usability isn’t that hard after all.

If someone visits your website and they have javascript turned off, do they really exist?

Every few weeks, the conversation here turns to web analytics. Not because anyone but a handful of us are really so deeply interested in the subject, but because there’s a pertinent question about a campaign or site we’re developing, and we can all agree that “the numbers don’t lie.”

I’m a big fan of Google Analytics, not least because the feature-to-price ratio can’t be beat. (“Nothing a month” is a very palatable price point.) Never the less, it has it’s drawbacks. But everyone does.

• CoreMetrics, SiteCatalyst and their brethren can be difficult to implement, and costly. Their price point puts them out of the reach of most small and medium size businesses.
• Log File analysis packages like ClickTracks work well, if the logfiles are well formatted and collecting all the data they need to be. Which isn’t always.
• Google Analytics has a couple of blindspots, most obviously the fact that it relies on Javascript, so if you have visitors to your site with Javascript turned off, you don’t know what you don’t know.

But if you’re worrying about whether or not the data you do have is 100% accurate, let me set your mind at ease.

It is not.

And yet, life will go on.

Instead of trying to nail down which metrics package is absolutely the best of the best, and cheap, and flexible, and always accurate, ask yourself these questions:

• Can I compare this campaign to the last one? Am I measuring success in the same way?
• Can I compare performance among my advertising venues based on the quality of traffic they send to my site (especially important when your business is not an eCommerce-driven one, and most sales happen offline.)
• Over time, can I tell if I’m improving? Are people coming back? Is that even what I want?

Note the common theme among these questions: you’ll have to pick a tool to measure with if you have any hope of getting to specific answers that are reliable over time. And while everyone has blind spots, focusing first on those areas you can see will help you build a better experience over time.

Next up: Tracking activity off-site

Why smaller is better

Apple’s new video iPod inherits from its forerunners the same sleek stylized design and feel, and can now act as conduit for other media besudes audio, including still pictures and video – with the same ease of use as previous generations. So why are people dissing it’s small screen size?

At just over 2.5″ inches across and sporting a 320 x 240 resolution (about the same, rotated 90 degrees, as my 2001-era Sony Clie), the screen itself isn’t much to get excited about. In fact, the whole idea of video on an iPod isn’t a whole lot to get excited about (I’d wondered why so many people were frothing at the very idea of a rumor possibly maybe being true.) Compared to the PlayStation Portable, it’s not very impressive.

Which is completely besides the point, because the screen doesn’t matter. It doesn’t matter because it’s just a UI – it’s not the real delivery device for video any more than it is for music. Complaining that the screen is too small to watch movies on it makes about as much sense as complaining that it’s too small off of which to read song lyrics. You didn’t buy an iPod to read song lyrics, you bought it to plug in headphones to listen to music.

Just like you’re going to buy the video-enabled iPod to plug it into your television. Or your iMac. Or your Powerbook. Or someone else’s laptop, TV, projector, etc. The new iPod is no longer an MP3-player (if it ever really was.) It’s a portable media station, a portable DVR – the “to go” portion of your digital life. iTunes 6 will let you download videos, television shows, movie clips, etc. – and not so you can watch those things on your iPod, but so that you can watch them wherever the hell you want to.

Quoted in the Philadelphia Business Journal

There’s a small quote by me in this article in the Philadelphia Business Journal, concerning some work that I’m doing for the Philadelphia Parking Authority. It’s an ambitious project, though not one I can talk much about yet. But suffice it to say that, for a semi-governmental municipal agency, the Parking Authority is up considering some pretty cool stuff.

Check out the article here.

Kids and Usability

A while back I wrote an article about Kids and Usability. It’s Part 1 of 3 (though to be honest, I’ve only written two of the parts.)

Developing websites for kids poses and interesting challenge, and one which is best met by a passionate and highly skilled interdisplinary team.

This article covers some of the basic “rules of the road” when developing sites for kids. The next part covers a specific example of a site I recently helped develop.

The day before yesterday's news

Just a brief mention that I have been profiled in the Monday, November 3rd edition of the Philadelphia Inquirer. A nice piece, I think.

A little context is in order: It’s not as though a reporter called up my company and said “we’d like to follow Ben around for the day.” Actually, it was a little bit more like “we’re doing a semi-weekly series on people who have jobs that most normal people don’t know about, or understand. Last week we did a professional horse groomer. Do you have anyone who might fit the bill?”

And of course, everyone thought of me.

Read it online while you can. In about 4 days it’ll disappear into the archives, and you’ll have to pay to see it. (Gee, that sounds familiar…)

Jakob Nielsen, evil genius

While perusing his site trying to find a good description of “talk-aloud” testing, I came across this little gem:

Patents
…
20. Nielsen, J.: Method and apparatus for facilitating popup links in a hypertext-enabled computer system, U.S. Patent 6,373,502 (2002)
….

What the f*ck?! A patent for popups? The most heinous user-interface abomination known to usability professionals worldwide, patented?! By Jakob Nielsen?! What the hell is going on here?

Sadly, it appears to be true.

I don’t like software patents to begin with; they seem like a rather sneaky way of awarding potentially massive royalties to someone based solely on the fact that they were the first to describe a programming hack, if not the first to actually do it. At my company, if we bothered to file a patent every time one of our programmers thought up a new, potentially useful way of hacking code, we’d never get anything done… and that’s essentially the problem with software patents – there’s so many useful and novel “inventions” of code being created every day that to try and patent each one of them would overwhelm the patent system entirely.

Oh, wait, that’s already happened.

Well. If Jakob Nielsen has a patent on popups, then I think he has an obligation to enforce that patent, with the aim of either:

• Showing everyone exactly how evil he really is, by reaping millions of dollars from one of the Internet’s most annoying “features”
• Forcing every pop-up ad vendor to pay such enormous licensing fees that they go out of business, thus ridding the Internet of one of its most annoying features.

I consider it a moral obligation, on his part.

Breadcrumb (in)efficiency

This research piece attempts to determine whether or not breadcrumb trails improve navigational efficiency on web sites. Specifically, they stick to investigating “location” based breadcrumb trails (those that indicate the user’s present location in the information hierarchy, rather than the path they used to reach a page.) Their conclusion is (roughly) that breadcrumb trails result in less usage of the “back” button, but no significant differences in “efficiency” (task completion time, total number of links followed, etc.) Several other important points are made, and backed up with statistical evidence (nice, that.)

I think they miss one important point: “Efficiency”, while measurable in definite terms like task time, is itself a proxy for experience. I think the central issue is whether or not including a breadcrumb trail in a site design makes the site feel more efficient, regardless of whether users’ task performance improves. After all, the real question is not whether or not users can complete tasks quicker, but whether or not they think they’re completing them quicker (and thus are happier with the web site.)

When is a persona not really a persona?

Henrik Olsen spins a good yarn about developing personas for a Scandinavian tin can manufacturer. As he quickly points out, he didn’t exactly do it the right way. Instead of interviewing actual customers of the site, he interviewed people who spend most of their time dealing with customers of the site. This is an OK way to do it, if time and budget are limited (though experience has taught me that it takes pretty much the same amount of time to talk to customer service representatives, as it does to find and interview actual customers.) One might more accurately call the artifact of this effort a provisional persona, rather than a full-bodied persona. (See “Getting from Research to Personas“.)

Now, let me just come out and say that personas are a tool, like a hammer. They’re a really good tool for understanding how people behave, but they’re not the perfect tool. (Nothing is.) Personas can’t tell you, for instance, whether to color combination you’ve selected is appealing (try a focus group.) Personas can’t tell you whether the check-out process on an eCommerce site is architected correctly (for that you’re going to need usability testing.) To me, personas are really good at helping you choose features, the depth of their functionality, and the specific design directions that your site needs to take.

Provisional personas will work too, but you’re trading accuracy for time/budget savings. That might be worthwhile in the short run (especially if you’ve got to get something launched by a specific, looming deadling) but it might wind up costing you a lot more in the long run. When forced to settle for provisional personas, I usually insist that usability testing occur at multiple points during the design phase.

There is one major risk of relying on provisional personas: too often, the result is a set of personas the reflect the kind of customers to whom you want to be selling your products. Or worse, they reflect only a certain type of customer (maybe just the ones who are the most vocal.) In both instances, you’re working with your blinders on, perhaps missing the forest for the trees. In either case, you’re getting a filtered view of your customers, which is never as reliable and informative as the real thing. Factor this into your development process, and highlight the risk appropriately.