> The other replies were mostly variations on the theme that Android users don’t pay for apps, they don’t have data plans, you can’t monetise them easily, and designers are all iPhone users and don’t really understand Android users … Socially, excluding Android users seems almost prejudicial. Unlike Android is difficult, this isn’t about about mere convenience; it’s a value judgment on who is worth designing for. Put uncharitably, the root issue is “Android users are poor”.
This position sells the opposing argument short. It's not so much "designers believe a priori that Android users won't pay for good design," it's "Android users have a long and well-established track record of not paying for good design." People are still experimenting, and I think that this is actually a case you can rely on market mechanisms to handle. If Android users start demonstrating a willingness to pay for good design commensurate with the difficulty of producing good design for Android devices, there'll be a market opportunity there. Someone will get rewarded for providing people with what they're willing to pay for.
This leads into how Bowles sells the other argument short: he conflates design and graphic design when he address the "Android is hard to design for" argument. Design is, to borrow a famous phrasing, how it works. Sure, it was tough to do good graphic design for Gingerbread and it's much easier now. Great. However, the fragmentation and glacially-slow upgrades have a real cost here - to design the same functionality, may require spanning multiple API versions. The comparison to the diversity of Web browsers and viewers doesn't work because that diversity, relies on web standards. The equivalent of web standards that would allow an Android app to do responsive design in the manner of a web app, devices don't have or respect.
Fundamentally, it seems like Bowles doesn't get that the answer to his question is "because doing good design work on Android is more expensive and people pay less for it." Sure, you could ask designers to make speculative investments in Android, but I suspect that'll go about as well as asking people to make speculative investments of their professional time and skill usually goes. Professionals who respect their own time and worth, go where they can do good work and get paid well for it. Currently, that means they don't go to Android.
You posted three links to the android documentation that don't address sedev's point at all.
Your first point doesn't address the "falling back gracefully" part. The second part of that example, the ActionBar, which was introduced in ICS, IIRC, only has a community shim. Granted if you want to use a new API that may not have as much community support as the ActionBar, you either code one yourself (strengthening the sedev's point that you have to design the same functionality across multiple versions).
Your second point is even more off base. With the web's responsive design, I have to make one HTML file, and one CSS file, and if my design is sane, it works across all screen sizes. Your second link requires you to hand code different layouts for every device size which is hardly a solution - infact you are back squarely where you started. And I'm unsure if you actually read those tutorials but they don't even seem to have been updated since eclair. IIRC, you only had to deal with 3 sizes then - ldpi, mdpi, and hdpi. I haven't done Android dev in a while, but I'm sure the number of layouts have tripled.
If you really want to counter sedev's point, you should point to an app with the relevant code that actually does what sedev is talking about and not some links to the documentation. Everyone is already aware of the documentation, and if it actually worked as you said it did, we would not be having this conversation.
As RyanZAG explained, your multiple layout files should only re-organize fragments.
Yes Android dev is hard, with multiple versions, sizes, formats and bugs. But there is documentation, tools and example to adress them. Deal with it.
If you are willing to try again, as so many things have changed since Eclair, you can have a look at this exemple where you will see how you can use new API and a fallback when they are not available: http://code.google.com/p/android-protips-location/source/bro...
You just make your app out of fragments and then use different layouts based on screen size to arrange your fragments. It's pretty straight forward and really not the problem. For general reactive design like on websites, you can just set up your layout in XML to grow correctly to fit the screen, which is something it does by default.
The real problem is that Android very heavily links layout with function. In HTML-land, a designer who knows a bit of html and css can happily redesign the layout of the page. In iOS-land, a designer can use UIBuilder to redesign the layout of the page as well (they usually break it too by dragging stuff inside other stuff, but it's visual and generally fixable). In Android, redesigning the layout of an app is generally very complex and nearly always requires major code changes because of how fragments are forced to interact through the activity god object.
I do not know how graceful falling back is in web development, but there are some non-graceful holes in what can be accomplished with Android compatibility libraries
The biggest design-impacting issues I've encountered are the absence of expandable or interactive notifications pre 4.1 and limitations in styling/visualizing list selection states pre 3.0
Perfect, I think that's the answer in one sentence: "doing good design work on Android is more expensive and people pay less for it". It's harder work for less reward.
I haven't checked on Android as a platform in quite a long time but it is amazing to see that things still are exactly where they were when I last checked.
Android == Google == Free Software
That still seems to be the basic idea many users have.
It was always weird to see a platform with such high market share compared to iOS can not even get close to what iOS rakes in as revenue and mobile traffic.
If one looks at the numbers it's staggering that a platform with so many active devices cannot even get close to the mobile traffic that iOS generates. And no, I do not think that Android users just use apps and that's why you don't see regular mobile traffic from them. iOS also has apps and personally, I use mostly apps and don't surf that much using the browser.
Still, even back when I last checked people where projecting this to be a temporary thing and things would soon change to reflect Androids market share in the mobile revenue and mobile internet traffic statistics. Apparently, that does not seem to be the case. The Google == Free mentality seems to be too ingrained in people's minds. And I guess the recent privacy issues don't help there. "If they all gonna get my personal infos, then I surely won't pay for the app" seems to be the rational.
And why shouldn't it? It was long since established that if something is free, you are not the customer, you are the product. And if every other app seems to try and collect your info, of course you want the app to be free.
uggh, conversations about this stuff get so messy....
Android users mobile traffic? iOS users may show more mobile traffic because the locked down nature of so many iOS app/features forces you to go out to the browser/web for daily tasks. Android allows so much to be done with only a few apps and basic information which accounts for 85% of your daily us to be at your fingertips without having to open a browser.
So yeah, Android users may just use apps, but the reasoning/tracking for mobile traffic and pattern exhibited from iOS comes for different reasons...
This position sells the opposing argument short. It's not so much "designers believe a priori that Android users won't pay for good design," it's "Android users have a long and well-established track record of not paying for good design." People are still experimenting, and I think that this is actually a case you can rely on market mechanisms to handle. If Android users start demonstrating a willingness to pay for good design commensurate with the difficulty of producing good design for Android devices, there'll be a market opportunity there. Someone will get rewarded for providing people with what they're willing to pay for.
This leads into how Bowles sells the other argument short: he conflates design and graphic design when he address the "Android is hard to design for" argument. Design is, to borrow a famous phrasing, how it works. Sure, it was tough to do good graphic design for Gingerbread and it's much easier now. Great. However, the fragmentation and glacially-slow upgrades have a real cost here - to design the same functionality, may require spanning multiple API versions. The comparison to the diversity of Web browsers and viewers doesn't work because that diversity, relies on web standards. The equivalent of web standards that would allow an Android app to do responsive design in the manner of a web app, devices don't have or respect.
Fundamentally, it seems like Bowles doesn't get that the answer to his question is "because doing good design work on Android is more expensive and people pay less for it." Sure, you could ask designers to make speculative investments in Android, but I suspect that'll go about as well as asking people to make speculative investments of their professional time and skill usually goes. Professionals who respect their own time and worth, go where they can do good work and get paid well for it. Currently, that means they don't go to Android.