public, mobile, transport

30 April 2010, 18:27

This week I was at a mobile applications workshop, organised by a customer of ours, the VBB. The VBB is the umbrella organisation for public transport here in Berlin and the surrounding federal state, Brandenburg.

Present at the workshop were public transport authorities and information services from across Europe. The buzz was solidly about iPhone apps, android apps, any mobile apps for—you guessed it—public transport information. Justus Brown from Nokia maps was there to show their latest effort in walking routing and to evangelise the integration of public transport information.

The VBB had asked me to deliver a talk ‘related to usability’ within the context of the day. So I shared some insights from my 13 years in mobile user interaction.

this is not a big pipe

Guesstimating that most of my audience was working on mobile apps coming from a desktop (web) background, I kicked off my talk by explaining that mobile is not a shrunk desktop. Let’s investigate the reasons:

UI output
Yep, small screens. But beyond how little one can fit at any given moment, it is about low bandwidth: how little communication can be passed over a given amount of time. Besides that, scrolling mobile screens is simply no fun.
UI input
Rigid cursor movement with the cursor keys, a cramped experience. Text input is of variable quality, from the simple dial pad to too‐generous‐by‐half qwerty keyboards. Again, low bandwidth.
on the move
But much more of a game changer is the mobile factor. The fact that a mobile can be used anytime, anyplace makes the current location (when available to the mobile software) and the moment of now! the right default for tens of percent of use for, say, a public transport routing query.

And now we have moved from trivial nuts and bolts to the totally different vibe in which mobile app interaction design should be performed: a sense of urgency, of life on the move.

you can’t touch this

Shifting up a gear, I moved on to the topic of touch devices, iPhone + co. As I argued years ago, when the iPhone was just a green sprout, touch is not mobile. I can add today: neither is it a shrunk desktop. Again, the reasons:

UI output
Compared to mobiles, there are quite a bit more pixels on touch devices. But watch that resolution: the display is not that much bigger when measured in centimetres. Scrolling is not only more fun, it is a pleasure. This has to do with how stroking a touchscreen is so much more satisfying than poking at it. Still, that pleasure has its limits. Immediate visibility without the need to scroll rules.
UI input
Touch sports random input access, so the cramp of mobiles is gone. Also the hallmark of true touch interfaces is the absence of Options menus: everything is done on the screen, making for an immersive experience. But there are inputs limits: the ‘average’ fingertip size dictates the minimum sizes of touchable items on the screen. And that, and the ups and downs of touchscreen text typing, set it apart again from desktop experiences.
the urgency, of life on the move
Yes, touch devices have the full mobile factor. But just as you think that tips the balance solidly towards being a mobile device, you have to factor in that touch devices are pocket computers that happen to be making cellular calls.

And with that we are straight back in limbo. The solution is to stop talking about mobile or desktop and respect the touch platform for what it is. Just as mobile application interaction has to be designed from ground up, touch applications have to be—by forgetting about everything one knows about desktop or mobile.

really real‐time?

I continued my talk with some general guidelines for interaction design, e.g. you are not ‘the user’ or nice data, but what about solutions? In this blog post I want to focus on one of them: be transparent.

A good portion of the mobile workshop was spent on real‐time updates—busses being late, interruption of rail service, etc.—being shown at stations, stops, on websites, mobiles and touch devices. An example of this was discussed and it boasts a pretty impressive response time, from measurement on a vehicle to consumers being informed.

But then it turned out that the system still depends on humans passing messages. This exactly breaks down when the stress starts, as delays get serious. Also some transport services report much faster than others. And when last winter a massive amount of snow shut down the rail service, the ‘real‐time updates’ kept showing trains arriving at stations. Final nail in the coffin: users on twitter inform faster about delays then the public transport system itself.

really transparent

Here is where the ‘be transparent’ guideline comes in. Because users of this service sense that the information is ‘real‐time,’ they expect it always to reflect the situation of now! and we have seen above that this is not the case. This discrepancy between representation (promise) and delivered service cannot be.

‘Be transparent’ demands that either the real‐time updates are made to be as instant, correct and free of human failing as promised by their representation (i.e. a serious redesign of the chain of the systems delivering the info) or the representation at stations, stops, on websites, mobiles and touch devices gets redesigned to reflect that the service is not really always ‘real‑time.’

You have to go all the way. There is no compromised middle ground in this.

private vision

I closed off my talk with a vision for the (near) future. It involves travelling with a mobile device on public transport. The route you are taking is known and on what exact bus/tram/train you are right now (that takes a small beacon). The public transport service has good real‐time data and sees that your bus connection is going haywire.

At this moment the public transport service could re‑route you and send your mobile updated instructions: at what stop to change and to which line. This could be really cool for commuters who get to know every little hiccup of their daily service after a while.

meanwhile…

The vision above can also be seen as one big privacy nightmare. The solution for this conundrum is control. By putting users fully in control, they get empowered to deal with it as they perceive it: as a great benefit or a privacy issue. This means in practice that users have to opt in first before a service is available to them. So no google buzz fiasco: shoot first and let them opt out later.

Labels: , , ,

PS logo

0 comments · post a comment

If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.

portrait of Peter  Peter Sikking is an experienced
interaction architect. He unabashedly puts shipping great products at the centre of his design practice. He is known for his work for Google, Nokia, the Metapolator & GIMP open source projects, and startups.

Peter teaches, mentors, lectures and publishes. He enjoys working with small teams in an international setting, but also the fact that his work can be found on half a billion mobiles and creates billion‐dollar revenues.

What is Peter up to? See his /now page.

get in touch: email · twitter · g+ · linkedin · xing