Redesigning Chrome Android. Part 1 of 2
Content, not Chrome
Preliminary notes: When I started writing this article, I didn’t know how much detail I wanted to put into it. As it turns out, it is quite lengthy and since I didn’t want to omit things that I judge important, I decided to split it in half to make it more readable.
In this first part, I talk about the reasons of this redesign in sync with Material Design as well as Chrome interaction and visual philosophy. I then start scratching the technical surface to talk about new styling, color scheme and iconography.
Introduction
October 2014 marked the release of the new version of Android: Lollipop. Lots of changes under the hood and a pretty big redesign brought to users under the name “Material design”. Not solely an Android guideline and best practice guide, Material design (will be referred as MD from there) represents where Google stands and communicate its values in design and tech.
Additionally, MD extends not only to Google properties but to anyone, on any platform (with the Polymer-project.org for the web for example) for anybody willing to embrace and iterate upon it to make their own product better.
As part of this effort to bring our apps up to date an consistent with the new visual language, the redesigned version of Chrome was shipped in Lollipop for its 40th update (M40) or as we call it: Chrome Material Design.
Content, not Chrome
Throughout the years, Chrome stood a little bit apart from its other Google product counterparts when it comes to its visual choices and directions. This is mostly due to the fact that Chrome aspired to be the “shell” that contains both Google products and well… everything else. As such, branding was always a balance or a mix between the Google brand, its own Chrome branding and platform consistency. This often led to the question: “Where do we stand?”
Other factors come into play when taking UX and UI product decisions and they can be grouped under the three key Chrome principles: Speed, Simplicity and Security.
An additional one, and perhaps one of the most important when it comes to visual and UX is:
“Content, not Chrome”.
The browser should always support and delivers its content as subtly and efficiently as possible while fading in the background.
So the question is: How do you design a UI that is supposed to be as minimal and forgettable as possible while demonstrating our new visual direction without ever overpowering the content that we are here to serve?
Well I do not know if we ever found the answer but we did have to come up with choices. And this article is what this is about, trying to explain choices and reasons that came to be the Redesign of Chrome for Android.
The platform
We’re now eight months after the release (I’m writing this in May), and now that the dust settled a bit, I feel more comfortable talking about how and why we did things. Both as a postmortem documentation that helps me take some distance and analyse things as well as a potentially useful resources for designers out there. Plus, with I/O 2015 behind us, it’s a good way to see how Material design matured. Good design takes time and I’m hoping we reached a satisfying version of Chrome, a year after the very first draft of the new version.
But before we start let’s talk about the Android platform.
As you may know, Android user base spreads among multiple versions. Each version is named after a dessert, the current version, L stands for Lollipop, the previous version, K for Kit Kat and before that J for Jelly bean.
I mentioned only the three latest versions as they are the most widely used.
The reason why I’m talking about this is that we delivered two versions of Chrome, one for pre-L and the other for L and beyond.
These versions of Chrome, while similar visually, are and will be drastically different from a usability standpoint.
1. Promoting the web as first-class citizen
Chrome is all about empowering and serving the web as good as we can. Beyond delivering support for new technologies and ways for developers to enhance their applications, its role is to put the web on a pedestal.
One of the biggest and most important part of the redesign of Chrome for Lollipop wasn’t the fresh coat of paint but the deep change in how users will approach the web on the platform. How we would put the web forward.
One way to do it was to break Chrome out of its “box”, take it apart and make it a more seamless part of the Android platform.
Merged tabs and apps
To differentiate this iteration from the original, Chrome in the L environment would be called “Merged tabs and app”. A pretty straight forward naming that describes well what is happening. In the current version of Chrome for Lollipop settings, you can find it under “Merge tabs and apps”.
This effort was conceptualized and lead by Roma Shah, Chrome UX lead.
I only describe the thinking the best I can as my responsibility was on the visual side.
Simply put, “Merged tabs and apps” is our effort to design ourselves, designers out of a job, by relying on the platform rather than our UI.
Step 1, taking it apart
We can split Chrome mobile into key features. The New tab page, the Toolbar and URL bar (omnibox), the Switcher and the menu. Settings being secondary.
Together, these features create the browser as we know it, a separate app distinct from the native core platform working more or less in a vacuum.
Step 2, removing the biggest point of friction
The switcher
The problem with an app running in a vacuum is of course how it interacts with other elements of the platform. Short answer is that it isn’t optimal. If you are working on a native app, let’s say taking a few notes for a trip you are going to make and you need to access a certain site to get and copy some info, you need to either close your app and open chrome or navigate the Android recents switcher, tap chrome, dive into Chrome own tab switcher and then start to actually do what you want to do.
This situation is not optimized both from an usability standpoint as well as from a more philosophical standpoint. Information, whatever its source is, should be as easily accessible.
The solution is to make every document equal by merging the Android native switcher and the Chrome switcher. This means stripping down Chrome from one of its core feature.
The omnibox
Now that the switcher is fully integrated to Android’s, the Chrome omnibox relationship with the Google search box will become more obvious and friction-less.
Before this change, entering a search in the system Google search box opened a tab inside Chrome. Now, triggering a search will open an activity in the Android recent stack, at the same level of any other app, not buried inside one.
I voluntarily restricted the changes to this one major, very visible one. There is a lot that has been done under the hood and a lot of more thing that needs to be done in the future to blend the Chrome (web) platform with the Android (native) platform even better.
While very simple in appearance, these features with Android Chrome constitute the essence of Chrome Material design, even more so than any polish and visual design tweak that might be added. We went further than ever in reducing the chrome of Chrome and putting the content first.
But we’re here to talk visual design, mostly. Let’s just take a step back and look where we are UI wise and version wise. we are now left with two different Chrome versions. Merged tabs and apps mode, working on Lollipop and regular, working on every previous version of the OS.
While very different technical wise, they share the same codebase and implementation. They should as well be visually consistent and built from the same resources and that’s what I’m going to talk about on the visual revamp part of this article.
2. The visual and motion overall
Chrome Android visual redesign happened at the same time Material design was being developed. Like other Google apps that needed to be redesigned for the release, we needed to make sure that Chrome was fitting the new Google vision/direction while staying true to its values and purpose.
What was clear from the start is that, as usual, Chrome was going to have to find its place between its own branding and the new Google strong visual language while making sure its UI is as discreet as possible. This was quite a challenge considering that Material design is all about boldness.
The consistency conundrum
Positioning Chrome in the consistency spectrum with the Google brand is made of constant adjustments and trade-offs. It’s made of constant back and forth and trade-offs between its Google identity, the platform identity on which the end user sees it and its own identity.
When you design a software that is supposed to be deployed and recognizable everywhere, you cannot design in a vacuum without thinking of how the product is going to be perceived and impacted elsewhere.
How is this going to be translated on other platform is a key question for us.
Thought process and philosophy
This redesign was the first one of its kind since we released Chrome mobile three years ago. Chrome UI is light enough and mature enough that we usually have time to see changes coming. We also like to be very rational and careful when it comes both to the UX and the visual design of our application. Like every product with a user base in the hundred of millions, changing the slightest little thing can have quite the impact, and when you have the minimal UI footprint that Chrome has, they are really noticeable.
One funny anecdote that sums up our spirit quite well is this:
When people ask me what I do and I answer designing Chrome, I often get the question “What is there to design in Chrome anyway”?
Sometimes this question is genuinely interested, sometime it’s simply a snarky comment and that’s ok.
If somebody is wondering what is there to design in Chrome, it means we’re doing a good job.
Chrome has an iterative process, we have branch points every 4 weeks that gets a new version of Chrome pushed through its 4 levels or versions from unstable (canary) to stable (the one everybody uses).
This sort of fast paced process has more benefits for the user than downsides. Fixes go through fast while new features are introduced just as fast. On the design side, it means being reactive, organized and knowledgable about every little aspect of our product so that we’re ready to deliver something in a short timeframe.
Material design and Lollipop gave us this opportunity to take a look at three years of iterative design and force us to wonder what will be the next Chrome.
We realized that this version of Chrome mobile and tablet will guide our choices everywhere else, not only Android but also iOS, OSX and Windows.
We had 6 month total from design to implementation and m40 release on October. We needed to make the best out of our branding, Google’s branding and the still yet to be announced and still working in progress Material design. Here are the choices we made.
Visual directions
One funny thing that we use to say is that the Chrome primary color palette is “grey with a bit of grey on top of it and a darker grey to make things fancier”.
This is not too far from reality. Chrome UI is quite literally fifty shades of grey as you cannot go more neutral when you pick a color. You can see how this can clash with the concept of Material design that is supposed to be bold and use bright and strong colors.
It appeared clear to us that we were going to have to mitigate the impact of MD on our redesign and that we were going to be very careful as for how and where we would apply it.
Defining what Material Design is
A debate that started very early in the process was to actually define what was MD and how to apply and make the best use of it in Chrome. The key principles as described in the Material design spec are as follow:
“MD is a metaphor with bold and intentional visual supported by meaningful motion design”
That’s for the philosophy of it.
A voluntarily broad definition of what it is that you can interpret as you see fit as long as it serves your design better. The gist of it is that your design needs to have and understandable structure, simple and obvious actionable elements with motion design that is here to enhance the experience, not simply to make things shinier.
Diving in the nitty gritty
As inspirational as they may be, these principles won’t make your app by themselves and when you start to look into the details of the guideline, you can find a ton of technical elements that form the backbone of a Material design app:
An 8dp based layout, 24x24dp icons, borderless buttons, touch feedback and specific motion curves are part of a very thorough set of principles that you can apply if you so choose.
By applying these technical recommendations, you can start laying things down and the skeleton of your app starts to appear. Picking these technical rules was an important step for Chrome to be consistent with the Google app ecosystem.
Because our UI is so simple, the branding and consistency would live in the little details.
Side note. I used “if you so choose” very intentionally. There is only so much a guideline can do and as everything else, including your design, it is a living and evolving thing, not something set in stone. You as a designer are the one making the best choices for your app.
A guideline is a first step, a kickstart, not a finality.
The evolution of the core style
Chrome evolves carefully when it comes to its core UI due to our constant will to make the chrome disappear in favor of the content.
Over the years Chrome changed slightly and sometimes un-noticeably at all for most of its users. The Core UI evolves aproximately every two years. This version would be the third big one.
As a reminder, here’s the transition from the first core UI to the second, on desktop.
Usually users do not see the transition between our UI states. May it be a big overall like the old UI vs. new Windows UI in the first two screens or very subtle changes, Chrome UI feels so neutral that very few people notice it. Which is good.
In fact, if users do not notice the changes and tweaks but are still enjoying the overall experience, it means we did a good job. Both from a visual and UX standpoint.
In term of visual style, Chrome is following a rather linear and predictable evolution. Platform consistency tweaks aside, shapes and color scheme remains consistent throughout and we can define areas of evolutions:
- Tab are getting sharper
- Color scheme is getting lighter
- Icons are getting less “etched” in the toolbar
- Highlights shadows and gradients are being toned down
Of course Chrome evolution is also bound to our industry’s visual style evolution and each platform own style and guidelines.
Giving a fresh coat of paint to Core UI is taking all platform in consideration at once and find the harmonious set of shapes and the right balance of elements that will fit each platform. We try to reduce the differences to a minimum due to maintenance reasons as well as consistency reasons.
I could come as astonishing but when designing Chrome for Android, we designed it with iOS in mind, and vice versa.
For the first time in this third iteration, the redesign would be conceived and implemented on mobile first. This shift in the way we conceived Chrome shifted a lot of pre-conceptions and impacted our approach on the design. This below, is the final “shapes only” version of Chrome tablet and phone along with their previous version.
As aforementioned, Chrome is sharpening and getting more precise while getting lighter. In this third iteration, we got rid of the strong shadowing and tighten the rounded corners on the tabs a bit more.
We also let the UI breath a bit more by increasing the size of the toolbar, tabs and cards headers. We also got rid of the “dog ear” on them, which makes the UI both more readable and the animations better.
Regarding the omnibox, we also worked on the shadowing to give it more detail. It’s not longer a straight drop shadow but a combination of a close shadow and a more blurred, diffused one.
Again, the difference is not striking, we prefer iteration over redesign.
The color scheme
The process was a bit rough at the beginning. We needed to flush out ideas and move things around and play with various things at the same time but a something that we got relatively easy was the color scheme. After all it would just be a matter of finding a shade of grey and an accent color.
The first thing that was sure is that we needed to lighten the UI. The first iteration of Chrome mobile was darker and stronger. We needed something higher in the grey spectrum but not quite white so we would be able to achieve contrast. This is especially important for the tablet mode where there is depth to this UI.
When we think of Chrome color, we try not to think of it from a single platform perspective, consistency is a constant consideration and we try as much as possible to get the same Chrome “feel” everywhere, in as much detail as possible
The Phone toolbar color should be as close as possible to the tablet toolbar color, itself even closer or similar to the desktop one.
With that in mind the first exploration we did was to go all the way in the white by trying and see what a full white Chrome would look like, relying on strokes and shadows to separate the elements. Chrome would be entirely made of the “Paper material”.
The result wasn’t satisfying as we had to bump up the strokes and shadows to get a good contrast between the elements. it resulted is an inelegant Core UI that wasn’t going to fit well on Android not on iOS.
The final result is the very restricted and simple color scheme you see below, a compromise between a bold all white version and the old grey with less dependance on the shadowing.
We now enforce this color scheme throughout the entire app to avoid the previous situation of too many different shades due to fast iteration. Remember when I was mentioning fifty shades of grey earlier? This is what the real color scheming looked liked before the revamp, deriving from the Core “Holo” color scheme:
This is a situation you do not want your app to end up in, unless it’s intentional. We successfully reduced the spectrum of color we used thanks to the new color scheme in the revamp, even if there is still some rough edges here and there, they’ll be corrected over time.
You might have noticed a line call “toolbar incognito theming”. One of the very striking changes in Chrome visual aspect with this update is the total re-skinning of the incognito mode. Besides the new icon, coloring is where the change resides.
Incognito introduces the concept of “theming” to mobile. While theming is something that our desktop users have been used to for quite a while, we took a slightly different approach to the concept for our Phone version.
Developer controlled coloring
What better way to blend in with the content than to let content owner theme Chrome the way they see fit. Another step toward making our Chrome invisible.
By specifying a color in the meta tag, a site can customize the Chrome shell. For example, if Medium did it using the meta tag:
<meta name=”theme-color” content=”#000000">
From a design perspective, we distinguished two modes: the regular mode and the themed mode.
By doing so, we’re able to classify two set of assets. One that works on extremely light background, like our #F2F2f2 toolbar, and one that works on darker colors, like our #505050 toolbar.
We’ll get to that later but this is important from both a technical and asset management perspective because now we have two version of the same app as well as two theming.
Note that the meta tag only works in the “Merged tabs and apps mode” version of Chrome, when tabs are merged with apps, all other version will use regular theming.
The way it was defined and conceptualized at first was as shown below in the initial spec created by Roma.
The values evolved a little bit from this with a few tweaks after trying it out on various sites but this is the basic principle.
Once we’ve determined if the site uses either a light theme or a dark theme, we color and change the assets accordingly. At first we had two separate set of assets for iconography but our engineering team made it so they could color the icon themselves, reducing the icon impact on the .apk size drastically.
Besides the icon set getting white, we also changed the omnibox to be transparent so it blends it better with the theming, we changed the security icons to their inverted versions and change the URL color scheme as well.
Here’s an example with the Dribbble site, which uses the meta tag along with a sample of icons.
Iconography
How to treat icons in the app was a bit more straight forward, although required its share of thinking. Over the years, Chrome iconography didn’t change much in it’s Core UI and when it came to secondary UI (toolbar, dialogs, permissions, etc…) there wasn’t any clear direction, creating a patchwork of style aggregated over time.
This redesign was an opportunity to recenter the Chrome iconography around a common language.
At the time, MD was still defining the final direction for the system icons which became this big set of consistent and polished icons available for anybody to use.
More than ever before, we faced the issue of consistency within our own brand, the Google brand and other OS’s visual direction.
Thankfully, the new MD iconography is intended to fit everywhere and is pretty successful at that in my opinion.
The new chrome icons were created at the same time the final guidelines for MD system icons was being determined, thankfully we ended up doing the same thing and most importantly using the same weight for our icons.
You may notice a little difference when it comes to Chrome primary UI icons compared to MD’s recommendations.
We went for rounded corners instead of rectangular.
This is due to the time at which we created the icons as well as Chrome pure visual directions as we historically had rounded corners. It is also an (admittedly) very subtle way to differentiate Chrome from the content like the following.
Chrome iconography is split into sections and buckets that are shared throughout platforms, iOS and Android having a common bucket, OSX, Windows and Chrome OS having a different one.
Currently, only our mobile platforms follow Material design spec.
Our sections per bucket are defined as follow:
[Primary UI] — Toolbar, tabs
[Omnibox] — Inside the omnibox
[Infobar] — Anything that is prompted to the user
[Site settings] — Permission icons and settings applied to content
[Settings] — Chrome settings icons
[Misc] — Occasionally needed icons or feature icons
Each icon are created and verified manually per DPI.
Here’s some example extracted for the source files (.sketch) for Primary UI icons, Omnibox icons and Infobar.
As you’ve seen before, there is quite a lot of color variation for each icon:
- Normal theming normal + active + inactive
- Themed normal + active + inactive for a total of 6 variant.
The first implementation of Chrome MD needed each colored icon as a separated assets, one per color, making the asset count reach beyond the thousand, all color and DPI included.
Now that we are coloring the .pngs in code instead of generating additional assets, we end up only having to generated icons per DPI which reduced drastically the assets impact on the final .apk as well as the number of asset in our design sources (6 times less).
[To be continued…]
This concludes the first part of this article. In the next one, I’ll talk a bit more about layout and grid, motion design as well as speccing and pure technical details regarding software used and asset generation.
If you want to connect, feel free to follow me on twitter @kounterb.
If you want to connect with Chrome team members involved in our mobile effort: @alanbettes, @codysielawa, @peteschaffner, @alexainslie, @gmurphy, @mano1creative, @cleerview, @romafied.
If you missed Google I/O 2015, head to the official site to catch up on all the interesting presentations. Also, the new google.com/design site is up with the updated MD guidelines.
