Moreover, the fact that you use non-standard UI does not necessarily imply that the user has to learn a new interaction paradigm.
Users are forced to return to figuring everything out as they go, and then start over again at square for the next website. Visual cues are frequently sacrificed for the visual mess someone called a "design". For people highly familiar with native widgets, they just can't navigate around as easily in a webapp as they can in a first-class gui citizen. Not only because everything is different, but because the extended functionality that comes baked into real toolkits just isn't present in the web reimplementation. Things like the history api are even further eroding what assumptions can be made about gui behavior on the web.
Yes, many Android apps looks bad (a lot of them appeared in the beginning of Android, made by hackers that dont care about design or poorly ported from other platforms) but this is not the case anymore.
So what iOS apps in your experience have "ugly" Android equivalents?
Apple. They spent the time to "get it right" with iOS, and when Android came along they had to settle for second best in most areas to avoid looking like an iOS clone.
If you want examples of how well Android can look try the MIUI rom. These guys built mostly everything from scratch to create a pleasant, unified look (contacts, phone, messaging, browser, music player etc. and they all are best Android apps I've seen). Sadly, it does look much like what would Apple do.
Disclaimer: not a fanboy, I have both, iOS and Android powered devices and I actually develop on them both.
Consumer apps used to compete on functionality - now everyone can mostly do that part.
Design (both graphic and interaction) is where companies will compete for consumers.
Bump has needed a TON of help in the past and even does tdoay (even with their iphone app, http://www.iwebsnacks.com/wp-content/uploads/2011/02/Bump-2....).
Please - start with a new logo.
Then, when they have solved the problem, why not put it in the Market.
Any Android App can look great. It's just a matter of taking the time to make it so.
Not to say I don't appreciate beautiful UI design, but I think there's room for beautiful apps and ugly but functional apps.
I'm going to say though that if anything is at fault, it's not necessarily the learning curve but the base assumption of expert knowledge applied to every bit of documentation Google produces.
For a purely technical piece of writing they'd win many awards, because they can get down to the nitty gritty for sure. To the guy who's new to it all who wants somewhere to start, he's fucked. It's documentation for people who already understand it (personal experience: the C2DM doc, maps API, their PHP library that makes it harder to use their APIs than rolling your own code, etc.).
So thanks to that those fabled UI solutions turn up in the form of PhoneGap, jQuery Mobile, Sencha Touch, etc. All of which abstract the concept of app development to merely be a case of designing a website for a small screen. With HTML and JS and CSS. (Of course the other reason is platform agnosticism but application homogeneity is another thread entirely.)
And, thanks to the point raised in the article ('Android UI design is easier coz it's XML so you can do it programmatically!'), the people who do know how to create an app are the developers who may or may not be very good at working the UX side of things and may settle for the utilitarian solution.
That is absolutely not the point raised in the article. XML based declarative UIs help to keep your view code separate from the application's logic allowing for faster iterations. I don't think anyone manipulates XML views in code except in corner cases.
The simplest way to get a big picture idea about Android's XML based UI is to think of them as HTML+CSS with the addition of good layout managers.
However, a purely native approach (without titanium or phonegap for example) still has many issues in developing well structured UI.
It is clear however, that BUMP's application, while better than their previous design, does lack something. Android design is not particularly easy and I personally think that the various screens, disparate versions of the OS, and capabilities of the phones make development that much more complex. In a very real sense we need UI testing that automates this as much as possible. It really is too much work.
Still I think that there are UI frameworks coming out for Android that will alleviate all this complexity and allow us to build consistently well designed apps. Just not right now.
Clearly, this post was posted by the resident Android dev. :)
1. UIKit - Apple made it easy for developers to implement consistent navigation, views, and transitions. Android Ice Cream Sandwich is providing a new UI library which will bring this much needed iOS advantage to Android. Is it possible to mimic UIKit on the current Android devices? Yes, but it's a pain in the ass and not practical for most developers on a deadline.
2. Fragmentation - Device Android version lock has caused problems with development. You are only as strong as your weakest link which unfortunately rings true with some developers who choose to develop on an older version of Android to remain compatible with as many devices as possible. Google has addressed this issue by obtaining agreements from many manufacturers to update their devices on a consistent basis.
3. Screen Resolution - Any web developer will tell you it's much easier to create a beautiful and consistent website if the site is fixed width. This is especially true for mobile development because you dont have to concern yourself with repeating tiles, resolution detection, and adjustable spacing when you know the exact dimensions of the device. There are only 2 iOS resolutions (not counting retina) making it easy to utilize space and perfect the UI in the most efficient way possible. Can it be done on Android? Sure, but without a UIKit to handle many of the little nuances it will yet again be a big pain in the ass and will take up time that the developer does not have.
