Understanding Android Adaptive Icons
Android O introduces a new format for app icons called adaptive icons. To better understand the motivation and potential of this feature it’s useful to take a look at what it’s replacing.
While Android’s icon guidelines have evolved over time, they have always promoted using unique shapes. I was a huge fan of this! I held that it really helped users to locate the app they wanted to launch. If you want to get nostalgic you can listen to Roman Nurik and I talk about this to 6 whole minutes in an old video we made.
Here’s the ‘traditional’ icon (created by Roman) from Plaid, an app I work on. I believed that the distinct shape helped it to stand out, making it easier to find:
But it’s not all sunshine and rainbows in distinct-shape-icon-land. The flipside of this near-complete creative freedom is lack of consistency. When each individual app is responsible for shape, size and drop-shadow (which is baked into the icon) then the inevitable consequence is that they vary widely. Here’s an example of icons just from Google showing how they at one time varied:
Now admittedly the above image is from 2012 and things have improved a lot in the meantime; especially with the extra guidance in the material guidelines. Nonetheless, I’ve come to believe that the current system places too much responsibility on app developers; giving us too much scope to detract from the overall experience..
When we’re working on an app, we can become laser-focused on it. We rightly spend huge amounts of time pouring over the details that make it unique. We think about it in isolation. But that’s not how users see it; no app is an island and we need to recognize that it exists alongside many other apps on a device. As such it needs to get along. This is true for your entire app but it’s all the more important with elements like app icons which appear side by side. With this framing we can see how instead of our idealized situation, the reality often ends up being more like this:
In response to this problem, a whole cottage industry has sprung up: custom launchers offering icon packs to replace app’s icons or normalize their size. Devices also started shipping with launchers adding backgrounds to app icons to enforce consistency & brand their platform.
Indeed Google’s launcher will start placing icons of apps which target Android-O but do not supply an adaptive icon onto a background (scaling down their non-adaptive icon).
While normalizing icon shapes or sizes is understandable, altering an icon without input from the app developer can’t lead to the best outcome.
Android 7.1 introduced
roundIconas an attempt to bring some consistency here but this was pretty restrictive to OEMs looking to differentiate their devices (i.e. only supporting circular icons) and lacked any kind of validation (developers could supply any shaped icon and pinky-swear that it was round!).
I’d characterize the situation as lacking a well defined contract between the app icons and launchers which will display them. Balancing the complete freedom of icon design against a desire for consistent display currently places responsibilities in the wrong camps. Launchers try to resize icons but don’t understand the content, like which elements are critical and shouldn’t be touched. App icons need to keep up with any guideline changes to ensure they bake in correct sizing/padding or shadow information. I see adaptive icons as making this contract clearer; becoming more explicit about what an app must supply and how a launcher will consume and display it.
For icon makers, it’s easy to see this as losing some freedom. I think this is actually more of a shift rather than a reduction. Adaptive icons introduce new and interesting constraints that open up new creative possibilities. Join me in part 2: designing adaptive icons to explore these.
