Why don’t designers take Android seriously?
medium.com
medium.com
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.
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.
(whole slide deck is worth looking at)
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.
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.
I can definitely sympathize.
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.
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_.
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.
I don't know anything about Kotlin on Android, though.
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 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'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.
But for pure Obj-C apps I'll take AppCode every day. There are so many little usability and productivity wins over Xcode.
(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.
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 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.
It's worth learning, even if you only learn the basics.
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 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.
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.
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.
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
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.
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.
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.
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.
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...
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
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.
Come on!
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.
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.
Most of the advice online seems to be "you must construct additional LinearLayouts".
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 really wish Google would let people use HTML and CSS instead of that bizarre relational XML stuff.
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.
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 :(
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 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.
"Android users obviously picked their device for other reasons than design, so it doesn't have to look as good."
Let's not use pejoratives. While we are at it, let's not project our own assumptions as points of fact.
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.
Oh, wait, they do!
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).
You could buy a feature phone separately and bring it to the telecom, of course, but normal consumers don't do that.
[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"
Web use is not the same that app use.
I guess it all depends on what platforms you have in mind.
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.
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.
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.
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.
"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...
"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.
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.
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.
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...
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.
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.
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.
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.
Perhaps simply because design doesn't appear to be instrumental to the success on this platform?
Surely you're going to provide data or some citation to back that huge assertion.
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!
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.
Or, "How to get me to stop reading after the first paragraph".