In 2000, after having worked for about a year as the UI designer and coder for what was then called the Nokia WAP Toolkit, I attended, probably on Nokia's dime but paying for my own flight, the CHI 2000 conference in The Hague, specifically a tutorial on designing mobile interfaces. And I swear, this story will become relevant to 2008 by the end of this entry. Smartphones barely existed if at all, Palm had just won over Newton, and a color screen on a phone was a rarirty. You had 5 lines in b&w at most, two soft keys, and no memory or processing power to speak of. The first WAP standards had just been released, standards for files and formats and markup and scripting languages that large mobile phone manufacturers were in the process of making browsers for. It was being sold as The Web On Your Mobile, which was a huge marketing mistake, because what the companies meant was "Now you can browse data from site to site just like you do on the WWW" and what consumer were hearing was "Now you can get the WWW on your phone", and designers making mobile sites were stuck in the middle.
The tutorial was a bit of a mismatch between what the audience wanted and the presenters were prepared for. The presenters wanted to give a tutorial on a high level, all about how mobile users didn't look at screens on their mobile like they do on the web, how they are walking or driving and easily distracted, how they usually use just one hand to manage a phone, design for context, pare down your service to the mobile essentials. The web people taking the tutorial wanted to know how the hell to get their 3-column table-based web pages for their banks and news organizations and shopping companies onto the phone. Bit of a mismatch. It didn't go well.
At one point I had identified myself to the class as the front-end designer of the Toolkit that they most likely would be using once they were back at work to make and test these sites, which means that questions also started being asked of me. We were telling them no, focus on information, on what you want to tell the user, on how it fits in their mobile life. The designers of course were tasked to not just deliver information, but to deliver an experience: banks want to look like banks, like their own brand of bank, shopping sites want to entice you to shop in their way and hope you find the experience better so you come back and not go to other shopping sites.
They wanted to know what screen resolutions were, we told them WAP did not set a standard for that, but that WAP browsers would take the site files and translate them to make sense. They wanted to know how many lines of text there would be, we told them WAP might run voice only (seriously, we thought it might). They wanted to know how many soft keys to design for and how to enter text, we answered that WAP might end up being shown on pagers (seriously, we thought.. yeah). WAP wasn't like HTML, WAP was really abstract: you kind of defined your actions and lines and the browser specific to the device would translate it to make sense. Two designers actually came to me with their notebooks asking what the code was to put a text field inline, and I had to tell them, no, you are going to define a text entry marker here, and then when the user gets to it, the phone will most likely open a sub-screen for the user to enter text in, and every phone has their own way of doing that text-entry and you have no control over it, because WAP wants to make a site feel like it is part of the phone, using constructs native to the phone. It took some time to get this through to the designers: this was not the web as they knew it, and they didn't like it at all, at all. But to fit a browser into those phones a lot of concessions had to be made.
But they weren't just concessions to technology, they were mostly concessions to politics, to the fact that WAP (later OMA) was a consortium of equals, and nobody was going to tell Nokia and Ericsson and Motorola that they would have to standardize on 6 lines of text, a soft key, one center joystick, or something that prescriptive for their handsets in order to display the mobile Web. No way no how, so WAP had to be a set of standards defined to work on all kinds of devices, scaling up and down, and thus giving everyone who actually had to make stuff that went across phones and devices real headaches and hives. Meanwhile, the Japanese mobile Web, iMode, was cleaning up like crazy, making tons of money, because NTT Docomo, the operator that owned Japan, basically dictated to the equipment makers that an iMode phone would have 5 lines, two soft keys, these screen colors, these graphic capabilities, etc, or N-Do would simply not sell their phones. All Japanese manufacturers complied, NTT Docomo plowed massive amounts of money on making services for consumers, designers knew what to design and how it would look, and Japanese consumers spent money by the brickload buying horoscopes and cute characters and checking their bank accounts. That and it wasn't sold as The Web on Your Mobile, but as a new add-on data service, so expectations were managed. But it delivered. WAP never did because, having to fit too many things, when the code met the glass, the resulting experience of this abstract site interpreted by the device browser never fit that specific phone the user was holding well. Plus it was buggy and data was expensive. WAP then added standards so the site servers could sniff what kind of phone was talking to them, but by then the infrastructure was so complicated the whole thing just collapsed. And seriously, now the site user had to code for every phone screen size out there?
If you want a platform, you have to frickin design a platform, not an idea of a platform. Jave ME has the same problem these days of running on too many devices differently, to the point that again, developers end up having to make special versions, not releasing for certain devices, and having to test every program on 168 phones, each with their own bugs in how they implement the runtime. This is an unhappy experience as a developer: you are sold a bill of goods of write once but a reality of rewrite many, run selectively.
I am seeing the same in Android, Google's phone environment they are licensing for free to handset manufacturers. Google's not proscribing. Google's not committing. They have an Software Development Kit [SDK] so developers can make and preview applications, just like the Nokia WAP Toolkit (later Nokia Mobile Internet Toolkit) was. The Android SDK comes with an emulator, just like the WAP Toolkit did. The Android documentation uses waffle words about this emulator like "The Android emulator mimics all of the typical hardware and software features of a typical mobile device" just like the WAP Toolkit tried to make very clear with our first emulator, delivered before any phones on the market actually had a WAP browser, that really, this was just a simulation on your computer screen and not an actual phone. Marketing made us jump through hoops to take off branding and not use an actual picture of a shipping Nokia phone lest we mislead consumers that the WAP handset Nokia would ship would be just like our example WAP browser, to the point we made a phone skin for our emulator that included the words "Not Actual Product" or something like that. (Then I commissioned the Blueprint skin, and all other kids of shenanigans.)
Developers are making programs for the Android. Google organized a contest and gave money to what they thought were the best ideas. Screenshots are out. Much labor has been spent. All these developers know about the hardware is based on the emulator Google released with the SDK, not actual hardware. HTC will make the first Android phone, but, like WAP, Google is saying the Android environment will run on many kinds of hardware: some with multi-touch, some single touch, some with stylus, and some with no touch at all. Google has been showing off all kinds of Android form factors: some look like iPhones, some like Blackberrys.
Apple is very prescriptive: an iPhone app is this and that big. It runs on an iPhone and it has multi-touch and this kind of screen. It has these fonts, and this kind of rendering. There is only one model right now, and it can show this many lines on the screen. (Of course, Apple makes its own phones.)
Android does have the advantage that WAP did not have (by design): an Android app can ask the phone how big it its screen is, and reconfigure itself. But let me tell you, for the visual designers that is going to be loads of butthurt. If you are trying to create a dashboard of essential mobile data, a one-glance no-scrolling view upon your life, designers need to use every pixel. And having to make these kinds of layouts when sometimes you have 300 pixels for height and sometimes 320 is close to impossible. They will go to their Project Managers and aks "What's the smallest screen we are targeting?" and design for that and the larger screens are going to be underused. Good god, just making a custom wallpaper is impossible.
I've seen this happen, people. I know how actual real development shops navigate these problems. There's going to be an awful lot of second-tier Android devices where the user experience is sub-optimal because developers are targeting the "average" Android device, the one with the largest installed base, and these developers will be wasting cycles, both programming as well as when the program actually runs, resising themselves to various sizes, while iPhone developers and apps just know. Look, if there were 3 or 4 screen sizes, things will be manageable. But if Android takes off like Google wants and gets thrown into all kinds of form factors, the platform, as far as developers are concerned, by design necessity, will be fractured into pieces, and not be this one vast marketplace. I've seen it before, and cost an awful lot of wasted money.