Why don’t designers take Android seriously?(medium.com)
medium.com
Why don’t designers take Android seriously?
https://medium.com/p/a649db399f42
36 comments
Eclipse is also HORRIBLE. Horrible, horrible horrible. Objective-C isn't exactly easy to understand, but Xcode is. I could functionally make things work in Xcode in 2 days having no experience with C or Objective C, I've probably spent 6 weeks in Eclipse in my life and I still couldn't really tell you how to do things. I have to re-learn it every time I want to do something, especially with the UI.
I can say the same for XCode — it's insanely horrible and completely unusable.
Congratulations on the most ridiculous comment on HN today. How many apps on the app store was that now, 1,000,000+ according to the admittedly non-authoritative Wikipedia. And all of them created with hex editors, you would have us believe. Not the completely unusable Xcode.
(a) opinions about things can vary among people
(b) people might suffer through substandard products because they're the only reasonable way of developing software for a platform (you see that sentiment a lot of times from people who claim to be forced to do development on Windows)
Just saying that a single person claiming that XCode is an unusable, horrible piece of shit probably says as much as 1 million apps being written for that platform. At least not about usability of the development environment.
(b) people might suffer through substandard products because they're the only reasonable way of developing software for a platform (you see that sentiment a lot of times from people who claim to be forced to do development on Windows)
Just saying that a single person claiming that XCode is an unusable, horrible piece of shit probably says as much as 1 million apps being written for that platform. At least not about usability of the development environment.
I find Xcode pretty awful and instead use AppCode with Xcode open at the same time.
Xcode 5 finally makes it easy to run single unit tests. Before this, you had to create a schema to run a single test, which was several clicks and possibly some typing. Now it's click and run, which is lovely.
Xcode 5 finally makes it easy to run single unit tests. Before this, you had to create a schema to run a single test, which was several clicks and possibly some typing. Now it's click and run, which is lovely.
I suppose to each their own, but if anything except for the provisioning/plist stuff in Xcode is complicated to you, you must be used to something else because in and of itself xCode is phenomenal.
xCode (sic) is far from phenomenal. I have been writing iOS apps since 2008 and Mac apps longer than that and Xcode has made significant progress, but is still mediocre.
It's very telling that Jetbrains managed to pull AppCode out of nowhere and blitz Xcode. I had never before used an IntelliJ-based IDE, but within a week or two my productive increased severalfold. It really puts Apple's efforts to shame.
It's very telling that Jetbrains managed to pull AppCode out of nowhere and blitz Xcode. I had never before used an IntelliJ-based IDE, but within a week or two my productive increased severalfold. It really puts Apple's efforts to shame.
I'm a big IntelliJ fan and I can't roll with AppCode. I admire the work, but XCode feels a lot better for native code development. (I do work in C++ and only use Objective-C for tooling via Obj-C++, though.)
AppCode's C++ isn't quite there yet, I agree. Lately I'm also mostly using XCode because a huge chunk of my codebase is modern C++.
But for pure Obj-C apps I'll take AppCode every day. There are so many little usability and productivity wins over Xcode.
But for pure Obj-C apps I'll take AppCode every day. There are so many little usability and productivity wins over Xcode.
Eclipse (or Android Studio) is good for when you are getting your feet wet with Android. If you don't like using it there are alternatives.
I usually use Emacs or vi. The only thing I miss when not using Eclipse with the ADT plugin is after typing say "LinearLayout ll;" with Eclipse I can type Control-Shift-O and the LinearLayout class is automatically imported in the code. I miss this, but I kind of have this in Emacs with JDE - a Control-C-V-Z has similar behavior. I could probably do some more tool work on Emacs and make it even more automatic.
I do everything with emacs, vi, ant, astyle, adb, and the Android commands "android" and "monitor". Some people do Android in IntelliJ, some in Netbeans. Some use Sublime Text.
If you think Eclipse with ADT is bad for Android development now, you should have seen Eclipse/ADT at the end of 2009. Just getting the ADT plugin to work with Eclipse was a nightmare. Having seen the improvement since then, I guess it all seems less bad to me. Although I don't use Eclipse when I do Android programming, generally.
I usually use Emacs or vi. The only thing I miss when not using Eclipse with the ADT plugin is after typing say "LinearLayout ll;" with Eclipse I can type Control-Shift-O and the LinearLayout class is automatically imported in the code. I miss this, but I kind of have this in Emacs with JDE - a Control-C-V-Z has similar behavior. I could probably do some more tool work on Emacs and make it even more automatic.
I do everything with emacs, vi, ant, astyle, adb, and the Android commands "android" and "monitor". Some people do Android in IntelliJ, some in Netbeans. Some use Sublime Text.
If you think Eclipse with ADT is bad for Android development now, you should have seen Eclipse/ADT at the end of 2009. Just getting the ADT plugin to work with Eclipse was a nightmare. Having seen the improvement since then, I guess it all seems less bad to me. Although I don't use Eclipse when I do Android programming, generally.
I'm pretty sure the idea is to get more GUI-based, not less. Telling a designer to use vi instead of Eclipse for UI is pretty hilarious.
Telling anybody to use vi at all is pretty hilarious.
I'm doing CoreOS based development at the moment and it only comes with vi. I've come across many other minimal linux environments where vi is the only option.
It's worth learning, even if you only learn the basics.
It's worth learning, even if you only learn the basics.
Perhaps you're already aware of Eclim, if not, check it out. Really useful for doing Android/Java in Vim.
Give Android Studio a shot. Makes laying out the UI in XML a breeze with its excellent intellisense.
I've heard that, and that's fine - I appreciate the suggestion and will probably use it, but if that's actually the best then people will take Android dev more seriously when the best is the standard IDE. Right now Eclipse is the default and it blows.
Eclipse is the default for most Java development, but I know fairly few serious Java developers who use it. Some do, I'm not saying they don't exist, but IntelliJ--of which Android Studio is a fork--is generally the go-to tool amongst the experienced, skilled Java folks I know. Double for Scala. (I used nothing but IDEA for Android work at my last job, for about eighteen months - Eclipse is certainly not required and doesn't really make it easier.)
I was wondering how IDEA compared to Eclipse for android dev, in large part because I'm interested in porting my app to Kotlin, if it's not too huge a jump. It's good to hear that it works well, despite not being the "official" default.
Although I cannot compare to Eclipse. I'm a .NET Dev with an interest in Android. In fact I'm falling out with MS and sticking to that for a day job, but want to do Java / Android in my spare time. I've just completed the Courera programming Android course and I did the whole thing in IDEA community edition. I had no problems what so ever getting answers to any questions. I was relatively comfortable and productive within about 20 hours. I had no previous Java experience (although I'm a clean C# coder for over 6 years)
I was impressed with the tools you get out the box. I've paid hundred (close to thousands) for similar tools in .NET.
I was impressed with the tools you get out the box. I've paid hundred (close to thousands) for similar tools in .NET.
Android Studio is completely replicated within IDEA itself, so there's that too. We used a Maven build that worked really well within IDEA--it correctly wired up the Android facet and everything.
I don't know anything about Kotlin on Android, though.
I don't know anything about Kotlin on Android, though.
Second this. Not to say I'm an experienced Java developer, but after trying both, I'm sticking with IntelliJ, which was introduced to me by a Google SSE who definitely favored it over Eclipse.
Actually "Eclipse is the default" is probably going to be false very soon. Every mid to senior level Android developer I know has migrated to Android Studio for months already. The advantages of Gradle and Studio are very apparent almost immediately.
Android Studio is the recommended IDE for any new projects. It's made by JetBrains, and it's 100x better.
I do not like Eclipse - it is clunky and often requires restarts to pick up changes or clear itself of confusion - and have never used Android Studio, but AFAICT the latter is still not the recommended editor according to the Android documentation - https://developer.android.com/sdk/index.html says "If you're a new Android developer, we recommend you download the ADT Bundle to quickly start developing apps." The ADT bundle is Eclipse-based. On the Studio page it warns "Caution: ... you may encounter bugs" (though as I say, with Eclipse I'm also sure you'll encounter your fair share of bugs!)
> On the Studio page it warns "Caution: ... you may encounter bugs"
Android Studio only added Gradle, which provides Groovy for its scripting, recently. Groovy has a history of shipping standalone versions as soon as possible and letting users find the bugs, and only afterwards does Grails bundle the version. I'd say Gradle-bundled sits somewhere between standalone and Grails-bundled on the testing scale for Groovy versions.
Android Studio only added Gradle, which provides Groovy for its scripting, recently. Groovy has a history of shipping standalone versions as soon as possible and letting users find the bugs, and only afterwards does Grails bundle the version. I'd say Gradle-bundled sits somewhere between standalone and Grails-bundled on the testing scale for Groovy versions.
It surely does. But why should I switch my build system? I'm a happy maven user. After all, only after AS came into picture I hear about the gradle non-sense. Gradle doesn't even use the proxy settings configured in AS (at least on Linux).
My honest response: it's not the IDEs fault. By the way I had felt the same with XCode and I don't think I can blame XCode for this.
I code in MacVim. For anything, not just Android and I didn't like either Eclipse or XCode, XCode even lesser as mentioned above.
I code in MacVim. For anything, not just Android and I didn't like either Eclipse or XCode, XCode even lesser as mentioned above.
> To make an app on Android look good, the responsibility lies much more on the developer than the designer.
I would add that the designer has to understand Fragment, understand that density, orientation, screen size and text size are different dimensions of screen geometry, and how to avoid a combinatorial explosion of layouts, or, conversely, layouts that only work at default font sizes on medium denisty screens.
The coder has to get it right, too.
I would add that the designer has to understand Fragment, understand that density, orientation, screen size and text size are different dimensions of screen geometry, and how to avoid a combinatorial explosion of layouts, or, conversely, layouts that only work at default font sizes on medium denisty screens.
The coder has to get it right, too.
Absolutely. In a lot of ways, Android UI design is like designing for the web, in that you're designing rules for layout more than you're designing specific layouts.
Although I'd argue that that's really what designers should be doing anyway, thinking procedurally and in terms of systems rather than fixed, one-off designs.
Although I'd argue that that's really what designers should be doing anyway, thinking procedurally and in terms of systems rather than fixed, one-off designs.
"From personal experience and from hearing 1st person stories of startups who went Android second, it takes at least 2x to even 3x the amount of time to build an Android app." This differs from my experience. I've work on several large app projects (> 200 000 downloads), and the Android versions have been ready before or at the same time as their iOS counterparts.
Also, the good apps are not made using IB. Fine for prototyping, sure, but not suitable for real world use. Feel free to prove me wrong, and name IB success stories.
Smells like good old FUD spreading to me.
Also, the good apps are not made using IB. Fine for prototyping, sure, but not suitable for real world use. Feel free to prove me wrong, and name IB success stories.
Smells like good old FUD spreading to me.
Saying good apps are not made using IB, and that its not suitable for real use, sounds like FUD to me too :)
Sure you need to leave IB sometimes (or a lot of the time - depending on the app), but if you are coding every little view by hand... well you have more time on your hands (and budget?) than I do :P
Sure you need to leave IB sometimes (or a lot of the time - depending on the app), but if you are coding every little view by hand... well you have more time on your hands (and budget?) than I do :P
>A browser permanently playing catch-up will always be an additional, potentially redundant, layer in the technology stack. If a single OS ends up running >90% of the world’s connected devices, why bother writing software for the browser?
I can't agree here. I think the OS world will be fragmented for a very long time (forever) and that the browser world will always have a core set of functionality to write apps once that run everywhere. I don't think Android, iOS, or the desktop browser are going anywhere fast, and so the only platform you can write for that reaches all three is the browser.
I suppose the author is predicting the end of desktops/laptops being relevant but even given that (which I don't think will ever happen) there will still be iOS and Android. That's still double the work to release one app on both. People will always try to find the common denominator and the browser is it (even if in another incarnation, e.g., Cordova/PhoneGap).
And assuming Android beats iOS, I can't imagine it beats the WWW too. I'd like to see a statistical breakdown of "native" apps with embedded browsers vs actual native apps. And if Cordova simply won't ever offer an elegant enough user experience, then I think Firefox OS will become the winner. The WWW is just so much bigger than Objective C or Dalvik, no one's going to port all that. So, even assuming that one OS rules >90% of devices, what percent of existing webapps/websites is that? And what percent of existing mobile apps' tech stacks is that, accounting for apps that are seemingly native but actually built on web tech?
I can't agree here. I think the OS world will be fragmented for a very long time (forever) and that the browser world will always have a core set of functionality to write apps once that run everywhere. I don't think Android, iOS, or the desktop browser are going anywhere fast, and so the only platform you can write for that reaches all three is the browser.
I suppose the author is predicting the end of desktops/laptops being relevant but even given that (which I don't think will ever happen) there will still be iOS and Android. That's still double the work to release one app on both. People will always try to find the common denominator and the browser is it (even if in another incarnation, e.g., Cordova/PhoneGap).
And assuming Android beats iOS, I can't imagine it beats the WWW too. I'd like to see a statistical breakdown of "native" apps with embedded browsers vs actual native apps. And if Cordova simply won't ever offer an elegant enough user experience, then I think Firefox OS will become the winner. The WWW is just so much bigger than Objective C or Dalvik, no one's going to port all that. So, even assuming that one OS rules >90% of devices, what percent of existing webapps/websites is that? And what percent of existing mobile apps' tech stacks is that, accounting for apps that are seemingly native but actually built on web tech?
Also it spares you from having to write Java, or worse - Objective C. I went for HTML5 just because I could use a (relatively) sane language and not be forced in walled gardens in the process - like having to buy a $3000 Mac to use a language that looks like it's straight from the 80's (and now they're trying to get me to buy a Mac just so I can view the console output of my Javascript app - I'm starting to think Apple HATES the people that develop software for their devices).
I don't take native apps in general seriously. The future will be cross platform web apps, and even if its not, I couldn't be arsed to write software for proprietary platforms.
Buy a $3000 Mac computer so you can write software in a language that doesn't work anywhere else (and for a good reason)? Sure, where do I sign up :D
Android doesn’t drive early adoption, so it would make sense to leave it out while you let iOS “take the cake” so to speak, for a while at least. Android, being the dominant platform with a huge mass of people in the early-to-late majority part of the bell curve, makes sense for when you want to scale.
"Android doesn’t drive early adoption"
Surely you're going to provide data or some citation to back that huge assertion.
Surely you're going to provide data or some citation to back that huge assertion.
Feel free to refute them with your own evidence.
I develop apps for both major mobile platforms, and when I speak with designers and artists about Android and iOS, they overwhelmingly prefer iOS. Since they use iOS devices themselves, it is their go to platform. It is almost always the one they want to work with.
Oddly, when I ask them why, the answers are mostly qualitative. It has nothing to do with "reaching the most people" or "getting exposure". It's a simple matter of taste. Designers tend to choose iOS products because they identify with them. They see Apple as an institution that they would enjoy being a part of in some way. Almost all the designers I know that are worth their salt use and love their macs for working in Photoshop and Illustrator, so it naturally follows that they prefer the iOS platform, regardless of numbers and market share.
Admittedly, my sample size is only around 50 or so, but this has been my experience.
Oddly, when I ask them why, the answers are mostly qualitative. It has nothing to do with "reaching the most people" or "getting exposure". It's a simple matter of taste. Designers tend to choose iOS products because they identify with them. They see Apple as an institution that they would enjoy being a part of in some way. Almost all the designers I know that are worth their salt use and love their macs for working in Photoshop and Illustrator, so it naturally follows that they prefer the iOS platform, regardless of numbers and market share.
Admittedly, my sample size is only around 50 or so, but this has been my experience.
Sounds akin to developers picking the companies they work for based on the programming languages/tech stacks they get to work with.
I can definitely sympathize.
I can definitely sympathize.
Glad you said that. Apple prepositioned itself as a design oriented company something that designers associate with. Something being easy is highly subjective.
As a designer this is exactly why.
No android phone nor interface is close to the level of what Apple is putting out - both from an experience and product standpoint. This is also the same exact same reason why I purchase all apple products.
I really don't understand the argument of "You're paying more for a lesser product when you buy Apple". Ok - so the hardware isn't as good/powerful, fine, but that's not why I'm buying an Apple product. I'm buying it because of the UX, because of the way the phone feels in my hand, because of the way the keys feel on the keyboard when I press them down, because of how great the applications look and feel when I use them.
If android came out with something that looked and felt great I would certainly consider using it. In fact, I purchased a Samsung Galaxy S3 several years ago when it first came out. The phone was absolute garbage - plastic bevels still had molding pieces around the edges, the unnecessary bloatware (which would have been fine if it was remotely useful) was very poorly designed, and overall the phone felt very light and cheap.
No android phone nor interface is close to the level of what Apple is putting out - both from an experience and product standpoint. This is also the same exact same reason why I purchase all apple products.
I really don't understand the argument of "You're paying more for a lesser product when you buy Apple". Ok - so the hardware isn't as good/powerful, fine, but that's not why I'm buying an Apple product. I'm buying it because of the UX, because of the way the phone feels in my hand, because of the way the keys feel on the keyboard when I press them down, because of how great the applications look and feel when I use them.
If android came out with something that looked and felt great I would certainly consider using it. In fact, I purchased a Samsung Galaxy S3 several years ago when it first came out. The phone was absolute garbage - plastic bevels still had molding pieces around the edges, the unnecessary bloatware (which would have been fine if it was remotely useful) was very poorly designed, and overall the phone felt very light and cheap.
> Ok - so the hardware isn't as good/powerful, fine, but that's not why I'm buying an Apple product.
The funny thing is, that's kind of a myth, particularly in phone land. The A7 (the 5S's SoC) had pretty much class-leading performance when it came out, except in highly parallel tasks, and to a large extent it _still does_.
The funny thing is, that's kind of a myth, particularly in phone land. The A7 (the 5S's SoC) had pretty much class-leading performance when it came out, except in highly parallel tasks, and to a large extent it _still does_.
That's not really surprising, since a large portion of mobile developers probably became mobile developers specifically because of what Apple was doing in iOS.
I was able to successfully train a designer to use the Android SDK's tools when appropriate, and check in graphical assets. In preparatory meetings I insisted the designer be in the room with the coders and product managers as I explained how Android is different. I taught them all how to use conditional layouts and how to test apps for good practices by changing font sizes to see if they really are geometry-independent. Once they saw how easy it is to make other developers' work look less than competent, I could see the switch in their minds flip: They were not doing to be tripped up by users who change font size.
This client was the typical kind of client who could easily have fallen into a "portitis" pattern of not designing for the capabilities of Android's layout system. If all parts of the system - product managers, coders, and designers, not have bought into thinking about their part of the project differently from an iOS implementation, the designers would have had no inputs from those other parts of the team re how they were modifying their approach for an Android version of their product.
Android has a richer system for adapting code modules to different layouts, and therefore a more sophisticated UX for tablets. It's a pity than many Android apps are low-bidder porting jobs that plaster right over that.
This client was the typical kind of client who could easily have fallen into a "portitis" pattern of not designing for the capabilities of Android's layout system. If all parts of the system - product managers, coders, and designers, not have bought into thinking about their part of the project differently from an iOS implementation, the designers would have had no inputs from those other parts of the team re how they were modifying their approach for an Android version of their product.
Android has a richer system for adapting code modules to different layouts, and therefore a more sophisticated UX for tablets. It's a pity than many Android apps are low-bidder porting jobs that plaster right over that.
I'd be interested in reading more about this - I'd love to show it to some designers I work with.
At the moment, I'm struggling to get the designers to acknowledge that Android and iOS need to be designed seperately. iOS designs can look pixel-perfect due to having only 2 resolutions to care about (ok, iPhone 5+ have taller screens, but same width)
Android is a whole different story.
At the moment, I'm struggling to get the designers to acknowledge that Android and iOS need to be designed seperately. iOS designs can look pixel-perfect due to having only 2 resolutions to care about (ok, iPhone 5+ have taller screens, but same width)
Android is a whole different story.
This is how I introduce Android to teams that are making their first serious non-game app:
1. How to scale the app across all screen geometries:
3. Then I get into Relative Layout and how to make your layouts "stretchy" enough that you don't have to specify a different layout for every combination of size, density, orientation, and text size.
4. Now that the coders and designers understand how they fit together in making a UX that "folds up" and "unfolds" I teach the designers how to check in to the client's repos, and how to edit layouts in Eclipse, so they can be responsible for their own work getting into the project and build and run the app to see how their layouts work.
This is still a vast simplification, leaving out things like Android remote methods and high-level (Intent) IPC and how hat affects UX, and numerous other areas where Android is substantively different from iOS's app environment.
1. How to scale the app across all screen geometries:
a. Let Android choose the layout from among the alternatives you create for different geometries
b. This means different numbers of Fragment objects can be displayed
c. This means different functionality can be available
d. This means you have to organize functionality in a hierarchy (for the smallest screens) that can be unfolded and flattened (for the biggest screens)
3. Then I get into Relative Layout and how to make your layouts "stretchy" enough that you don't have to specify a different layout for every combination of size, density, orientation, and text size.
4. Now that the coders and designers understand how they fit together in making a UX that "folds up" and "unfolds" I teach the designers how to check in to the client's repos, and how to edit layouts in Eclipse, so they can be responsible for their own work getting into the project and build and run the app to see how their layouts work.
This is still a vast simplification, leaving out things like Android remote methods and high-level (Intent) IPC and how hat affects UX, and numerous other areas where Android is substantively different from iOS's app environment.
Slide 86 on of this talk by Stephanie Rieger will help http://www.slideshare.net/yiibu/designing-for-diversity-how-...
(whole slide deck is worth looking at)
(whole slide deck is worth looking at)
As an app designer, I wouldn't mind a lesson myself!
Likewise. Zigurd, would you mind writing up a short lesson?
I wonder how much of it had to do with how graphically inconsistent Android was until 4.x
I had Stock Android 1.x and 2.x devices (before switching to iOS), and there was no consistent UI anywhere to be found, even different parts of the base system did things differently, not to mention non-scrollable UI elements that'd render off partially the screen (parts of the menus for example) - and thats just the interface - while android is better now, you still have the supposed fragmentation issues, and the fact that if you have a single device that has some issues with your app, you can end up with comments and ratings that reflect that minority rather than the majority of users for whom it works fine.
I had Stock Android 1.x and 2.x devices (before switching to iOS), and there was no consistent UI anywhere to be found, even different parts of the base system did things differently, not to mention non-scrollable UI elements that'd render off partially the screen (parts of the menus for example) - and thats just the interface - while android is better now, you still have the supposed fragmentation issues, and the fact that if you have a single device that has some issues with your app, you can end up with comments and ratings that reflect that minority rather than the majority of users for whom it works fine.
Fragmentation is a real thing, not laziness. Almost 98% of Android users don't run KitKat.
It is both a real thing and laziness. With decent technical design and Google's Android support library you can pretty much code as if 98% of people run KitKat and not worry about it, the support library will fallback gracefully down to all the OS versions you do care about.
Most of the time when I hear designers complaining about Android fragmentation they are really just using "fragmentation" as a scapegoat to bemoan they fact that they can't just create a very small set (1-3) of universal "pixel perfect" mockups and ship those off as a PSD to a developer as the end-all, be-all "visual spec". They have to worry about things like how different parts of the app should scale as more real estate is made available, really understand DPI (I've met more than a few designers who shockingly don't really grasp DPI scaling), etc. Some designers are awesome at this and welcome the challenges (and benefits!) that "responsive layout" brings with it, but a lot of them (most of them, in my personal experience) just want to punt on all that shit.
Most of the time when I hear designers complaining about Android fragmentation they are really just using "fragmentation" as a scapegoat to bemoan they fact that they can't just create a very small set (1-3) of universal "pixel perfect" mockups and ship those off as a PSD to a developer as the end-all, be-all "visual spec". They have to worry about things like how different parts of the app should scale as more real estate is made available, really understand DPI (I've met more than a few designers who shockingly don't really grasp DPI scaling), etc. Some designers are awesome at this and welcome the challenges (and benefits!) that "responsive layout" brings with it, but a lot of them (most of them, in my personal experience) just want to punt on all that shit.
> With decent technical design and Google's Android support library you can pretty much code as if 98% of people run KitKat and not worry about it
People say this. It's not really actually true.
A nice little example encountered recently. Say you have a HTTP server which uses gzip or deflate when the client asks it to. Pretty standard, right? And say you want to return a HTTP 204, or other contentless success. Seems reasonable? And if you do this on Android 4.4 using the standard HTTP client, it will work. If you do it on Android 4.1 (the most commonly-deployed version of Android), it will throw a null pointer exception deep in the library code.
This is just one of many issues. Compatibility support libraries are all very well, but they don't really help with the standard libraries being buggy, and those bugs will _never be fixed_ for the vast majority of users.
It gets even worse when you take OEM crap into account. Want to use the camera? You'd better know about obscure Samsung quirks: http://stackoverflow.com/questions/13448731/does-samsung-gal...
People say this. It's not really actually true.
A nice little example encountered recently. Say you have a HTTP server which uses gzip or deflate when the client asks it to. Pretty standard, right? And say you want to return a HTTP 204, or other contentless success. Seems reasonable? And if you do this on Android 4.4 using the standard HTTP client, it will work. If you do it on Android 4.1 (the most commonly-deployed version of Android), it will throw a null pointer exception deep in the library code.
This is just one of many issues. Compatibility support libraries are all very well, but they don't really help with the standard libraries being buggy, and those bugs will _never be fixed_ for the vast majority of users.
It gets even worse when you take OEM crap into account. Want to use the camera? You'd better know about obscure Samsung quirks: http://stackoverflow.com/questions/13448731/does-samsung-gal...
So you're saying it's easier to design on iOS then.
It IS much easier. Given that you only have to worry about 2 devices, with 2 resolutions (2x scaling is handled pretty well), it's perfectly possible to make a pixelperfect layout off a PSD (of course, things get a bit complex with font sizes, etc, but autolayout helps out).
It's "easier" in the same sense that it's easier to hack up a quick website in PHP than it is to write kernel driver.. (though the magnitude of the difference is not as great as that example picked for illustration).
And then you read about stuff like this[1]:
"Mika says it spent 20% of its total development time last year on the process of porting two of its games to Android and then tweaking those titles for individual devices. It could never even get Battleheart to work on Galaxy S phones, because they can't download .apk's larger than 30MB with stock software. For all the months of "thanklessly modifying shaders and texture formats to work on different GPUs, or pushing out patches to support new devices without crashing, or walking someone through how to fix an installation that wouldn't go through," Mika claims it never made a profit off either of its Android games."
Geez, I wouldn't go into Android game development after reading this. And we haven't even breached the piracy issues.
[1] http://www.androidpolice.com/2012/03/12/mika-mobiles-decisio...
"Mika says it spent 20% of its total development time last year on the process of porting two of its games to Android and then tweaking those titles for individual devices. It could never even get Battleheart to work on Galaxy S phones, because they can't download .apk's larger than 30MB with stock software. For all the months of "thanklessly modifying shaders and texture formats to work on different GPUs, or pushing out patches to support new devices without crashing, or walking someone through how to fix an installation that wouldn't go through," Mika claims it never made a profit off either of its Android games."
Geez, I wouldn't go into Android game development after reading this. And we haven't even breached the piracy issues.
[1] http://www.androidpolice.com/2012/03/12/mika-mobiles-decisio...
That's the original Galaxy S, a device which is now 5 years old. There are plenty of apps which no longer support iPhones that old.
"It's too hard" or "it doesn't make enough money" are more than reasonable. A software limitation in a 5 year old device is not.
"It's too hard" or "it doesn't make enough money" are more than reasonable. A software limitation in a 5 year old device is not.
You apparently missed that the article itself is from March 2012, talking about a game (Battleheart) released in June 2011.
The Galaxy S was released in June 2010 (so it's not even 4 years old, let alone 5…), it was barely a year old at game release and was not only one of the popular smartphones of the times, as the Nexus S it was also the reference device until November 2011.
The Galaxy S was released in June 2010 (so it's not even 4 years old, let alone 5…), it was barely a year old at game release and was not only one of the popular smartphones of the times, as the Nexus S it was also the reference device until November 2011.
It wasn't 5 years old when the article was written, though. The Galaxy S was less than 2 years old at that time.
But devices that limit inbound APK sizes? That's just too much to deal with.
Does that really matter though? Apps which require 4.0+ still frequently have terrible design which is just an iOS clone, complete with fuzzy assets and a frustratingly iOS-centric UI.
At the same time, developers like ShiftyJelly (www.shiftyjelly.com) show that fantastic crossplatform apps can be developed which have a great Android UI and are still very similar to their iOS counterparts.
I genuinely think it is just laziness, but while users continue to put up with it (especially since Android users appear to be happy to stick with a shitty UI on a free app compared to dropping a couple of dollars on a great one), it is unlikely to change.
At the same time, developers like ShiftyJelly (www.shiftyjelly.com) show that fantastic crossplatform apps can be developed which have a great Android UI and are still very similar to their iOS counterparts.
I genuinely think it is just laziness, but while users continue to put up with it (especially since Android users appear to be happy to stick with a shitty UI on a free app compared to dropping a couple of dollars on a great one), it is unlikely to change.
They design for the devices they have. They also design for the largest part of the viewing traffic of the web (ios). Apple is still a design deity.
Apple had the first big app platform and clients still demand iOS first. In game and app development, it still gets the most focus.
Finally, and a bit of a trick almost, is the review times are longer for Apple when talking about apps, this causes a focus on iOS earlier many times. Projects tend towards getting iOS ready early and in the queue and approved and the Android platforms second because Google Play is instant almost (Amazon is as slow as Apple on reviews). Like complaining customers that get the most focus, the more difficult to approve platform gets the most focus but only because of its market share and past (new entrants need to be easier).
However with Google's beta system on Play more and more projects are starting there now that a good chunk of clients have Android devices. Apple really needed to buy testflight because they didn't have anything as nice. Android is becoming a better test market and something you can iterate on faster early to prepare it for iOS, lots of game developers are thinking this way now, primarily because iOS is so hit driven at launch you have to get right and Google is better long tail is seems.
Apple had the first big app platform and clients still demand iOS first. In game and app development, it still gets the most focus.
Finally, and a bit of a trick almost, is the review times are longer for Apple when talking about apps, this causes a focus on iOS earlier many times. Projects tend towards getting iOS ready early and in the queue and approved and the Android platforms second because Google Play is instant almost (Amazon is as slow as Apple on reviews). Like complaining customers that get the most focus, the more difficult to approve platform gets the most focus but only because of its market share and past (new entrants need to be easier).
However with Google's beta system on Play more and more projects are starting there now that a good chunk of clients have Android devices. Apple really needed to buy testflight because they didn't have anything as nice. Android is becoming a better test market and something you can iterate on faster early to prepare it for iOS, lots of game developers are thinking this way now, primarily because iOS is so hit driven at launch you have to get right and Google is better long tail is seems.
Granted I'm a developer who's just starting out with Android, but for the life of me I can't figure out any reasonable way to position things with percentages and maximum widths. I tried weight_sum and weight and gravity=center and that gets me percentages but then maxWidth is ignored.
Most of the advice online seems to be "you must construct additional LinearLayouts".
Most of the advice online seems to be "you must construct additional LinearLayouts".
I've been writing Android code for close to 3 years now and I can tell you the problem isn't you. Android layouts are like CSS in that eventually they warp your brain to the point where you can mostly understand them and be productive with them, but they are still kind of ridiculous and make doing things that should be relatively easy much harder than they ought to be.
Sadly the whole way the layout system works seeps into the programmatic APIs in all sorts of bad ways too -- like, I just want to set the width of this view... there's no setWidth, wtf? Oh... LayoutParams? What in the hell is all this. Not to mention things like every layout type having its own LayoutParams class and all the fun that comes along with changing say a RelativeLayout to a LinearLayout and then having to both change all your different dpi xml files to match (especially on tablet/phone hybrid apps), and also make a ton of code changes to correct your Java casting, etc. bleh.
Sadly the whole way the layout system works seeps into the programmatic APIs in all sorts of bad ways too -- like, I just want to set the width of this view... there's no setWidth, wtf? Oh... LayoutParams? What in the hell is all this. Not to mention things like every layout type having its own LayoutParams class and all the fun that comes along with changing say a RelativeLayout to a LinearLayout and then having to both change all your different dpi xml files to match (especially on tablet/phone hybrid apps), and also make a ton of code changes to correct your Java casting, etc. bleh.
I've been there. I even started one small isolated project with the experimental idea to completely forego the XML layouts and just build the entire thing in Java.
Embarrassingly, it actually worked out okay. The thing is, with XML layouts, eventually the functionality requirements force you to pull in nearly all the views in Java and set styles and behavior programmatically. It's not exactly pleasant to do everything in Java (especially things like RelativeLayout.LayoutParams), but you're going to have to do it anyway, so the only thing the XML layouts really save you is setting up the view hierarchy. Perhaps if I worked with a designer who created the XML layouts and styles, this wouldn't be the case, but the Android tools for designers seem laughably bad.
Embarrassingly, it actually worked out okay. The thing is, with XML layouts, eventually the functionality requirements force you to pull in nearly all the views in Java and set styles and behavior programmatically. It's not exactly pleasant to do everything in Java (especially things like RelativeLayout.LayoutParams), but you're going to have to do it anyway, so the only thing the XML layouts really save you is setting up the view hierarchy. Perhaps if I worked with a designer who created the XML layouts and styles, this wouldn't be the case, but the Android tools for designers seem laughably bad.
Really? I picked up CSS in a few hours but I still can't begin to wrap my head around how to properly work with Android layouts.
I really wish Google would let people use HTML and CSS instead of that bizarre relational XML stuff.
I really wish Google would let people use HTML and CSS instead of that bizarre relational XML stuff.
PhoneGap is exactly that, with the bonus that's it's also cross platform.
http://phonegap.com/
http://phonegap.com/
And this is where a seasoned developer is required to implement good design on Android: you'll want to write a custom ViewGroup to layout child views the way that you want, without nesting layouts and causing overdraw or slow rendering.
I tried to do Android development and threw in the towel.
But picked it up again later using Xamarin Studio. Much nicer experience and easier to make a nice design.
I managed to make a small app and have it run on my iPhone and Windows Phone, and my flatmates Android.
Lots of fun, just lacking ideas to make a real world app now :(
But picked it up again later using Xamarin Studio. Much nicer experience and easier to make a nice design.
I managed to make a small app and have it run on my iPhone and Windows Phone, and my flatmates Android.
Lots of fun, just lacking ideas to make a real world app now :(
Has anyone seen good results with the new Qt mobile tools? I realize that it won't look quite native - but Qt's got a pretty good track record, and if I could write apps using C++ instead of Java, and get some cross-platform capability, I'd certainly be interested.
I've been burned by cross-platform tools. I tried Sencha Touch, and it was a horrible 2-year mistake.
Something that compiles might do better, but at the end of the day you really want to be calling into the cocoa touch framework directly. If Qt lets you do this, great. If it doesn't, look elsewhere.
Something that compiles might do better, but at the end of the day you really want to be calling into the cocoa touch framework directly. If Qt lets you do this, great. If it doesn't, look elsewhere.
I have probably been writing and porting more C++ code on Android lately than Java code. I haven't done much with QT. Some of the apps used the SDL library. Some of the apps have been OpenGL 1.x code ported to OpenGL ES.
I guess it all depends on what platforms you have in mind.
I guess it all depends on what platforms you have in mind.
Elephant in the room = adoption rate of current OS version. "Kit Kat is awesome!!" That's great. Who is using it?
I am. On my Nexus 5. Compared to a iPhone 5s, this runs circles around it. I'm not trying to start a flamewar or anything, but why are iOS devices so slow and clunky, and why is the UI so... fruity? Its just weird.
I am.
I've also got an iPad and seriously considered getting a iPhone instead of my Nexus 4 but iOS's poor keyboard i.e. key caps are always uppercase regardless of shift state, it's hunt and peck rather than swype, and the lack of intents were a deal breaker for me.
I've also got an iPad and seriously considered getting a iPhone instead of my Nexus 4 but iOS's poor keyboard i.e. key caps are always uppercase regardless of shift state, it's hunt and peck rather than swype, and the lack of intents were a deal breaker for me.
You're in a tiny minority, right now. 2.5% of Android users use 4.4, compared to 19% using 2.3.x, 15% using 4.0.x, and _35%_ using 4.1.x. It's nice that you like it, but it's probably not worth most developers' time using 4.4-specific features for a year or so.
Terrific.
[deleted]
About 2.5% of the users.
Why don't designers make their stacked area charts really oddly proportioned and with muddled palettes so that they're difficult to read?
Oh, wait, they do!
Oh, wait, they do!
The chart is from a well known and respected former Nokia analyst who, incidentally, has a degree in computer science. I guess the question should be; "Why do people on the internet consistently mouth off without checking their facts, which are always a mere search away?"
> 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.
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.
> 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.
Oh, really?
Let's take a look shall we:
1. Using new APIs if available and falling back gracefully if not: http://developer.android.com/training/basics/supporting-devi...
2. Adapting your layout and UI to each device based on screen size, density and other features: http://developer.android.com/training/multiscreen/index.html
3. Libraries to help use newer features while being backward-compatible: http://developer.android.com/tools/support-library/index.htm...
And so on. Looks to me like there's plenty of infrastructure to help building responsive apps if you want to.
Oh, really?
Let's take a look shall we:
1. Using new APIs if available and falling back gracefully if not: http://developer.android.com/training/basics/supporting-devi...
2. Adapting your layout and UI to each device based on screen size, density and other features: http://developer.android.com/training/multiscreen/index.html
3. Libraries to help use newer features while being backward-compatible: http://developer.android.com/tools/support-library/index.htm...
And so on. Looks to me like there's plenty of infrastructure to help building responsive apps if you want to.
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.
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.
You are not really aware of the documentation are you?
ActionBar is not a community shim anymore, a compatibility library down to gingerbread is provided and supported by Google: http://developer.android.com/reference/android/support/v7/ap...
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...
ActionBar is not a community shim anymore, a compatibility library down to gingerbread is provided and supported by Google: http://developer.android.com/reference/android/support/v7/ap...
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.
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
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
[deleted]
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.
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.
It seems to me that we have to go more than a year back, since iOS generated more web traffic than android: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#De...
There is something going on with iOS and Android web usage.
My daughter used 8 gig of data last month. It meant she watched a lot of Netflix at her college who's Wifi is weak.
Video = More Data not necessarily a good measurement.
My daughter used 8 gig of data last month. It meant she watched a lot of Netflix at her college who's Wifi is weak.
Video = More Data not necessarily a good measurement.
I don't understand, do you mean that the stats I provided are based on data usage? In that case you are not correct. They are all StatCounter web hits: http://gs.statcounter.com/#mobile+tablet+console-browser-ww-...
Free Software != Freeware
Come on!
Come on!
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...
"However, the growth patterns of Android are what give it such power. Android utterly dominates in emerging markets."
The last point there is an important one. In the US (and various other markets), iOS and Android are not that far apart in user count. In fact I believe in the US now, iOS is taking share back (albeit a minor share lol): http://www.comscore.com/Insights/Press_Releases/2014/3/comSc...
But anyway, I've enjoyed reading the comments here, and I think the point about designers themselves being more mac-oriented (historically) is a pretty valid reason!
The last point there is an important one. In the US (and various other markets), iOS and Android are not that far apart in user count. In fact I believe in the US now, iOS is taking share back (albeit a minor share lol): http://www.comscore.com/Insights/Press_Releases/2014/3/comSc...
But anyway, I've enjoyed reading the comments here, and I think the point about designers themselves being more mac-oriented (historically) is a pretty valid reason!
Designers don't take Android seriously because they are mostly iOS users. It's hard to build on something you cannot really relate to.
There also seems to an element of elitism among Apple fanboys, thinking their design is the only one that matters.
"Android users obviously picked their device for other reasons than design, so it doesn't have to look as good."
"Android users obviously picked their device for other reasons than design, so it doesn't have to look as good."
>..."element of elitism among Apple fanboys,"
Let's not use pejoratives. While we are at it, let's not project our own assumptions as points of fact.
Let's not use pejoratives. While we are at it, let's not project our own assumptions as points of fact.
You are right, I have but a little anecdotal evidence.
In my experience there does exists a group of designers who view Apple to be the gospel of UI design, which can sometimes lead to them ignoring other schools of thought.
So if I've got this right... It's those nasty lazy designerses fault, and has nothing to do with Androids colossal shortcomings either as a platform to develop for, or to earn a living from?
No. And I said, these designers are a minority. Android is definitely hard to get "right" design-wise, but it can be done.
But if all you are trying to do is make it look like iOS, you are on the wrong track.
Monetization issues are a separate problem as far as I can see. While money can shift priorities, but shouldn't affect design.
But if all you are trying to do is make it look like iOS, you are on the wrong track.
Monetization issues are a separate problem as far as I can see. While money can shift priorities, but shouldn't affect design.
Probably because when Android evangelists (not necessarily Google) market Android as the "anti-Apple" OS, you remind a lot of current Apple users about the days when Windows ruled the earth and all of the anti-usability that came with it.
Money is in iOS, so companies prioritize it first. After Android becomes the main platform for monetization, it will probably be taken a lot more seriously.
Right now it goes like this in every company.
1) Lets make an iOS app
2) okay we have an iOS app, can someone clone an Android one real quick? It doesn't have to be perfect, just get it done ASAP.
> I recognise that I have a fairly rare stance, given the ideology that surrounds platform issues.
It's not a rare stance. Android is the hot thing now and has been gaining tons of momentum.
Right now it goes like this in every company.
1) Lets make an iOS app
2) okay we have an iOS app, can someone clone an Android one real quick? It doesn't have to be perfect, just get it done ASAP.
> I recognise that I have a fairly rare stance, given the ideology that surrounds platform issues.
It's not a rare stance. Android is the hot thing now and has been gaining tons of momentum.
Most designers I see have iPhones. I think they just like designing for a platform that they like. It's natural. People who like Linux develop for Linux, etc. Why would you do otherwise?
Make more money perhaps, no source on whether or not well designed apps drive more revenue, just a guess.
> My uncharitable interpretation for this class of responses is simple laziness
What does this mean? If I was uncharitable, I'd say it sounds like he wants designers and developers to work nights and weekends. If there's a business case for supporting Android, then you need more headcount. If not, calling the team lazy is unnecessary.
> I do hope, given tech’s rhetoric about changing the world and disrupting outdated hierarchies, that we don’t really think only those with revenue potential are worth our attention.
Most designers work for for-profit companies where revenue potential is an extremely important consideration, irrespective of whether they personally sympathize with the poor.
There's a valid point buried in here somewhere. It's possible that companies are underinvesting in Android because they've underestimate the opportunity, but blaming this on designers preferring iOS is just weird. A decision as important as the choice of platform is rarely left up to the personal preference of the designer.
What does this mean? If I was uncharitable, I'd say it sounds like he wants designers and developers to work nights and weekends. If there's a business case for supporting Android, then you need more headcount. If not, calling the team lazy is unnecessary.
> I do hope, given tech’s rhetoric about changing the world and disrupting outdated hierarchies, that we don’t really think only those with revenue potential are worth our attention.
Most designers work for for-profit companies where revenue potential is an extremely important consideration, irrespective of whether they personally sympathize with the poor.
There's a valid point buried in here somewhere. It's possible that companies are underinvesting in Android because they've underestimate the opportunity, but blaming this on designers preferring iOS is just weird. A decision as important as the choice of platform is rarely left up to the personal preference of the designer.
I one thing to consider, is that emerging markets also generally spend less money on applications, and good design is expensive.
I've seen two identical apps (games specifically) on Android and iOS, the iOS versions made considerably more revenue than the Android version.
So I guess the commonly asked question is "Will we make the same amount of money with a cheaper design?"
Obviously this is a bit anecdotal, but I think it's a contributing factor.
I've seen two identical apps (games specifically) on Android and iOS, the iOS versions made considerably more revenue than the Android version.
So I guess the commonly asked question is "Will we make the same amount of money with a cheaper design?"
Obviously this is a bit anecdotal, but I think it's a contributing factor.
This was more complaining. I wish he would show an example with android UI
Rather than asking "Why don't designers take Android seriously?" I'd ask "Why don't companies take Android seriously?" Once a company decides to take Android seriously, it isn't all that difficult to create compelling apps, with or without a designer that is dedicated to the Android platform. While I don't advocate simply copying the iOS experience on Android, a developer with some knowledge of how the platform works doesn't necessarily need a designer's help to modify the iOS experience to fit Android paradigms.
Because great designed Android apps don't sell any better than mediocre ones.
> Why don’t designers take Android seriously?
Perhaps simply because design doesn't appear to be instrumental to the success on this platform?
Perhaps simply because design doesn't appear to be instrumental to the success on this platform?
> 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”.
How about "Android users want a phone, not apps". If you want a phone, you get an Android. If you want apps, you get an iPhone.
Look at the stats for web use. In 2012, there was more Android Webkit use of cellular (more users?), but far more Mobile Safari if you included WiFi. An iPhone / iPad is used as a computer, Android is a phone and mobile browser (for when you can't use a real computer).
How about "Android users want a phone, not apps". If you want a phone, you get an Android. If you want apps, you get an iPhone.
Look at the stats for web use. In 2012, there was more Android Webkit use of cellular (more users?), but far more Mobile Safari if you included WiFi. An iPhone / iPad is used as a computer, Android is a phone and mobile browser (for when you can't use a real computer).
No, Android user wants apps. iPhone is just expensive as hell. Android is much cheaper alternative. People who want "just phone with browser" usually buy Nokia Asha or feature phone.
A touchscreen Nokia Asha or other feature phone is not actually cheaper than an Android phone and very few shops carry them. You have to be quite into phones to even know they exists and have any reason why you'd want one. If a person who wants a cheap phone with a browser walks into a shop and asks for a cheap phone with a browser, they'll be walking out with a low end Android phone.
Really, even if they just ask for a cheap phone; at least in Europe, many telecoms don't sell consumer feature phones anymore _at all_.
And your evidence is ... ? It seems to me there are more than enough cheap and crappy Android handsets out there to serve the feature-phone market too.
The cheapest Android phone I found costs 50 euro. You can easily find feature phone for 15-20 euro.
Depends where you live. In Ireland, for instance, if you walk into a shop wanting a prepaid phone, you're pretty much getting an Android, with most telecoms. Three, for instance (generally the cheapest major telco), currently lists precisely one non-Android phone in its under-100 euro category, and it's not a feature phone, it's a Symbian smartphone. The rest of its cheap phones are Android, mostly 2.3 and 4.0/4.1.
You could buy a feature phone separately and bring it to the telecom, of course, but normal consumers don't do that.
You could buy a feature phone separately and bring it to the telecom, of course, but normal consumers don't do that.
Three, and every other telco, has a vested interest in getting you to buy something that they can sell you data for [1]. Argos will sell you an unlocked Samsung phone for 19 euro, Nokia for 25.
[1] of course, Three doesn't let you use that data because their network is a joke, but that's another story from the annals of "Ireland may be wealthy, but our infrastructure sucks so hard CERN has a contender for accidentally opening black holes in atmosphere"
[1] of course, Three doesn't let you use that data because their network is a joke, but that's another story from the annals of "Ireland may be wealthy, but our infrastructure sucks so hard CERN has a contender for accidentally opening black holes in atmosphere"
> Look at the stats for web use. In 2012, there was more Android Webkit use of cellular (more users?), but far more Mobile Safari if you included WiFi.
Web use is not the same that app use.
Web use is not the same that app use.
Part of why Android development is so frustrating for me is the tools we have to use. If I'm not bashing my head trying to understand fragments and layouts, I'm battling with Eclipse -- constantly closing/refreshing project -- and that incredibly slow emulator.
Android Studio is way better in every conceivable way the old Eclipse-based ADT and I haven't had speed problems with the Android emulator since they released the x86 images. Have you actually developed for Android in the last year?
I never used Android Studio, only Eclipse, since it was what everybody else was using. This was my experience from around 2012/13 sorry for sharing it but it put me off Android.
Things have drastically improved. You should give the new toolchain another try. It's far from perfect, but a huge improvement.
Yes, Android is gobbling up marketshare, but the growth is at the low end. The cheap plastic boxes made for people for whom design is not a deciding factor.
When given a choice, most designers will work for companies and customers that appreciate good design and are willing to pay more for excellence in experience, even at the expense of raw specs. Apple has built its success on aiming for that market.
You see this in all products, from phones to cars to houses, so why should Android be any different?
The best designers will work on premium products, and Android just isn't. Google doesn't care much for design, and neither do the Android hardware manufacturers (with the possible exception of HTC, and you can see how popular that is in the Android market...), so that creates an ecosystem in which design, visual, industrial and UX, is secondary.
Just like good developers don't like to work somewhere where good code is not considered important, designers don't want to work in a market where their talent isn't valued.
When given a choice, most designers will work for companies and customers that appreciate good design and are willing to pay more for excellence in experience, even at the expense of raw specs. Apple has built its success on aiming for that market.
You see this in all products, from phones to cars to houses, so why should Android be any different?
The best designers will work on premium products, and Android just isn't. Google doesn't care much for design, and neither do the Android hardware manufacturers (with the possible exception of HTC, and you can see how popular that is in the Android market...), so that creates an ecosystem in which design, visual, industrial and UX, is secondary.
Just like good developers don't like to work somewhere where good code is not considered important, designers don't want to work in a market where their talent isn't valued.
they dont take it seriously because Google doesent
I'm not going to get acquired by Facebook for releasing my powerlifting app on android. So I truly do need to consider the "Android users are poor" statement.
They are.
I did some math, though, and the time it will take me to learn android and build the android app should be worth my time if I can convert a decent percentage of my old android paid users over to the designed, native app.
They are.
I did some math, though, and the time it will take me to learn android and build the android app should be worth my time if I can convert a decent percentage of my old android paid users over to the designed, native app.
A friend of mine is making at this moment a vector based Android skin file in Sketch. You guys should check it out when it is ready (very soon).
http://android.sketchtricks.com/
http://android.sketchtricks.com/
Apps in Android market are not under pressure from design competition, people drive the way things they need ... when people accepts things the changes are really slow -- people push change.
We apply unidesign (works equally well on iOS and Android) for all our apps these days. But we take iOS as the base for design. This is because Android still do not have the design consistency of iOS. Also Android devices come in variety of shapes and sizes and resolutions making it difficult to visualize end result.
"My uncharitable interpretation for this class of responses is simple laziness"
That does not make sense. Those designers will not go home sooner for using web. They work how much they work regardless of technology choice. Those who work hard will work hard on both Android and web and those who slack will slack on both. What changes is how much they achieve during their work-time.
"it’s a value judgment on who is worth designing for. [...] I do hope, given tech’s rhetoric about changing the world and disrupting outdated hierarchies, that we don’t really think only those with revenue potential are worth our attention. "
This argument does not make much sense to me. Those are designers working for companies. Both companies and designers gotta pay bills. Even if they do not, owners want to get rich and there is nothing wrong with it. That is what business is.
As for disrupting rhetoric, that one is just a buzzword used to get attention. Getting attention is needed to earn money. Anyone with half a brain know that "disrupting" means either "new" or "has earning potential" these days. By definition, you will disrupt nothing by releasing apps nobody wants to buy
WhatsApp and few other successful apps are outliers and not a norm. They did not become successful by nice design only, they become successful by figuring out which features matter right now for their business.
That does not make sense. Those designers will not go home sooner for using web. They work how much they work regardless of technology choice. Those who work hard will work hard on both Android and web and those who slack will slack on both. What changes is how much they achieve during their work-time.
"it’s a value judgment on who is worth designing for. [...] I do hope, given tech’s rhetoric about changing the world and disrupting outdated hierarchies, that we don’t really think only those with revenue potential are worth our attention. "
This argument does not make much sense to me. Those are designers working for companies. Both companies and designers gotta pay bills. Even if they do not, owners want to get rich and there is nothing wrong with it. That is what business is.
As for disrupting rhetoric, that one is just a buzzword used to get attention. Getting attention is needed to earn money. Anyone with half a brain know that "disrupting" means either "new" or "has earning potential" these days. By definition, you will disrupt nothing by releasing apps nobody wants to buy
WhatsApp and few other successful apps are outliers and not a norm. They did not become successful by nice design only, they become successful by figuring out which features matter right now for their business.
This is why when a very talented Android engineer like Sarah Haider (Twitter's Android lead) goes from Twitter to Secret, it is a big deal. There are many strong, capable iOS technical leads out there and probably a fraction thereof in Droidlandia (using Pareto's famous rule, probably 4 - 5 good iOS technical leads for every 1 good Android technical lead).
To make an app on Android look good, the responsibility lies much more on the developer than the designer. The designer on iOS can easily use IB. Not so much Android Studio or Eclipse.
At the highest levels (slightly below Jake Wharton), talented Android developers who care about the user experience and can deliver compelling, beautiful apps can name their own price.