Design for mobility? Design for immediate action. 22:03 on Thursday
On my way back from lunch a guy stopped by in his car to ask directions. I didn’t know the street he was looking for, but in a true nerd-moment I thought “Hey, I can check that out on my mobile.” So, there we were, he parked on the sidewalk, me standing next to his Volvo launching Reittiopas in the S60 built-in browser of my N90.
For those who don’t know, Reittiopas is a guide to public transportation in Helsinki and around. Quite useful for getting directions and pointing out places on the map.
The emphasis here is on quite.
Navigating the service and scrolling and scrolling and scrolling the pages sloooowwwly took so much time the guy in the car got ready to leave. Yes, I was using the “pocket version” of Reittiopas, and yes, I had images turned off to speed things up. When I finally got to the page with the map and switched images on, nothing happened. No map. I tried repeatedly to click on the map to load it, only to be repeatedly told the connection timed out (that looked like a bug in the browser, actually).
Why didn’t I use a dedicated mapping service? Because I don’t have one in my bookmarks, and searching for mobile services on the fly is not an option.
So what is there to be learnt from this?
To get mobile apps from the “just killing time” category to the “useful” category, attention must be paid to immediacy. This is not (only) about loading times, but more about interface design. The one most important interface element must be immediately visible and available. If you provide search, put the search field first. If you provide maps, the map should come first, before any other active element. I’d say if you include a header before the important element, you’re only wasting precious pixels on that tiny screen.