Over the years, Chrome has kept itself at a distance from other Google products based on its direction and visual choices. That’s because Chrome is actually supposed to be a vehicle for all of Google’s products and all of its creations. As a result, chrome’s brand and platform continuity has always blended or balanced with Google’s brand. This often leads to the question: Where do we fit in?
Review images
When Sebastien Gabriel, the head of Visual design for Chrome and a friend I spoke with at Google IO, saw his latest book detailing what the design process was like for a new version of Chrome for Android, I can also see some information about the development of Material Design in Google products and how it is applied. Many thoughts and details are first-hand news, very detailed, so I translate them to share with you.
When I started writing this article, I wasn’t sure how much I wanted to include. When he was finished, I wrote a long essay because I didn’t want to leave out anything I thought was important, so I split the essay into two pieces to increase the readability.
In the first part, I discussed the reasons for this redesign, Material Design (HEREINAFTER referred to as MD) and Chrome’s interactive and visual design philosophy. Then talk about our new styles, colors and icon graphics through a simple technical analysis.
introduce
A new version of Android called lollipop was released in October 2014, with many changes and MD based redesigns. More than just a guide to Android and a showcase of its best design practices, MD represents Google’s position and conveys its design and technical values.
And MD’s application expansion is not just Google’s proprietary, but every platform that wants to use the design language to make its products better. As part of our efforts to promote MD, and to keep our Google Apps and Apps up to date with the latest Design languages, a redesigned version of Chrome has been released in lollipop’s 40th update to Android: we call it Chrome Material Design.
Content, not browser
Over the years, Chrome has kept its direction and visual choices at arm’s length from other Google products. That’s because Chrome is actually supposed to be a vehicle for all of Google’s products and all of its creations. As a result, chrome’s brand and platform continuity has always blended or balanced with Google’s brand. This often leads to the question: Where do we fit in?
In addition, when it comes to making decisions in UX and UI product design practices, it can be summarized as three design concepts based on Chrome: speed, minimalism and security.
Review images
From left to right, they represent chrome’s design philosophy: speed, minimalism, and security.
And perhaps most important for visual and user experience: “Content presentation, not Chrome design.” The browser should always provide and deliver the most accurate and effective content possible, while minimizing the background design of the browser itself.
So the question is: how do you design an interface that looks as weak as possible and as easy to ignore when presenting content, while we can never outperform the content we provide?
I don’t know if we’ve found the answer, but we’ve made the choice. This article explains what we chose to do and why we did it when we redesigned Android Chrome.
platform
Now that the dust has settled, eight months after the release, I feel more sure to talk about how and why we did what we did. Not only does it serve as a retention file for a summary review that helps me jump out and analyze what I’m doing, but it also serves as a potentially usable resource for designers who need it. And with I/O 2015 just around the corner, it’s a good way to see how the Material Design language is becoming more and more mature. Good design takes time, and I hope that a year after the first release chrome has reached a satisfactory level.
But before I get started, let me talk a little bit about the Android platform. As you know, Android users are widely distributed across different versions of the system. Each system is named after a dessert. The latest system is Lollipop, the previous version was Kit Kat, and before that, Jellybeans.
Review images
I will mention only the three most recent versions of the system because they are by far the most widely used. The reason I’m talking about this is because we released Chrome on two versions of the operating system, one pre-L and one after L. These versions of Chrome, while visually similar, are based on a very different usability standpoint.
1. Content is king
Chrome is an information network about licensing and serving as well as we can. Chrome’s mission is to build the information web on top of new technologies that support the delivery of information and the way developers constantly improve their applications.
In the Lollipop OS release, the most important and biggest redesign of Chrome is not a new skin and look, but a deep change in how users process information through the platform, and how we drive the integration of the entire content.
| the only way is to chrome the “box” break apart it makes it a part of the android platform seamless connection.
Integrate tabs and system applications
To distinguish this iteration from previous versions, Chrome on lollipop is called “Merging tabs and Applications.” A very straightforward name to describe what we do. This conceptual effort was led by Roma(UX lead at Chrome). And I just did my best to describe my thinking, because I was mainly responsible for the visual side.
|, in short, “combination of tabs and application” is relative to the design of our browser UI to rely more on the platform.
Step one, take Chrome apart
We’ve separated chrome’s mobile side into a number of key pieces. New tabs, toolbars, url bars, toggles and menus. Set to level 2. These parts make up what we know as a browser, a stand-alone application that does not interact with other content and systems, which is fundamentally different from how native systems operate.
Second, the operation process is extremely simple
Switch design
The main problem with a standalone app is that it has no interaction with the rest of the platform. For example, if you’re running in a native app, and you want to go to a specific url to access and copy some information, you first need to close your app and then open Chrome or use the Native Android Global shortcut, click Chrome, go to chrome TAB and then really start what you want to do.
Review images
Chrome normal toggle. It can be used by turning off the Merge tabs and Applications function in the system Settings before Lollipop.
This situation is not particularly desirable either from a usability perspective or a rational one. Information, no matter where it comes from, should be extremely simple to reach. The solution is to equalize each process when combining Android local toggle and Chrome toggle. That means dismantling Chrome from one of the browser’s core features.
Review images
Chrome TAB and Android apps are combined in Lollipop into a unified Global Android shortcut.
The address bar
Now that toggling is fully integrated with Android, the relationship between chrome’s address bar and Google’s search box is clearer and more seamless. Before this change, typing a search into the Google search box opened a TAB in Chrome. Now launching a search opens an Android process, just like any other app, without being buried in an app.
Review images
Android Search
Review images
Start a search
Review images
Open search results
We have a lot of work to do in this direction, and a lot of features to do in the future to better integrate Chrome Info Network with android native platforms. While superficially simple, these Android Chrome features form the core of MD, even more than any embellishment or effort to add visual design. We’ve simplified Chrome content as never before.
Of course, this is mainly about visual design. Let’s briefly review where our UI positioning and version positioning are. We currently release two different versions of Chrome. Chrome’s tabs and system modules are incorporated in Lollipop and previous OS versions.
Review images
Lollipop before and after version
They share the same underlying code and execution, although they are very different technical locales. They also look visually consistent and are made from the same set of resources. This is where I’m going to talk about visual improvements.
2. Visual and overall motor effect
The visual design of Android Chrome was developed at THE time MD was working on it. As with any app that was redesigned for release, we needed to make sure Chrome was able to meet Google’s vision and direction while retaining its values and goals.
From the beginning we made it clear that Chrome would have to find a place between its brand image and the new and strong Visual language of Google, while keeping the UI as discreet as possible. This is not a small challenge for bold innovation MD.
Continuity problem
Chrome has made a lot of tweaks and trade-offs to stay consistent with the Google brand. We’re constantly going back and forth between Google’s image, and when you’re designing software that can be adapted and used anywhere, you have to take into account how products are perceived and interact elsewhere. How this fits into other platforms is key for us.
Thought process and philosophy
The redesign is the first since the mobile Browser was released three years ago. Google chrome’s UI is already light and mature enough that we have time to embrace change. When it comes to user experience and visual design, we tend to be sensible and deliberate. As with any product with a user base of hundreds of millions, small changes can make a big difference, and when a product iterates its UI as infrequently as Chrome does, every tiny change is worth noting.
| summed up our philosophy: is there an interesting is when people ask me what to do, I said Google browser design, the vast majority of people would ask me any good design of the Google browser.
Sometimes it’s a question of pure interest, sometimes it’s an innuendo, and I think it’s understandable.
| if someone think Google browser UI to a good design, it means that we did a good job.
Chrome has a fast iterative process, we iterate a small version every month, and this fast process benefits users more than it harms them. Fixing a product is as quick as launching a new feature. From a design perspective, this means responding quickly, organizing and understanding the nuances of our products so that we can produce new products in such a short period of time.
| Material design and the lollipop system gives us a chance to review the three years of interaction design, and makes us think about the next to Google browser can do.
We realize that this time Google Chrome on mobile and tablet will expand our platform from Android to iOS,OSX and Windows. It took us six months from design to implementation to launch in October. On the one hand, we have to take full advantage of the Google brand, on the other hand, we have to take into account the Material Design which is not officially released but still in development. Here are our choices.
Visual Design Direction
We used to say that for Chrome, “Add a little gray to the gray, and then a darker gray to make it look better.”
That’s mostly true. Google’s Browser UI is typically fifty shades of grey, since it’s hard to maintain neutrality once a color is selected. You can see how this collides with Material Design’s bold use of bright, strong colors. It was clear that we needed to mitigate Material Design’s influence on our designs and be very careful about where and how Material Design was used.
Define the Material design
Early on we debated how to define Material Design and how to make the most of it. The key criteria in Material Design are described below
“Material Design is a metaphor based on meaningful dynamic design and bold and purposeful visual expression”.
Review images
From left to right are “metaphorical,” “bold, graphic and purposeful,” and “meaningful kinetic effects.”
This is the philosophy of Material Design.
There is an unwritten broad definition of what Material design is, which basically means that anything that can better serve the design is reasonable. The point is that design needs to have understandable structure and simple kinetic elements and use them to enhance the experience, not simply to make the design beautiful.
Further details
While these guidelines seem inspired, they are not the whole story of the application, and if you look at the details of the guidelines you will see the technical elements that underpin the entire Material Design-based application.
8DP pages, 24 * 24DP ICONS, buttons without stroke, touch feedback and dynamic curves are just a part of the whole set of guidelines and can be used according to the specific situation.
After applying these technical recommendations you can start laying out your application’s skeleton. Choosing these technical rules is important to keep them consistent with the Google app ecosystem.
| we interface is so simple, so the brand and consistency are exist in every tiny detail.
But be careful about “choosing on a case-by-case basis. Because there are only a limited number of guidelines, and your design is not set in stone, it will evolve. As a designer, it’s up to you to make the best choices for your app.
A guide is a first step, a beginning, not an end.
Evolution and iteration of core style
Chrome’s core UI style iteration was carefully considered because we wanted the style to be integrated into the content.
Over the years, the changes to Chrome have been minimal or even noticeable to most users. The core UI is iterated about every two years. This will be the third major iteration.
Here are the first and second iterations of Chrome (PC).
Review images
The UI design of the first version of Google Chrome on PC (HD Browser Optimized edition)
Review images
Current version of Chrome (Windows)
Review images
Current version of Chrome (MAC, Mavericks)
Often the user will not notice the UI changes. Like the old UI in the first two screens and the new Windows UI, or a very subtle change, chrome’s UI is somewhere in between, and very few people will notice, which is a good thing.
In fact, if the user can still enjoy the product experience without noticing the change, it means we are doing well (both visually and from a user experience perspective).
Visually, Chrome follows a more linear and predictable evolution. In addition to platform consistency adjustments, there is consistency of graphics and colors, so we can define the content of the evolution:
– Sharper tabs
– Lighter color matching
– Reduce the engraving of ICONS in the toolbar
– Highlights and gradients have been weakened
Of course, the evolution of Google Browser is closely related to the evolution of the company’s overall visual style, as well as its own style and design principles for different platforms.
Redesigning the core UI takes into account the possibilities of all platforms, striking a balance between working for different platforms. We want to minimize design variability for maintenance and consistency reasons.
When we design for Android, we design with ios in mind, and vice versa.
In the third iteration, we went mobile first. These changes changed many of our original concepts and influenced the way we designed Chrome as we conceived it. Here’s the “graphics only” version on tablets and Phones.
Review images
New tablet layout (Nexus 7 screen ratio)
Review images
Old tablet layout
Review images
New Phone layout (toolbar and card-stack/switcher)
Review images
Old Phone layout (toolbar and card-stack/switcher)
As mentioned above, Google’s Browser is getting lighter and sharper and more accurate. In this third iteration, we dropped the strong drop shadow and tightened the rounded corners of the TAB bar slightly. At the same time, we increased the size of the toolbar, TAB bar, and card title. Ditching the “dog ears” makes the UI much more readable and dynamic. As for the multibox, we also put some thought into the projection. Change the vertical projection to a closer fuzzy projection
All things are difficult at the beginning. At first we need a lot of ideas, a lot of back-and-forth, a lot of things to do at the same time. The easiest thing to do in this process is to match colors.
The first thing we made clear was that we wanted to make the UI lighter. The first iteration was darker and heavier. What we need is a lighter and brighter gray but not completely white, so we can have contrast. This is especially important for a deep UI on a tablet. That’s the depth of this UI.
Review images
The core part of the UI from previous versions
When we think about color schemes, we avoid thinking purely in terms of platforms, but also in terms of consistency, and we try to make Chrome permeable everywhere and into every detail.
The color of the toolbar on the Phone should be as close to the toolbar as possible, or even closer to the desktop version.
For the first time with this in mind, we tried the all-white Google Browser and relied on lines and shadows to distinguish elements. The Browser interface is completely “paper”.
Review images
Try an all-white (# FFFFFF) desktop Google browser
This attempt was not satisfactory and had to rely on lines and projections to emphasize the differences between elements. This UI is not elegant enough for the Android platform. The final result, as shown below, is a compromise between the bold all-white interface and the old grey one, and a reduced shadow effect.
Review images
We now apply color matching to the entire application to avoid excessive colors due to rapid iteration. Remember I mentioned fifty shades of grey? This is the color scheme before we do “tinkering”, from the core color combination of “Holo” :
Review images
This was obviously not what we wanted, but fortunately we reduced the color scheme and ended up using a new color scheme, which may still be a bit inadequate, but it will be corrected over time.
You may have noticed the “toolbar invisibility theme”. This was one of the big changes in the visual design, and in this iteration we redesigned the invisible skin. Besides the new ICONS, the color was the most significant change.
Review images
Review images
Stealth mode and normal mode with new color scheme
Stealth mode brings the concept of theme to mobile. Users are used to themes in desktop applications, so we will try to minimize the differences between the two platforms in the Phone version.
Developer controls color matching
It’s better to make the content look better than the theme. This is one way to make Chrome more invisible.
Web pages can use Google chrome’s custom themes by marking them with color in the transform TAB. For example, here’s the Medium app with the transform tag:
Review images
The site automatically ADAPTS to the browser theme, not only switching to theme mode, but also changing the color scheme of the card
From a design perspective, we define two patterns: general and thematic
In this case we can set up two different design styles. One emphasizes a light base, like #F2F2f2, while the other emphasizes a darker palette, like #505050.
We’ll talk more about this later, but it’s important from both a technical and asset management perspective, since we have two versions of the theme.
Note that changing labels only takes effect under “Merge tabs and applications”; all other versions use the regular theme when the tabs are fused with the system.
Our original concept is shown in the picture below:
Review images
This method has been tweaked after trials on various websites, but the general principles remain the same.
Once you decide on a bright or dark theme, the colors and configuration will change. Initially we provided two different configurations for stealth mode, but the engineers made adjustments so that they could adjust the ICONS themselves to reduce the size of the pack.
In addition to making ICONS whiter, the multifunction bar has been made more transparent to better fit the theme, and the security icon has been changed to reverse color, as well as url address color.
The dribble site, for example, uses a transform tag under the same icon.
Review images
Icon design
ICONS are much more straightforward, and of course not without a thought process. The ICONS in Google’s core UI haven’t changed much over the years, and changes to the secondary UI (toolbars, conversations, etc.) haven’t had a clear direction.
This redesign gave us an opportunity to reposition the Google Browser icon.
At the time, Material Design still determined the design direction of the system’s ICONS — ICONS with continuity and smooth shapes that could be used by anyone.
Before that, we had the problem of finding continuity in the brand image, the Google brand, and other visual specifications of the Google OS.
Fortunately, the icon design method in Material Design is universally applicable, and in my opinion it has been very successful.
When we created the new Google Chrome icon at the time the Material Design system icon guidelines were in place, fortunately the end result was uniform and, crucially, the same stroke value was used.
Review images
Icon design framework, rounded corners and stroke specifications
You can already see the difference between the Material Design specification and the Google Browser UI icon.
Review images
On the left is the return icon in Material Design and on the right is the return icon in Google Chrome
We chose rounded corners instead of square ones.
The reason is that the Browser visual design specification had rounded corners when we designed the icon. This is also to make some distinction between Chrome and something like the one below.
Review images
The Google + top bar on the Google Tablet. As shown, we still choose to represent the menu with three dots
The Google Browser icon is broken down into modules and specifications, with ios and Android platforms using one specification and OSX, Windows and Google OS using another.
Currently, only mobile platforms follow the Material Design specification.
Our criteria and module classification are as follows:
[Main UI] – Toolbar, TAB bar
[Function box] – In the function box
[Info bar] – Any information presented to the user
[Site Settings] – Allows ICONS and Settings to be applied to content
[Settings] — Google Settings icon
[Other] — icon used occasionally
Each icon is manually adjusted to be accurate to each DPI.
Here are a few examples of major UIs, feature boxes, and information bars:
Review images
Main UI ICONS
Review images
Multifunction bar icon
Review images
Information bar icon
As before, each icon has a different color for different states:
– Normal + Active + Inactive under the default theme color
– Customize the normal, active, and inactive states under the theme color
Google Material Design requires each colored icon to be its own set, with one color per set, which allows for thousands of colors, including various colors and DPI.
Now that we code the color values, we end up just generating the icon/DPI to reduce the impact on the final package size, and also reduce the number of design resource sets.
To continue, please look forward to PART2
In this paper, byProduct 100Recommend and present to you
Article source: wechat official account MIX Wireless Design (Alibaba-MIX)
Author: Sebastien Gabriel
Shinodeer Zen Winter
Friendly tips:
If the source of error, please contact QQ: 2977686517 timely correction, thank you for understanding and support!
Teenagers follow our official microblog @product100 and wechat subscription number: Chanpin100ghsd, there are surprises!
Review images
Summary of Google Browser redesign ideas