Shared publicly  - 
 
There has been a recent trend among new apps to use a mostly-default Holo theme and follow the design guidelines as if they were a strict requirement. I would argue that this is incorrect and is actually worse than deviating from them a bit. The Android Design Guidelines should be treated as you would a GPS in your car--it's there to navigate you along logical paths but it is still you who must do the driving.

Applications which use the stock theming on Android will never go away. With the last few iterations of the platform the default theme has gone from a disjointed plastic mess to a sleek and clean blue wonder. For this, I think everyone is thankful.

However, just because we now have a document that defines use of widgets, relative sizing, and interaction patterns as well as a pretty theme to slap on top does not mean that there is no work to be done for those writing applications. If anything, simply following that formula creates an application that becomes distant, emotionless, and boring.

Designing is hard. It's also strongly an opinion-based field which makes it a lot harder. I had a specific application that is becoming very popular in mind that I was going to critique but I think it's best to let them iterate on design themselves.

For every application that is following the design guidelines (and that should be every single one) there are two things that you must do:

Provide non-default styles to UI-defining widgets. Most notably, of course, the action bar and all its intricacies. Providing a single color background here is not enough. The design guidelines states that "the action bar is arguably the most important structural element of an Android app. It's a dedicated piece of real estate at the top of each screen that is generally persistent throughout the app." If we users must stare at this widget on every screen of your application you damn well better make sure it looks good.

Theming the action bar has a fantastic side-effect of branding your application. You can easily create a unique look through this widget so be sure to take the time here. There is a lot to consider, but I assure you that the benefits are worth it: icons, background, split background, stacked background, action item selector, tab selectors, and your app icon/logo. Need some examples? YouTube, Friendcaster, Papermill, and the Play Store client.

The other big thing that applications must do is to not overuse these patterns and not be afraid to deviate from the norm. Not everything necessitates an action bar and a view pager. Moreover, the design guidelines are not strict laws. If your widgets look better with 10dp spacing instead of 8dp then do it. It is more important to adhere to the 'Pure Android' section than it is including every single pattern.

This task is certainly not easy but it is by no means difficult. I urge all you developers out there to spend some serious time on providing a unique look to your application. Through this you will evoke emotions in your user leading to better engagement and providing that so-called "X" factor of why your app is simply more enjoyable to use than others.

I had originally intended to call out specific examples of where this was needed in a few applications that have recently garnered a lot of attention. I think each of the teams and developers behind those applications are slowly moving in the right direction and with each update comes a warmer experience. I didn't think it would be appropriate to call them out directly. The key here is to realize where you need improvement and ensure that you are taking steps toward a better solution.
196
50
Roman Nurik's profile photoDiji Adeyemo's profile photoDavid Cesarino's profile photoMichael Stevenson's profile photo
30 comments
 
The biggest problem I've come across is often times when designers think they're "breaking new ground" on Android, they end up taking a lot of their iOS biases with them causing their new approach to not fit with Android's design language. It's not that one should set out to break the guidelines. Rather, the guidelines should be your default. It's completely fine to break them, but you must have a fairly good reason for doing so. Better branding is a good reason; "we did it that way on iOS" is not. For a lot of designers who work primarily in iOS or split their time between iOS and Android, there is a lot of checking assumptions and biases that must go on if you're going to deviate.
 
I guess one of the applications you were thinking about is Instagram for Android. Yes, this is a good example of how to not port an iOS application to Android.

I would prefer if every Android application would be based on the Android Design Guidelines and for example not put an action/tab bar to the bottom of the screen. Of course minor alterations are ok but app designers/developers shouldn't add UI patterns which are absolutely uncommon for Android and wouldn't utilize the (unique) advantages of the system.
 
+Jake Wharton Exactly.
The design guidelines are important in interaction design. Following navigation guidelines etc is important.
Visual design is different. The guideline document isn't suggesting that every app should be default Holo.

http://developer.android.com/design/style/themes.html
"Pick the system theme that best matches the needs and design aesthetics for your app. If your desire is to have a more distinct look for your app, using one of the system themes as a starting point for your customizations is a good idea. The system themes provide a solid foundation on top of which you can selectively implement your own visual stylings."

This is a good guideline. Starting from Holo makes sense. Visual design is difficult and requires skills that I, for example, don't have. For me starting from Holo and customising some bits and leaving others untouched makes it easier to reach a good result.
 
Great piece. I was just thinking about how the first pure-Holo apps seemed to have a distinct look, but just because there weren't many of them. Now that developers are paying much more attention to the UI (thanks, +Matias Duarte for ICS and the design guidelines) and lots of apps are moving on to a standard Holoish/ICSish UI, it's not unique anymore.
I mean, Holo is great, but if you need to get a visual identity of your own, you have to provide some unique details in your design. A pure stock UI might be great for some apps, but it's not always the best choice. Totally agree on that.
 
This is great. Too many apps are now so focused on the Android Design Guidelines that they're missing what I think is they key to standing out: looking unique.

I could have a hundred different apps that work really well and achieve what I want them to do, but if they all look like the default Android look, I would rather download the one app that has a unique visual appeal and support that developer in creating something that can truly stand out from the Holo based horde.
 
+Juhani Lehtimäki Yes. I totally agree. I'm no designer either but I try and consume as much design-related content as possible so that while I may not have the skills to make something beautiful, I can at least understand the methodology behind what makes something beautiful or not. The Holo assets are a great starting point for customization and they make it really easy to get a good looking app with not too much effort. Piggy-backing on the extensive work done by the Android team is a great way to ensure your app fits in with the platform as well.

Another thing that I forgot to mention that really bothers me is backporting pure Holo to pre-3.0. Nobody wants to see the pure Holo experience on an Android 2.2 device because it's wildly out of place. "But wait," you might say, "doesn't ActionBarSherlock do just this?" Well, yes, it does but only in an effort to provide a consistent base across platforms that you can build on. I tell every developer to use it as a starting point on which to build a simple customizations. Even if all you do is take the default action bar background and replace the blue line with yellow, red, purple, pink, or anything you've now started down the path of creating a unique look for your app. Use all of the Holo assets as a foundation, not a finish line.

+Sven Jacobs I actually had not been thinking of Instagram when writing this. The Instagram app does a good job of providing a unique look. Sure their interaction patterns are blatently iOS but I think that's been well documented by a lot of folks. With this I was only trying to focus on apps which use the Holo theme as a crutch rather than as a base for building a clean look.

+Josh Brown Yes it's a fine line. And as +Juhani Lehtimäki said, I'm not trying to say deviate from things like the concrete navigation patters that are outlined but rather more a pure visual design aspect. Unfortunately a lot of design is done for iOS first and Android is left shoving square blocks into round holes to make it fit with the platform.
 
+Jake Wharton I completely agree. The biggest problem with porting a design from iOS is that it's too easy to deviate from the guidelines without thinking about it. Deviations should require justification. I think the best approach I've seen is to have a separate UX/Flow designer (or design team if you're large enough) for each platform and a single UI/Visual designer for both. This gives you the cohesiveness and brand consistency that a common design gives you while ensuring you're fitting in with the platform. If you have a site map phase of your design, that should probably be common across platforms (where it makes sense).
 
+Jake Wharton I have to say that I disagree with the back port bit. 2.3 default design was so bad that anything is better. This is a very interesting discussion in general. How do we design apps so they support older platforms too. I don't have any problem seeing Holo based design on older devices. That is the future of Android anyways so it is a pretty safe bet. There really isn't any other guidelines for them. :/
 
As the Android design guide itself states, "deviate with purpose." Everyone so far in the comment thread is on the right track.

There's not usually a good reason to come up with something custom to accomplish something that already has an established idiom on any platform you're targeting, Android or otherwise. Don't migrate system interaction patterns from elsewhere just to have some misguided form of consistency between ports of your app that you publish on different platforms. That serves to confuse and alienate your users. A feeling of "intuitiveness" comes from leveraging what your users already know, and when you contribute to a cohesive feel on a platform it helps reinforce that for every other app as well.

But at the same time, there's also no reason why your app's star functionality shouldn't be your own. Have hero moments. If we tried to bake that into the UI toolkit itself or into Holo it wouldn't be special when you need it to be.

Most importantly, the design guide should be seen as a catalog of solved problems, of UX wheels you don't need to reinvent. If you have unique functionality that you want to expose, don't just squint at the design guide until one of the patterns there looks appropriate. Make sure it's familiar enough that users can figure it out, but don't be afraid to make different things be different.


Your app's UI is its identity. It should be recognizable at a glance over someone else's shoulder as both uniquely yours and a great fit for the platform it's running on.

+Juhani Lehtimäki We have a few sessions at Google I/O this year you might be interested in, and as usual they'll be on YouTube later.
 
+Juhani Lehtimäki I, for myself, think that you shouldn't shove Holo down 2.x users' throats. They're not used to it. They don't know how to deal with it. It's, in a certain way, just like that God-awful iOS 1:1 ports. That's just not what you expect.
 
+Juhani Lehtimäki Oh I'm fine with (and encourage) Holo-based design for those devices too. I just don't want the stock Holo experience (buttons, checkboxes, action bar theme, etc.) for them.
 
I don't mind unique designs for Android apps, but doing a 100% copy of your iOS app and porting it to Android just says you're a lazy developer to me, and you probably didn't even bother to take advantage of some features that only Android has and optimize it for Android, but instead you tried to make it a sloppy copy of the iOS version, which means even in the best case scenario it's only as good as the iOS version, but more likely than not, it's probably worse. I think many other people feel the same way about about blatant iOS ports.
 
I agree completely. With Friendcaster I've been trying to strike a balance between designing an interface that is familiar and unique to Android while also looking for ways to make the app itself unique among Android apps. Part of Android's success on the design front will need to come from app developers/designers taking a more intentional approach with design and not just trying to perfectly mimic some guidelines. I also agree with +Lucian Armasu that it's usually bad when designers try to port iOS design idioms over to Android.
 
"Even if all you do is take the default action bar background and replace the blue line with yellow, red, purple, pink, or anything you've now started down the path of creating a unique look for your app."

Out of interest, is there a simple way to map the blue to some custom colour (maybe using some drawable xml) without having to recreate the pngs?
 
You may be able to accomplish this with a ShapeDrawable via XML but I've never done something that would purely create a line at the bottom. It would be pretty easy to just create an UnderlineDrawable which took in a color in its constructor that you could set on the action bar via code. This is how we create the customizable subtle gradient backgrounds on the action bar in Pay with Square so that it matches the merchant's desired color. Just make sure you're accounting for density when drawing the line!
 
I 100% agree with this. In fact, I'm actually starting to get sick of seeing 'ICS designed' apps as they all look the same. Variety is the spice of life.
 
This discussion has been really interesting. I find myself disagreeing pretty strongly in many places though. I don't think there's anything wrong with apps that ship with unmodified Holo themes. An Holo themed app is much better than random colors thrown together to do customisation just to look different. A plain Holo themed app looks good. It might be a bit boring but it looks good. I agree with Jake's point of view that unmodified Holo should not be forced on teams (and it isn't) that have skills and will to customise it but for app teams that either don't have skills or don't want to do it shipping a pure Holo visuals is a great option.
 
I like the clean slate of ICS but agree that it will get boring very soon. Google should do more to educate developers how to customize the theme and provide more example of cool themed apps.
 
"It is more important to adhere to the 'Pure Android' section than it is including every single pattern."
This is the most powerful point of a very well-articulated argument.
 
For some applications Pure Holo is the best way to go.
The most noticeable example is this new Tasks application:
https://play.google.com/store/apps/details?id=ch.teamtasks.tasks.paid

The choice for design and look similar to Gmail is appropriate here and the fact that it uses Holo on Android 2.x only makes the users like it more. Just take a look at the comments. I actually started working on a similar project but they beat me to it.

I agree that this shouldn't be done in most apps but IMHO for utility apps this is a perfectly acceptable choice.
 
+Jake Wharton On the subject of backporting Holo, I'd argue that the majority of users are somewhat familiar with it due to the Google Play client using it.
 
+David Lawerteh The Play client is one of the examples I give of what you should be doing since they are using a highly customized theme which has its foundations in Holo and the design guidelines.
 
I love the holo look but I am trying to make my apps stand out, I think adding to the holo while still keeping true to it is the best way to go, this way android will look like everything is integrated BUT designers wil still show of their amazing skills
Kris B
 
I'd love to deviate from the Android Guidelines, unfortunately working with layouts in Android is so frustrating that just getting basic layouts working is a huge feat.
 
+Mark Carter I did use xml to do this. I applied a huge padding to the top of a <shape> rectangle. It works perfectly. That this because I knew the height of the buttons (in dpi) before hand, though.
 
+Jake Wharton, do you allow me to translate this post into French, and post it elsewhere (my G+, plus my blog perhaps)?
Add a comment...