Android being open-source, there's probably an expectation from Google for the community to provide a range of solutions to a 'boring/inconsistent/shit UI' problem, be it through providing boilerplate code or UI component libraries or whatever.
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.
> Android UI design is easier coz it's XML so you can do it programmatically!
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.
Comments
Android being open-source, there's probably an expectation from Google for the community to provide a range of solutions to a 'boring/inconsistent/shit UI' problem, be it through providing boilerplate code or UI component libraries or whatever.
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.
> Android UI design is easier coz it's XML so you can do it programmatically!
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.