Meebo IM client on Android (left) versus iOS (right)
The debate over why the same apps available on iOS are less pretty – and, arguably, less usable – on Android has finally gotten its whistleblower.
Nikolai Sander, CEO of EODSoft, writing on the blog Android Gripes, gave this insider’s perspective on the workings of Androids User Interface API:
I just recently ported one of my apps to the android platform and was shocked when I learned the User Interface API. It is the worst UI library I have ever worked with (and I have worked with quite a few)! I would even go so far as calling it amateurish. It looks like it was designed by at least 3 to 4 different people without common design guidelines. The naming conventions are inconsistent and the static nature of declaring the UI in xml files might work for the web but for a dedicated device interface it’s a nightmare. This along with the fragmentation of devices (mainly different resolutions) it is close to impossible to create a nice UI on Android devices.
Aside from its cute holiday-themed logos, Google has never been known for its design savvy. Indeed, the entirely data-driven company seems to have side-stepped the issue on its flagship site by avoiding it at all costs. That’s kept the company’s search engine free of clutter, but search remains a fairly straightforward design problem at the display level. In Android, however, the lack of polish is finally hurting the company: Good design isn’t just about making things aesthetically pleasing, after all, it’s also about making them functional.
Aside: Android’s failure in this department doesn’t explain Apple’s success
To understand why Apple is so good at user interface APIs, one need only look at Apple’s long, long history with creating an API for a very different sort of operating system – OS X. Even before there was an OS X, back in the days of System 6, 7, 8 and 9, Apple worked very hard to give its application developers a standard set of tools for doing everything from displaying windows to rendering buttons.
Indeed, Apple’s current Cocoa application programming interface makes building apps for OS X easier by automating portions of the development – precisely so that every app on a Mac follow’s Apple’s human interface guidelines.
This is where Steve Jobs’ fanatical devotion to usability really shines. On the one hand, the results are uniform. It’s like the old Model T – you can get an iPhone or OS X app in whatever color you like, as long as it’s black – i.e., Jobs-approved.
Dealing with screens of every possible size
Of course, a second issue with development for Android is the maddening array of potential device resolutions. Whereas iOS apps only have to work in basically two resolutions – original iPhone and iPad / iPhone 4, Android apps must accommodate many.
I wouldn’t blame the developers or designers of the apps for the bad UI. After all most of them wrote the iPhone version first and they sure have all the assets (bitmaps etc.) available but in most cases I assume that they got so frustrated with the UI SDK on the Android that they decided to create a simpler one in order to not waste too much time. I know I have. Trying to get the UI look right on the Android platform is a trial and error process and with trial I mean “you try it on all possible device resolutions and encounter mostly errors”. On the iPhone, you just build it in Interface Builder for 2 resolutions (320x480 and retina, which is almost identical to the iPad) and you’re done.
And here’s what all those device resolutions look like, courtesy of Nick at AnIdea:
Screen resolutions of popular Android phones
Developing for such a wide array of device screen sizes and aspect rations means that not only is it impossible to create pixel-perfect designs for Android interfaces, there isn’t even any guarantee that a given interface can be scaled to fit a particular screen. That makes developing for Android devices more like designing web pages than designing an application interface. A challenge of this scale demands the best user interface library Google could possibly provide – yet the opposite appears to be true.