« JAMDAT Soup | Main | How Many Pieces In A Google Pi? »

August 17, 2005

Inferior Bathroom Technology and UI In The Mobile Space

I am thinking about UI lately, and because of this, I am noticing all of the things with really bad user interfaces that could be greatly improved with a new approach. Particularly, I am noticing things that probably work well in the test environment, but fail miserably in real-world deployment.

My next company
I you want to be a kajillionaire, make an automatic sensor for restrooms that actually works. I travel a lot, and the thing that most detracts from the enjoyability of my trips is inferior bathroom technology. Automatic sensors are used to flush the toilets, operate the faucets and dispense the paper towels. NONE of them work well. You enter the stall and put the little paper gasket thing on the toilet seat, then when you stand up to undo your belt, the damn thing flushes and takes the little paper thing away. You might figure out how to fake out the sensor, but probably not and then it won't flush when you actually want it to so you end up pushing the manual override button. Then you want to wash your hands. You put your hands under the faucet, and…nothing. You wave your hands a bit, then something! Then nothing. More hand waving. A small ration of water vomits onto your hands. Then you see everyone else, down a line of twenty sinks, doing the same thing with looks of mild frustration on their faces. After that maddening experience, you have to wave your hand in front of the paper towel dispenser and it dispenses ONE piece of paper, which is insufficient, but when you wave your hand again, nothing. Wait five seconds, wave your hand again, then one more piece of paper. A queue of people builds up behind you. Out of the corner of your eye you see a guy quickly walk out with wet hands, wiping them on his suit pants.

To me, airports are for rushing through, and the bathroom technology not only slows me down, but it adds indignity and frustration to the process. This is because it doesn’t quite work the way it might work in another environment like, say, the manufacturer’s showroom where they are using the product in a very different way. I don’t think any salespeople are actually demonstrating the auto-flushing toilets.

The mobile environment is like an airport bathroom – it requires a specific technology approach to accommodate a specific use case that is very different from your bathroom at home. The current technology meant to enable us, while nifty, actually slows us down.

Mobile applications are different
Mobile application development is constrained in ways that web development is not. The browser environment is relatively stabilized and robust now, whereas the mobile phone only recently could do anything but ring. There is no real “platform” - every handset is unique in its own beautiful way, often requiring reverse engineering to find workarounds. Last week, we discovered and reported manufacturer defects on five handsets and had to engineer creative ways to work around them. (How is it that we are the first to discover these things? Happens all the time.) For Rabble, we essentially maintain a different client codebase for each handset class ID, and often for each handset within a class ID.

Not only is it difficult to do, requiring technical domain expertise that not every hacker possesses, but the environment itself is different, requiring a fundamentally different approach to technology, architecture, presentation and most importantly, User Interface. Rabble has been in development for a year. Sounds like a long time for a blogging and social networking app, doesn’t it? How about cramming that app into a 200k payload, working around caching limitations which are all different across hundreds of supported handsets, overcoming network latency issues unheard of on the web and doing it all in a presentation environment that requires creative solutions to the problems that are among the easiest to solve on the web? Now do it with 1.5 inches or less of screen real estate in a way that is logical and useful for the consumer. The coding was done in a few months. It’s everything else that goes into bringing a product to market that takes time. This is the kind of time I wish the automatic bathroom flushing people would have spent.

Be careful if you think that your website is going to be relevant in the mobile space because you may be asking for disappointment. Your functionality might be very relevant, but your success will depend much on how you present that functionality to the consumer. You cannot effectively render a web page on a mobile device. The 18 inches of landscape point-and-click multi-purpose real estate you have on the web simply does not translate to the 1.5 inches of scroll-and-select single-purpose real estate you have on mobile devices. Oh, and session lengths are measured in seconds, not minutes or hours. Thinking that a user is going to fire up the browser on their mobile phone and get any real utility out of an application developed for the web is like providing inferior bathroom technology – you will slow them down and frustrate them to the point of losing a customer. Imagine viewing this site on a 1-inch screen.

I counted 158 things to click on. You cannot do “portal” in the mobile space.

Rules for mobile app development
I want to see more companies provide mobile applications, but I want to avoid the lameness of the internet bubble when you could go public with a “dog food service provider.” Just because you can make a mobile app doesn’t mean you should. Behold my contribution in this regard: Shawn Conahan’s Rules For Mobile Application Development…

Start with UI and work backwards. This is the era of single-purpose applications. They must be extremely well thought out, provide vertical functionality with minimal navigation options or requirements and still be visually compelling. Do not try to replicate an experience from somewhere else. If you can’t make it work with very small storyboard mocks, (we do ours at actual size to pass the “squint test”) then you may simply have an idea that won’t work in the mobile environment.

Consider the input device. DigitWireless' Fastap is going to help text input-based applications. The HipTop is even better, and possibly the coolest device in the mobile space. While you shouldn’t underestimate the amount of free time a teenage girl has to spend with her mobile phone, there is no reason to make life more difficult for her. The best mobile apps are built with the hardware in mind. (Rabble on the HipTop will be a great user experience.) Like bathroom technology engineers, many handset manufacturers aren’t thinking about the total use case of their handsets. Many manufacturers still don’t ship their devices with things like multiple keypress. This has implications if you are building a game which requires you to be able to move your spaceship and shoot at the same time. The Motorola T-720 was a big seller, but the soft keys don’t map to anything in BREW, making it a difficult handset to develop for. Keep these sorts of things in mind across the hundreds of handsets you will need to support.

Get mobile domain expertise. There are many web-based businesses that could be very successful in the mobile space if presented correctly. The most important presentation element to keep in mind is how mobility augments your functionality. Internet dating is cool, mobile dating with an LBS-based social networking proximity overlay (a cornerstone of the LMNO) is very cool, but it also changes your service from the web-based long session length “I want to meet Miss Right” to the mobile-based short session length “I want to meet Miss Right Now.” Not that there’s anything wrong with that. I am just pointing out that mobility changes things and may change what you think you have, so just be aware of it and think creatively.

Start with the basics. If you do these things and don’t consider whether your application is relevant or useful to the mobile consumer, you might fail anyway. Here are my five criteria for useful mobile applications. (All of our planned mobile applications must have at least four, but maybe you don’t think they are all that important for what you are doing. Time will tell.)
Successful mobile applications:
1) Are not just mobile relevant, but mobility relevant
2) Are personal or offer some form of personalization
3) Leverage the network effect of mobile connected devices
4) Originate in the mobile space
5) Utilize and extend the upstream capabilities of the mobile device (this could be as simple as texting and passive location or as involved as massively multi-user networked games.)

All of this boils down to a holistic approach to UI, which I believe is the cornerstone of mobile application development. I like short lists, but feel free to add more if you think I missed something important.

Posted by Shawn Conahan at August 17, 2005 09:45 AM

Comments

Posted by: Juan at August 19, 2005 08:01 AM

Post a comment

Name:

Email Address:

URL:
Remember Me? YesNo

Comments: (you may use HTML tags for style)