Redesigning Chrome Android. Part 2 of 2
Layout, UI and motion design
Preliminary notes: This article is the second and last part of the “Redesigning Chrome Android” series. It is the direct follow up to Part 1, so I really recommend you read it first before continuing.
In this part I will talk layout, grid usage, tablet layout, motion design, and we’ll dive into the tools we used, the way we spec’ed things as well as the way we handled asset generation.
Layout and UI design, phone and tablet
High-level principles and phone layout
Chrome is following material design to the letter when it comes to core layout principles. MD offers a very detailed grid system that values spacing and comfortable touch targets. The 8dp grid is a good base to build on, and as long as you do not break it unintentionally, you shouldn’t encounter spacing issues, making your design easily scalable.
Additionally, following a strict grid like this one allows you to be safer when it comes do PPI and multipliers and helps you avoid constantly having to check your measurements when adapting your design to various screen densities.
In Chrome, we are extremely conservative when it comes UI prominence over content.
Part of the “Content, not Chrome” motto is minimizing the footprint of the UI elements as much as possible.
That being said, minimizing the footprint doesn’t necessarily mean reducing the amount of pixel and spacing between elements to a minimum.
In a lot of cases, minimizing the visual weight of the app UI is actually lessening the negative impact it can have on the user’s attention and focus. This can mean making the visual affordances bigger.
In practice, creating a crowded, small, icon-heavy, unevenly spaced out UI will make it harder for users to accomplish simple tasks. Over time, this creates a state in which the UI feels “wrong somehow” even if the visual design is not bad per se.
This brings me to my point, MD introduced a bigger spacing grid than the initial one we had when designing under the Android Holo guidelines. The touch target of 48dp remained the same, but the default toolbar size as well as general spacing got bigger. It’s a natural and welcome evolution considering that our devices’ screen sizes have been consistently increasing year after year, reaching a stopping point of around 6" today.
Let’s start with the phone, non-merged tab situation.
The static mock-ups for Chrome Android were created based on the Nexus 5 screen size and PPI. A resolution of 1920 x 1080 in a 2.4*4.3 inches screen which gives us a PPI of 450 and a multiplier of 3 (xxhdpi). I you are looking for a handy site that figures all that stuff out for you, head over to the Google Design device metric page.
Thanks to the grid and icon guidelines, we were able to iterate directly on a 3x based design without having to constantly triple check all the measurement.
Let’s see how the image above looks with the actual specs and MD grid. We use bitmaps for our elements, so the first thing we need to define is their footprint and the grid. For the icons, we used the 24dp MD base layout.
We wanted to find the right visual balance based on MD before defining touch targets, so we settled on a 40dp height omnibox that would fit well with a 8dp padding left top and bottom in the 56dp toolbar. This 40 dp size, as a multiple of 4, would also play nice with the security indicator inside the box, allowing another 8dp of visual padding around it.
You might have noticed that the menu (3 dots) icon is rectangular instead of being a square, this throws the grid off a bit. In this case, we maintained the MD padding of 16dp and in-between icon spacing of 24dp. Going off grid makes for a lot of double checking, but it’s usually fine as long as you keep track of the padding between elements and make sure you’re consistent.
Touch target are based on the default MD guidelines, which are based on default Android guidelines, 48x48dp. Below is an extract of the metric & keylines guidelines.
Here they are applied to the Chrome toolbar. While 48 x 48dp is a recommendation, it is not a final value, and when you have the opportunity to go beyond that, you do. In this case, we extended the touch targets to the edge of the 56dp toolbar.
A mistake that I made early on while speccing the toolbar is to only define icon to icon spacing, not the spacing related to each icon’s touch target as you’ll see later in the spec section of this article.
Defining the touch target is actually more useful than using the icons’ bounding box. engineering won’t have to do guess work when it comes to the placing of your icon inside the touchable area.
Secondary touch targets, such as the security lock were purposefully reduced to avoid cannibalizing the -more important- omnibox one.
The Chrome menu is custom build and defers from the default MD guidelines. Instead of using MD’s “attic” menu, we use a classic overlaying menu, which is lighter and faster to display and dismiss. On top of it, we add a row of primary actions that align with the toolbar actions underneath.
We used the recommended 48dp row height and spread them out based on three equal touch targets. See below.
Diving deeper into the features, one of the most important is the omnibox, or search bar, where we aggregate both regular URL queries and search queries to deliver the best answer possible.
For this version of chrome, we really wanted to give it the maximum breathing room, especially compared to our previous versions.
Using one of Material design paper property, we expand the omnibox background out of the screen bounds and cast a stronger shadow over a full bleed dropdown. We also remove as many icon as possible to focus on the results. For example the “page” as well as “ history” or “search” icons are gone to let the user focus on the actual result without un-necessary visual noise.
We again used the grid and MD spacing with a 56dp line height for double lines and 48dp line height for single lines.
As you can see the “x” button as well as the arrow button used to append search queries are placed in a very expected way, aligned on the Material design grid. Using a row height of 48dp makes it very easy to align them with 48x48dp icon touch targets.
Similarly and to avoid too much finger travel when hitting the switcher button, we use the same icon disposition for the card stack.
We changed the tabs from having a “dog ear” to a more touchable and clean top bar. We removed a lot of of the inner and outter shadowing and reduced the tab containers to make them lighter. We kept the containers’ border, however, for better visibility when it comes to differentiate the various tabs from one another, displaying an infinite array of different content.
While this part of the interface is a sliding card stack, a non-default Material design UI paradigm, applying the layout specs remained possible.
The top icon placement remains consistent with the normal top bar spacing and we increased the cards’ top bar to 48dp so they become both more touchable and allow more space for the 48dp recommended icon touch target.
Note that we defined the tabs top bars as being stretchable in width but not in height so touch target stay consistent and expected when there is two stack available like below (normal and incognito stacks) as well as when it resizes to fit any kind of Android device. The card height and width changes, but the top bar remains at the same size, in the same position.
Speaking of stretchable or “fluid” layout, we use the same sort of behavior for our “New tab page,” another core feature of Chrome.
There are two primary elements of this starting page, the Google search bar with its Doodle, and the grid for most-visited pages, right underneath it, that mimics the aspect of our cards in the switcher card stack.
Let’s look a bit more closely at these two elements.
The grid for most-visited pages
We use a 2x3 grid of rectangular elements to display them.
An equal percentage of the screen (rather than a fixed amount of dp) is attributed to the padding and inner-padding surrounding the most-visited thumbnails, so the UI is scalable to the large number of Android screens, while keeping the same ratio.
Personal note here, the dp to % translation was calculated by engineering as well as a lot of the initial behavior, as I spec’d for fixed sizes initially.
We compensated the weakness of my initial spec work by going back and forth and a lot of tweaks to get it to the right spot. Lesson learned: make your developers’ lives easier by providing a spec that is actually useful! :)
For this particular grid, we felt comfortable having a minimum padding of approximately 16dp on each side of the grid, as well as between the grid elements. This estimation is based on our Nexus 5 test device.
We now need to translate this padding into a workable percentage:
The Nexus 5 is a 1920* 1080px screen with a 3x PPI multiplier. Therefore we need to find what percentage of 1080 48px (16dp*3) is :
48/1080=0.04444
0.04444*100=4.44%
Add to this other parameters, such as maintaining the same ratio for thumbnails (in this case 6:5) as well as adding a minimum padding between the bottom of the search bar and the first row of item, and you will get the working and flexible grid below:
The Google search bar + omnibox
The second main feature of this page, and one of the most thought through, is the interaction between the Google search bar and the omnibox.
A point that is sometimes hard to get across to our numerous users is that Chrome’s omnibox is a place to both type a URL or do a direct Google search. Getting people to understand this instead of going to Google.com to start their searches each time is really important from a UX standpoint and it’s a big time saver for the user.
One of the UI solution for this was to have a single, Google branded search box on our starting page as well as an automatically updated Doodle, synched with the one from from the Google.com homepage. The second step was to visually make the Google search box merge with the Chrome omnibox users are used to seeing at the top of their screen, encased in its grey top bar.
For this last part, we used motion and transformation to make them visually and conceptually merge:
Scrolling up
Each time the user scrolls up from the most-visited thumbnails, he would see the google search bar slowly merge with the chrome top bar. Up to a certain threshold, we snap the bar in place so the user doesn’t have to do too much finger travel to get to this state.
Tapping
When the user want fast access, he can directly tap the box, it will automatically go up, span across the screen and merge to the now familiar “full-bleed omnibox search state”.
I could go on and on about the phone layout, but let’s cut here, take a step back and look at what we ended up with before implementation: a set of “key-screens” that will serve both as layout spec and motion base.
While the conceptual phase, motion phase and development phase overlapped over time, constantly impacting each other, this was roughly the starting point of what would become the redesign: the core “skeleton” of our application.
The mobile layout was the first thing we approached for the Chrome Material redesign, phone being our top priority. That being said, tablet is really important as well, and from a pure visual design standpoint, it is something that I really enjoy doing because of how much more visual UI there is and how fragile the balance can be to make it(hopefully) visually pleasing.
The tablet layout
Chrome tablet and phone are, of course, not two separate items but are two parts of the very same product, sharing the same base both stylistically as well as technically as we share all the assets from mobile to tablet — except for a few tablet-specific ones.
Following the stylistic and visual changes that I talked about and previewed in Part.1, we started applying the same Material layout core principles.
Here’s a direct visualization of the grid, sections, and spacing of the tablet’s core UI.
Chrome tablet is like Chrome desktop. A UI on three levels (background, inactive tab and active tab+toolbar. “Active tab+toolbar” split into two core elements: the tabstrip on top, and the toolbar at the bottom.
As you can see above, the toolbar part is similar to the phone in height (56p). We re-use the exact same icons and omnibox asset, we’re just using the large real estate to display more actions.
Where it gets tricky is the tabstrip section. A big part of the Chrome brand is carried by its tabs, and even though we made their angles sharper, they have essentially maintained the same “folder styled/diagonal” shape. A shape that does not always play nice when it comes to balance the UI and make it touchable. Make them too small, and they are not touchable. Make them too big, and they overpower the overall UI.
Their very particular shape requires a slightly different approach to the layout. While we stick with the 8dp base grid, we did have to make exceptions.
Physical shapes being diagonal, we also needed to approach the layout as boxes overlapping each other, and in some places, rely more on visual alignment rather than mathematical.
We went for a 36dp height tab asset leaving 4dp to the top border of the app real estate.
While the touch targets go all the way up to Android’s status bar, the actual graphical footprint of the UI feels visually balanced, giving more prominence to the most used part of the UI — the toolbar — and avoids creating too much white space where the active tab meets the toolbar.
See below with the touch targets visualized:
And the final look:
For the omnibox interaction, we do not do the same thing as we do on the phone — getting it full bleed would be too much movement and quite confusing on larger, tablet screens. We take a more conservative UX approach that borrows more from desktop than phone in its function, while keeping the full bleed and clean aspect of the dropdown.
As you might have noticed, we’ve added back the omnibox drop-down icons on the left side of each row to balance the UI for better readability. The icons being aligned with the security chip, guiding the users’ eyes straight down.
Visual aesthetic
As I mentionned, I really enjoy working on tablet because there is more UI to take care of, and it really satisfies my OCD desire for neatly organized pixels.
Over the years, and on every single version of Chrome, the tabs are what benefited from the most visual attention.
They are very important and a bad shape can really throw away the visual polish of a very UI-light app like as Chrome.
As I mentioned in part.1, the natural flow of visual transformation and iteration of chrome tends to make it sharper and sharper — coming from rounded tabs and corners to something pointier and squarer without ever reaching hard corners.
With this iteration, I think we went as far as we could go with tiny corners and abrupt line transitions.
As you’ll see right below, we used 4pt circles as a visual guides to get our curves right. The 65° angle of the tabs was a pure visual call, no math or particular logic behind it.
If you look on the right side of the image, where the new tab button is, you can see that we also used tiny 2pt circles. The alignement of the button is based on visual appreciation over math as its shape is very particular. The only thing we had to get exact was the angles of its left and right edges so it looks like the button was directly “detached” from the adjacent tab.
We continued pushing pixels around until we were satisfied. The trickier part was figuring out where the tabs’ base meets the toolbar as well as where the tabs meet each other.
Another thing I’m very keen on when looking at any UI is its lightness and the level of detail that was put into it. I’m alway delighted to see how far a designer can go to get something right.
I enjoy using 1px lines, even on hi-dpi screens. Rather than simply multiplying, there is a tremendous benefit in spending the extra time trying to make your design feel right for each ratio, jumping on the oportunity offered by the extra pixels to get little details in.
We tried to carry this principle to our tab, toolbar, and omnibox.
As you can see, we use a constant 1px stroke throughout the assets until reaching xxxhdpi which uses the 4x multiplier. I do not think this density is used yet in any tablet, but the asset is there for future proofing.
The upside of this is that you can take full advantage of the additional pixels offered by higher density screens to make your UI lighter and sharper.
What works well on a low-res display may not be perfect when scaled up.
You may have to play a little bit on the opacity of certain strokes but overall your visuals will benefit from such an approach over simply multiplying and ending up with chunky strokes. This is particularily relevant for odd or mor complex shapes such as the tab ones.
The downside is that you need to manually create and check every asset you will display instead of relying on automatic scaling (using sketch, for example). While this is something I usually do for everything, you may not have the time to do this if you have a lot of assets.
As you can see below, we kept a 1px stroke around our omnibox while varying it’s opacity so it gets the right weight on each ratio depending on how much drop shadow is drawn by the combination of the double shadows.
We do visual estimates rather than math to get the right feel. Yes, sometimes it might be a bit much.
Shadows
Speaking of shadows, they are an important to communicating the structure of your app in the Material design language.
Material design aside, it is usually a good idea to consider your application as a set of various layouts layed down on a physical view, allowing you to consider its structure from another, more tangible perspective.
Applying this to the matter at hand, this would be the Chrome structure:
The app structure has to be communicated differently from phone to tablet due to screen real-estate and the direction we’ve taken UX wise. The tablet’s screen real estate allowing us to bring back the tabs where the phone screen real estate forces us to use a card-based tab switcher.
Shadows as a hierarchy indicator works better on tablet than phone because of the difference in viewport size. For the latter, we tend to use motion to give the user hints on his spatial location and app hierarchy.
Visually and assets wise, as different as the phone and tablet UI can be, we try and to use similar shadows, starting with the toolbar.
Stylistically and while MD tend to recommend strong shadows to clearly indicate depth, we needed the Chrome Core UI to “stay back”, making it spatially “flatter”.
We need to be quite conservative when it comes to its visual prominence, especially when it directly impacts content. We needed to stay back, even when drawing our shadows to let the content display its own structure, especially if said content is going to use Material design as well (shadows everywhere!)
Our shadows cannot compete with the content, and even if the toolbar is one of the highest elemenst z-order wise, we needed to tone it down, like so:
As you can see, we try and keep Chrome’s always visible elements as physically close as possible to the content area, drawing small and very sharp shadows, mostly supported by our set of strokes and thin separators line.
On the other hand, when we add ephemeral overlapping elements such as menus and information bubbles, we can represent the hirarchy better by casting stronger ones.
This is the case for elements such as full bleed omnibox, omnibox dropdown, find in page bubbles, dialogs and menus. These elements require the user’s momentary full attention and the shadows will serve this purpose.
The elements are not passive but supposed to be acted on.
Logically, as we go higher up into the z-order, shadows get more spread out and dimmed out as it is further away from the reflective surface. Its is especially noticeable on tablet, like on this unrealistic view where I display all the menus at once:
You might have noticed that the menu’s shadows (5) are counter-intuitively stronger than lower ones, the complete opposite of what I just mentioned.
Besides my constant will to say something and do the exact opposite, the reason for that is that these shadows are directly overlapping an inpredictable content and we needed stronger differentiation hence the additional opacity, regardless of the “physical” layout and logical structure.
In the end, with the very light Core UI and the strong menu shadows, you may question the relevance of going all the way to visualize the UI and create a physical representation of the app if it’s to directly break its learnings once you get to the visual design. You are not wrong, although I think the greatest benefit of this process is the physical visualization of your app structure, over pure shadow representation.
While shadow hierarchy is a good principle to define the visuals, utlimately what it comes down to when designing is their direct relationship with their environment.
The reality of the software use is more important than physical world mimic, but they can work together to deliver good UX and UI.
Like for mobile, we defined a final base layout and flow for Tablet as a set of key-screens for us and engineering to work from. They were a lot less numerous than their phone counterpart of course considering that a lot of features are accessible directly from the same layout.
Typography
The last aspect I’d like to quickly go over for Chrome’s layout is typography.
Chrome is not font heavy but the less surface on which you have font you have the more it’s important to get these few occurrences right. These being the ommibox, the omnibox drop-down, the menu and the tab cards titles.
We naturally used Roboto, Android’s native font.
While the MD guidelines recommend a body font of 14sp, a subhead of 16sp and a title of 20sp, it didn’t fit our very particular layout. While we have typography in our top bar, it is constrained in our omnibox, not defined as a title, therefor it needed to be a bit smaller.
We opted for a base typography of 17sp, using a combination of regular and bold, used to put an emphasis on the user search string.
We use the Chrome specific color scheme for font, #333333 for dark text and #4285f4 for actionable items.
As a secondary surface, the menu uses a smaller set of font, 16sp regular. We went back and forth between this and the MD recommended “attic” menu with 14sp Roboto medium font.
As I mentionned in the layout part of this article, we chose to got with an overlapping menu, lighter and more agile than the attic, our menu being opened quite frequently. The attic is great for opening secondary surfaces and different app sections.
Following the same reasoning, we used the 16sp font, a bit taller than its attic counterpart to have bigger, more parseable text as well as being more consistent with the font-size used on our other primary surfaces: omnibox and drop-down.
We use this menu style consistently with the tablet version. Font-size and weight alignment becomes even more relevant and visible here.
Motion design and prototyping
A big part of what makes Material Design what it is today is its motion.
At the time, we were still discovering the core principles on which the final MD guidelines were going to be based on, including motion. Therefore, a lot of experimentation was done in terms of timing and effects as nothing was final or set in stone, even internally.
As one of the first “MD revamped” app to be released publicly post I/O 2014 (along with Gmail’s Inbox project), the primary task of the Motion design here was to balance what we thought MD was going to be with the possibilies of the Android framework had at the time a bit more than a year ago.
Motion design was lead by one designer, Manuel Clement, and all the work I’m going to show here is his. My implication in this was mostly feedback and visual help. He was also interacting directly with the Material design team.
Prototyping
Describing this part of the project as “motion design” only wouldn’t make it justice it’s more akin to prototyping with the benefit of delivering precise motion spec to Engineering.
To achieve this, Manuel only used HTML/CSS and javascript that he was running on device by simply reaching to a URL. No prototyping tool other than his browser and Sublime Text which was really impressive for me to see. He successfully managed to deliver both accurate motion expectations as well as relatable code.
The delivery of specs and previews was made via a dedicated internal website that included a link to the main protoype, several videos displaying various aspect of the application separated in “feature sections” and written specs.
Each section specs was linked to a common one defining the base and shared values such as timing and motion curves.
For the sake of this article, I built a little motion appendix page where you’ll be able to see the videos from which the gifs below were made along with a excerpt of their respective state.
From keyscreens to specs
As you’ve seen earlier in the mobile layout, we defined a set of key-screens that can be associated to “features”. Some of these features required motion design and they were defined in the motion spec as followed:
- Omnibox full-bleed
- Omnibox dropdown
- Tab switcher
- Tab switcher icon
- New tab
- Close tab
- Menus
- Page info
- First run experience
These key-screens were developped into a main prototype (and a few secondaries) as shown below that enabled us to preview how the motion would feel in place (the .gif was too big for Medium so check the full video directly on the appendix by clicking the image):
From these prototypes was extracted a set of values which were gathered in a section called “Variables” and defining the set of common bezier transform curves, fade out curves as well as a set of durations.
Setting a common set of variables not only makes the spec easier to parse but allows us to keep the motion curves and timing consistent by attaching them to a “fixed” set of value. That, they can be used in other projects/features developped in the future.
Now let’s talk about the thought process surrounding each of the motions specs. I have added a direct appendix link for HD video and spec excerpt in each section.
Omnibox full-bleed
As mentioned before, we used MD properties to emphasis this very important feature of Chrome by giving them more screen real estate to allow better user focus. Motion here provides spatial location, the omnibox expands and takes over the entire toolbar. When disengaging, the motion is simply inverted.
Omnibox drop-down
In direct continuity with the full-bleed omnibox, we changed the drop-down to span across the entire device width. The motion goes from top to bottom in a progressive fade-in.
Tab switcher
We worked a lot to make the transition between states for tabs more seamless by removing the dog-ear for example. this way it’s is easier to communicate the fact that the toolbar relates to the cards’ title bar. If you look closely at the motion, you will notice a subtle shift and fade-out to transform the URL into the card title.
New tab
The “new tab from card stack motion” is all about animating from the point of origin. One of the core principle of MD is “meaningful motion”.
In the current case, it relates to the point of origin of the surface you just created. We expand diagonally with a delayed fade-in for the content.
Close tab
Same principle as “new tab” but in reverse. The card collapses on itself when closing from the “X” button located at the top right.
Quick note, to limit the duration of the animation, the card actually disappears before the completion of its “collapsing” animation. The user’s brain bridging the gap between the origin and final stage of the motion.
Menus
Similar to the “New tab” motion, the opening menu animation is based on the point of origin and expands diagonally. The version shown here is actually outdated as we changed the cascading effect to a simpler and faster fade-in once the card is deployed. As a result the menu feels less “in the way” and snappier.
Simulating “force” is also fun. If you look at the top row of icon, they are pushed out to the left while the rows are pushed down. Without making it “springy” to avoid motion overdose, sliding icons in while fading them in is a good way to convey inertia.
I’ve added two additional motion specs I didn’t judged essential to this article to the appendix: page infos and first run.
Motion Wrap-up
In the end and while we were always aiming for high fidelity between prototype and final implementation, the reality of the development and the limitations brought by a wide variety of devices hardware made us reconsider a few decisions and lead to a few tradeoffs.
We needed to be careful regarding the CPU usage for each animation or rendering and modify the implementation accordingly. While we weren’t able to reach the original framerate we were hoping for on certain devices, it was important to keep the essence of what the motions were trying to accomplish, i.e focusing the attention of the user on what is happening and giving him a sense of spatial order within the app.
Nothing is set in stone and most of the current animation we have now differ from the original specs. Steps have been removed, curves have been simplified and their impact on the screen real estate have been slightly reduced, trying to remove motion as a decoration in favor of motion as a UX help.
Even beyond technical limitations, we shorten every motion to make them snappier. At this point and once the novelty of an animation passed, all is left is finding out if your motion design is in the way of the user or still serving a purpose. Hopefully, we striked the right balance.
Tools, speccing and assets
Having the right tools for the job is essential if you want to keep your sanity and spend as less time as possible on tool problem for focus on your actual work.
The tools
Chrome Android redesign was done a bit after the release of Sketch 3 and the team was slowly transitioning from Photoshop to it. After a few weeks of tryouts, I decided to switch our entire process and legacy files to use Sketch 100% for the making of Chrome for Android (and later iOS). Our previous version of the app was Photoshop based.
It was quite a “bet” as I didn’t try Sketch enough to know how good it will scale for a large project and how well it would be received by the team. The potential returns though overwhelmed the potential downsides so we took this risk and while it took a little while to set the new process up and file system to support the project, I do no regret this choice.
Layout and especially asset production greatly benefited from this switch. All our current project at Chrome are now designed using Sketch.
Illustrator was used as well to bridge the gap between us and the Material design team, desining the MD system set of icon at the same time we were designing ours (Jeff D. stark was our icon designer on this project).
Illustrator is still used by our team today for its extremely powerful vector tool and its .svg generation, unmatched today.
After Effect was used by the Material Design team to communicate motion principles. As you saw, Manuel chose to go for HTML prototyping for Chrome, using Sublime Text and Chrome.
Speccing
Starting without plugins and done manually, layout specs where then done using the Sketch plugins “Sketch Measure Master”. An absolute must have. See below a few preview of our initial spec files most of them done before we used the Measure Master plugin extensively. Our specs our now closer to the polished ones I created in the first sections of this article.
File structure and asset production
There a lot of ways to structure a project, each with their set of flaws an benefits of course.
Ours relied on a common Google Drive folder shared to everyone involved in the project — designers, engineers and PMs — each with their own set of permission.
Automatically synced to each designer’s local drive, this system allowed us to move fast once the basic system was defined. Careful though, this system may not scale well to larger teams of designers potentially working on the same file at the same time. In our case, each designer was assigned a specific part and there was no overlap, we knew who was doing what. It allowed us to work off a simple drive folder rather than build on a more complex versioning systems.
Regarding the structure of the folder, explicit naming was used as well as a subfolder system that made sense for our purpose. Each project is different and what works for one may not work for the other.
We decided to divide the project based on device, PPI ratio and feature, in that order. We set the following naming convention:
[Device-ppi-feature.sketch] which gives something like this:
[Phone-xxhdpi-toolbar-menu-fip.sketch]. This means that we used a phone 3x template(Nexus 5) regrouping the toolbar, menu and find in page features.
For tablet, we used the Nexus 7 2nd generation as our test and design device which gives us:
[Tablet-xhdpi-Toolbar-menu-fip.sketch].
You might have noticed that there is no versionning in the file name. Initial tryouts and explorations were regrouped in an “archive” folder. Modification was done ad hoc in the various files if small.
If the modification required deeper changes, we simply duplicated the file and put the old one in archive, this allowed us to make sure that anytime an engineer would look at the shared folder, they will see the very latest version of the thing he or she is looking for.
Here’s what the folder structure looks like, I voluntarily reduced the amount of files and folders to focus on the more interesting, core structure:
You might have noticed that “Preview and specs” are in a separate folder than “All sources”. While all previews and specs are created in the same source file, separating the very numerous exports in another folder allows to share and show engineering easily (we have an internal slideshow/commenting tool) without mixing them with source files that are useless to them.
The asset folder is structured similarly, each export folder mirroring the source filename. As you can see, we appended the PPI instead of directly separating them into folder buckets (mdpi, xhdpi, xhdpi, etc…). The reason for that is the export process of assets.
At the time, I didn’t find any viable solution for exporting a large set of assets from a single sketch file into different folders. Today, you can do this with plugins such as “Sketch-android-assets” but I do not think it works with manually designed assets for each PPI.
Each asset was checked and manually tweaked if needed per PPI. If you remember the “Iconography” section I wrote in Part.1 one, I went over the fact that before started automatically coloring .pngs, we needed to export 6 version of each assets:
Therefore, the PPI bucket was appended after the icon name and state state, like so: [back_white_active-hdpi.png]
Then it was placed in the right folder by engineering in the code repository after automatically removing it. A cumbersome flow that needs some improvement but we got it done.
If I had to summaries the lessons learned from managing, organizing and producing assets, I’d say that the file structure was working well but checking each asset independently per DPI was superfluous considering the icon were based on a good grid and were, for the most part, good candidates for auto-scaling.
What I’d recommend if you are working on a 4dp icon grid is only generating the 1.5x (hdpi) assets manually and rely on Sketch’s automatic scaling for the rest, giving the export a final check before implementation.
Additionaly, coloring the assets in code to manage their various states was huge from a scalability, time saving and .apk size reduction prespective, getting out asset repository from ~1200 to ~580.
Asset management can have a really negative impact on your efficiency and therefore on your project in general. Plan well in advance and figure out a good balance between good design, good rendering control as well as design and engineering overhead.
Designing this kind large projects is a chaotic process full of learning opportunities.Writing this helped me realize what went well and what needs improvement. I really hope it was useful for you as well and that you can gather a few positive things to add to your own process or a few negative things you want to avoid.
This concludes the second and last part of this series. Thanks for reading!
If you want to connect, I’m @kounterB on Twitter or you can add me on Google+. If you want to connect with the Chrome UX team members involved in our mobile effort: @alanbettes, @peteschaffner, @alexainslie, @gmurphy, @mano1creative, @cleerview, @romafied, @rlian.
