Developing Gmail’s new look

Editor's note: This post is more technical than most posts here, but we thought some of you might find it interesting to look inside how development on the Gmail team works.

Developing the new look for Gmail was like the proverbial “changing tires on a moving car” - only that the car is carrying hundreds of millions of users and is under constant construction and development. The two main technologies that we use for these types of projects in Gmail are “conditional features” and “Javascript mods” (other Google products use very similar systems). Both technologies were particularly important for testing the new look.

Let’s start with the first one: conditional features. This is our ability to make changes to the Gmail code that get deployed, but not executed. You can think of it as a lot of if-statements around the new code that get enabled when the conditional feature is on. The conditional feature flag itself is set outside of the deployed code. These flags can be set in various ways: as a percentage of overall users (if we want to rollout a feature slowly), for Googlers only (if we want to use a new feature internally), for individuals (if we want to give users early access to a features) and in many other ways. In short, conditional features allow us to update our production systems separately from releasing new features. This way, Gmail developers can make changes, but don’t have to worry about their unfinished changes being released before they are ready.

The other technology is “Javascript mods”. We use this technology to create modifications for a new feature in Javascript across many files. The main challenge with Javascript is that we want to keep the amount of Javascript code that the browser has to download as small as possible - the more code the browser has to download, the longer it takes to load Gmail. So, we don’t want to include the code from all possible mods, but only the code that’s relevant to your browser. Let’s use our Gmail mobile app as an example: it comes in various forms, including the smartphone user interface (UI), the tablet UI, and the offline UI. All these UIs are slightly different. We don’t want to download the Javascript code for all different UIs to the browser. Instead, our server inspects which browser or device you are using and creates the exact Javascript that you need. The selection of mods can be triggered by browsers, devices and even “conditional features”.

Using these technologies, we can make sweeping changes in Gmail without those changes going “live” before they are ready. Plus, since we can turn pieces of code on or off, we can enable new features in specific environments, such as Google, or for specific users, like the Gmail team, without changing the code itself.

Designing Gmail’s new left navigation

One of our goals for Gmail's new look was to make Gmail feel more like a native application with independently scrolling panels rather than a website that scrolls as a single page. This design approach brings with it many advantages: the search box and primary navigation are always in the same place, your inbox unread count is always visible, etc. As with any design decision there were challenges with making this change. People with lots of labels might have their chat contacts pushed entirely off the screen and those with gadgets, like the Google Docs or Calendar gadgets, might have to scroll the left panel past both the labels and the chat contacts in order to see them.

We went through a number of different design revisions to try and address these issues as elegantly as possible. We experimented with several accordion designs, which stack sections on top of each other but only allow one or two to be open at a time.



We also experimented with designs that involved only one scrolling region, but showed fewer entries per section.


The final design combines aspects of both approaches. It is a ducking accordion design with only two sections. The bottom section has two tabs, one for chat and one for gadgets, with room to add more tabs in the future. The upper section, which contains labels, expands to show all of the visible labels when you mouse over it. This allows you to see chat contacts but still give quick access to the labels. Best of all, you can easily adjust the balance between labels and chat to fit your own personal preference by dragging the divider between the sections up and down.


This design went through a number of iterations as well. We carefully adjusted the timing and triggering behavior of the expanding labels section to minimize accidental triggering. We noticed in usability testing that having the labels section expand when you are mousing over the Inbox label delete didn't work for everyone. We tweaked the system only to expand if you moved your mouse below the inbox label and keep it there for a moment. We also tried to ensure that if you are moving your mouse to click on a particular label or chat contact, that label or chat contact will never move out from under you.

The end result is a system that is more flexible, more responsive, and always keeps your chat contacts and unread count visible without adding a lot of complexity or requiring too much clicking around.