Archive for December, 2008

Design for Mobile 2009

Thursday, December 11th, 2008
My N95, plus Alison's Gz'one, Jana's borrowed Razr3 since she destroyer her BB, the office N800, my VZW aircard and Barbara's iTouch and E71

For everyone looking to plan their 2009 conference schedules, you can pencil us in for the 20th - 22rd of April. If you liked your trip to Kansas before, or are jealous of your friends a co-workers descriptions, you are in luck as we're staying there. It will be at the Eldridge Hotel again, in historic downtown Lawrence.

We already have a few speakers lined up, though we're not ready to announce them just yet. You can expect a similar mix of speakers from research, design and organizational disciplines talking about academic exploration, design theory and case studies of actual products.


We're not quite ready to accept registrations, but check back here or the slightly new Design for Mobile website. While you are waiting, please contribute to the mobile design patterns wiki we have recently moved over there.

one pitfall (or two) of always-aware mobiles

Tuesday, December 9th, 2008
I like to harp a lot about how a favorite feature of mobiles (and a thing that frustrates me about iPhone) is that they must be multitasking, and let a lot of services run in the background. And everyone around here likes concepts with awareness, like location-centric alarms – which need to run in the background in one way or another – to work.

And, I found some software that does neat stuff like this. I actually installed a bunch of location related software in the last few days and well... it's early. Some of the apps more or less don't work at all, and the rest are still a bit too hard to understand or use every day, or for less nerdy folks. But the future is clear and it'll be great soon enough. I have a half-dozen personal use cases for location based alarms.

Always-on GPS burning down my battery

A few days later I started noticing the N95s battery wouldn't last a whole day. Besides all the installing and playing , I have been doing a lot of testing for [a piece of client software] that I designed, so it was not surprising to burn down the battery. But then there was a weekend and it kept doing it.

Eventually, it occurred to me that it was one of those GPS items. I finally discovered how to turn off the always-on location awareness in the background, and it's fine. Yup, the GPS uses 3x as much power as usual.


Now, you could go ahead and take this to mean that it's not a good idea after all to run awareness software, or to run anything in the background (so the iPhone is right!), but I say these are totally surmountable instead, and addressing it head on is the only way to improve things. There are actually two problems, which both need (and probably already have) solutions:

  1. Awareness   I installed them and am pretty aware of this technology, and it took me several days to figure out why my battery was dying. The problem is that there is no way to tell what is running in the background. The paradigm of always-on services is not different from current desktops, but the battery-powered, restricted processor and memory environment makes this more important on mobiles. The S60s running-apps list is something I have learned to rely on; I want to see a similar list of background processes, and a single way to turn them off, both for now, and forever.
  2. Power management   Newer dedicated GPS devices can last almost 24 hours of on time. Sure, it has no radio and data processing, but they are using less exciting batteries, a large screen and can do this while running several "applications" at once (not to mention they get better reception than phones, and are spending a lot more power on DSP and other signal eeking). Running GPS-centric nav software will run down my phone in around 4 hours. Clearly there's a problem here of power management.

    Now, the awareness products I was using went about twice as long, so there's something to be said for background process efficiency, but i suspect additional cheats would be easy. What about using tower ID (and maybe accelerometers) and only go turn on the GPS when the user is overtly moving? Then only poll the GPS for position only as needed. If nowhere near a location with an alarm, and moving slowly, check every minute or two. Faster and closer, check more often.

I can't wait to see even more stuff like this, and hope no one else gets scared off by all these challenges.

UX discussion at Off-Deck Mobile Content

Tuesday, December 9th, 2008

GoMoNews published a transcript of the user experience panel at Off-Deck Mobile Content, featuring both Scott Weiss (now of Human Factors International) and myself.

Beyond just the topic of the panel, there are some minor implications of off-deck site and application design. How does UX design differ for off-deck versus on-deck? Obviously in the distribution method. For now, you can assume a higher degree of expertise for off-deck users, just because finding the application or website can be tough. But what else?

On-deck applications generally must follow operator guidelines. This means that to get on the deck, you must support all the devices accessing the deck. There are some third-party content stores for which this is not true, but it is currently true for all the operators I know of. However, expect savvy operators to start shifting this.

I think that more users are getting “smart” phones – our best definition is “voice+data communications device with an operating system whose name is used in the marketing of the device”. It’s not that the Java phones couldn’t download applications, but that lots of people could not find the application once downloaded. They didn’t see a way to download applications without going deep into a content store. So applications weren’t downloaded. So people are getting the smart phones, some with an intent to do more web browsing and applications, despite the fact that they could have done it before.

As a result, more and more devices accessing the web are smart devices, whose users have increasing expectations. This in turn makes off-deck content and downloaded applications easier to get to.

As off-deck content becomes more mainstream, content providers will have to really start thinking about usability issues. No longer can we expect reasonably savvy users (not that we could before); now we must design for users who want “that www phone”. (actual customer request of an AT&T sales representative, courtesy of Debi Jones)

Take Gmail, for an off-deck example. Their recent upgrade added two nice features: multiple account support and offline access. But the offline access comes at a high price: you have to remember to refresh your inbox before messages actually get deleted or archived. Otherwise you have to manage the messages you’ve already processed back on your computer. In general, despite wanting offline mode and access to two accounts, I’d rather go back to the previous version. Maybe I could convince two copies of the application to run on my device.

Oh, and the only way I’ve found to tell the program to refresh is by going to the inbox again. But this doesn’t fully work.

Is Google losing customers based on its more complex design? Probably not, but then again it is counter to their brand aspirations; too much of this and they will erode their brand. And you? You probably don’t have Google’s technology brand devotion; you’ll need to do a better job.

we’ve been animated!

Monday, December 8th, 2008

animation of first two chapters of Designing the Mobile User Experience
I just found an educational animation project in which four interaction design students animated the first two chapters of my book, Designing the Mobile User Experience (buy now). Their goal was to help students new to user experience, and I think they did a great job.

See the video; it’s fun. Comment there, or on Joel’s or Niek’s blog entries.

Credits: Joel Laumans, Niek Dekker, Lemmy-Boy Hoogendoorn, and Gemma Vernooij.

mobile analytics

Thursday, December 4th, 2008

In the past year, I've gotten more interested in analytics for mobile sites and applications. To better understand it, I've looked at a few packages, spoken with a few vendors, listened to several presentations, and listened to several web site owners.


Desktop analytics don't translate well to mobile

Nobody with a mobile site is happy with using Google Analytics.

  • Google (and many others) rely on Javascript, which works on a very small percent of phones
  • Google (and many others) rely on cookies, which have highly variable support.
  • Desktop analytics do not report operators.
  • Desktop analytics do not report interaction type.
  • Desktop analytics may not distinguish mobile Safari from desktop Safari.
  • Google (and many others) do not collect screen sizes in a usable fashion.
  • Desktop analytics do no reporting of transcoders, nor do they report users of "keyhole browsers" at their proper screen size.

For example, our site's analytics report that less than 1% of our visitors are mobile browsers, but nearly 8% of our visitors don't have Javascript. If I carefully add up the screen resolutions that look mobile to me, around 2% are mobile. Given the fact that the vast majority of our readers are technically very savvy, and we have a much higher Firefox use rate than the typical site (just shy of 50%), I think that those 8% of non-Java browsers are actually mobile.

So I'm losing around 75% of the information I need.

I think.


Desktop analytics vendors don't understand mobile

Every once in a while, a "full" analytics firm will call and try to sell me on their services for us or our clients. I quiz the sales person, who ends up bringing in somebody from their technical staff (which is actually better than most people who try to sell us stuff). It turns out most vendors don't even realize that the mobiles aren't being picked up in this data. In general it will be safer to go with a mobile specialist.


Free mobile analytics packages are partly there

Mobile ad networks like Bango and Admob have analytical tools built into their platforms. They are there to make ad graphic presentation easier by detecting operator and screen size. But there's no reason these tools can't help you answer questions like "is it time to make a touch version?"


Applications are harder to measure

Most packages don't have easy tools to insert code into your application, and managing impressions versus image downloads may be tricky. If you serve data to an application, think about what you absolutely have to gather, and see what you can divine from customers hitting your server periodically; you won't get click by click data, but you can get a surprising amount of info from it. And definitely look into a source like Flurry to help out.


What should you look to get reported in your analytics package?

  1. Operator
  2. Device type
  3. Device description interaction – be able to run reports based on video support, interaction mechanism, screen size, script support, and more. Not just screen size and browser type.
  4. Standard analytics, like connection speed, geographical area, and so forth

Don't give in. Consider little cheats like one-pixel images (called from your server) or other multiple-prong approaches for collecting data.

Good analytics will help you make better decisions about product strategy as well as advertising.

what convergence?

Monday, December 1st, 2008

I have spent a fair bit of my time navigating. I've climbed mountains and hiked through wilderness for weeks with nothing but a compass and a map. I even teach navigation to ROTC cadets periodically.

N95 with Nokia Sports Tracker disagreeing with a Garmin GPS60

When I finally succumbed to the GPS, I did some research but was overall pleased that – at least for the top brands – they abide by navigational standards. So they integrate nicely into the whole system. Which, with their propensity for minor failures, is a good thing.

For close to ten years I've been waiting for convergence to bring me a GPS in a phone. And for much of that time, after peripherally working on some of the systems myself, I've been instead waiting on a useful GPS in a phone. The N95, being a great device and noted as being good for GPS, made me excited about this again.

We've griped before about how location is not just GPS and maps (you can use towers, and use the data to make other services more contextual). But what I still find is that a GPS receiver still does not make a useful GPS unit in a phone. Sure, you get maps, but there are a stack of things that are just wrong with it. At least for someone like me.


Depending on how broken down I am, I run a couple times a week. And I use my Garmin GPS60 to track the time and distance, and tell where I am if I get lost. So this has been a baseline "useful GPS" test for some time. I did finally determine Nokia offers their Sports Tracker (although it's beta, so is not officially supported on many devices) which seemed to give speed, altitude, distance counters and so on so it might replicate the functions. So I took the phone for a run and tried it.

And it was pretty painful. Most of the experience was significantly sub-optimal, but let me try a few examples.

Where's the path?

Sports Tracker has no map. I mean, it has a path chart, sorta like older non-mapping GPS units, but there's no map data overlaid there. Maybe I was missing something, but it sure was easy to miss then.

So I tried Nokia Maps and Google Maps for Mobile. These all do, thankfully, run at the same time, so I was able to switch around between them to see what was happening. They still didn't help. I could tell where I was, but there was no track. The track on a GPS unit is a little dotted (usually) line showing where you've been. I like to keep them for years, so I can tell where the turnoff is to an obscure scenic outlook, and so on. For a local run, they have the same use. I can see old tracks and tell where the good (or bad) routes are, and I can backtrack if I went the wrong way.

This is a key feature for a GPS navigator, which is essentially entirely missing.

You are heading "right"

Standalone GPS units, and I guess mobile phone mapping software when route tracking, orient the map to your direction of travel. This is taken from real life, where a good way to walk around in the woods is to orient the map to your direction of travel; things ahead of you in the world are ahead of you in the map.

Orienting maps to the real world helps with mental models. It's called "mapping" even when no maps are involved; light switches should be "mapped" to their actual locations by relative location and orientation on the panel, and so on.

Disregarding Sports Tracker, which has no useful map (and if it did, it is still tiny) the two map nav programs I used orient north-as-up. Always. Again, I tried a lot of settings, but could not get them to switch over unless (sometimes) I was in route-following mode. And that was useless for two reasons: 1) route mode seems to insist on displaying in a cute 3D display, so the map is not really readable, and 2) I don't want to run a pre-planned route. I'd rather use paper.

Advantage: Garmin. They do indeed orient the maps north-as-up when you zoom out far enough (around the time the state takes up the whole screen). Below that, they automatically orient up as direction of travel. And there's no way to change this, because it's the right thing to do.

Waypoints, units and accuracy

There are three other features I use all the time on a GPS. The first is location. I very often want to know my actual location. Not as a point on a map, but as coordinates. Now, Sports Tracker does have this, but... not very usefully. For a lot of reasons I don't like lat/long (I use MGRS or UTM, and if you ask I'll tell you why) but even within lat/long, there are several ways to communicate it. DD.ddddd is only one of them; not being able to change it means I cannot really communicate with other nav devices.

An absolutely critical feature of every GPS is setting waypoints. You can do it before the trip to plan it, or do it on the fly. "Hey, a place that sells honey!" (this is real), then you mark it, label it at your convenience, etc. Absolutely no such feature seems to exist on any software I can find for any mobile. Yes, I should mention that Garmin and some others do offer software for mobiles, but it's so expensive that you can buy a cheap piece of actual hardware, so I don't know anyone who has it. I also just got to poke around with Sprint's navigator solution on a new Blackberry, and it has a sort of waypoint feature, but assigns a street address to each saved point; a sort of odd solution, that also misses the point of the coordinate systems above.

And lastly, there is another issue that is dear to my heart, precision and accuracy. Here, everyone is at some fault. GPS, like most electronic devices, implies great accuracy due to its display of data very precisely. But this is not true; only so much accuracy is available, and sometimes this is shown, but not robustly enough to me.

The Garmin unit, and some of the mobile phone software I have used has a precision circle, but all of it puts a very precise-looking center point, and (when available) displays coordinate location to many decimal places. I have been driving while others navigated incorrectly because a GPS (or more often, a phone) said we were a block, or a quarter mile, to the left. These devices need to work on ways to better visually imply they only have a certain amount of accuracy, and help avoid such use errors.

Location precision examples

Read another blog post where I gripe about many of these same issues.

Datum and trust

I ran with both the GPS60 and the N95 running Sports Tracker on a couple of runs. At the end of the run I encountered one of my biggest concerns about this: they disagreed. See the image at the top of the posting. How is this possible? Well, I have some ideas, but they relate some to the issues with data above. There is no way to set (or even see) which datum is being used. This can mess with position indication, and position calculation. Sure, most users won't want to mess with it, but if the data is wrong, shouldn't there be some settings to let you try to fix it?


I want to be clear that I'm not hating on Nokia, or Google, or any specific product. In fact, these are finally good enough they are worth this sort of use and review. I don't even want to talk about trying a couple years ago to get a Nextel GPS to display useful data on the device. But this seems to be typical of far too many products that get "improved," or integrated (say, into mobiles). Core functions get lost or modified just a little, but enough to make them a lot less useful.

And I'd maybe gripe about how this could be fixed, but I do have hope it might get better on it's own. Camera phones used to be universally comically bad, but I might have bought my last point-and-shoot camera. Our current devices all have cameras as good as, and with more storage and easier transfer, than most standalone devices. Maybe I just need to wait another generation or two to see GPS – and other convergence features – that work in really useful ways. Or maybe they will always stay like this, as consumer driving navigators, and like my DSLR is the serious camera, standalone GPS will always be the serious navigator.