Official Gmail Blog
News, tips and tricks from Google's Gmail team and friends.
Developing Gmail’s new look
December 6, 2011
Posted by Mark Striebeck, Engineering Director
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.
Labels
buzz
calendar
Gmail Blog
Google Apps Blog
Google Calendar
googlenew
Inbox
Inbox by Gmail
labs
mobile
Offline
reader
tasks
tip
Archive
2016
Sep
Aug
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Aug
Jul
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2007
Dec
Nov
Oct
Sep
Aug
Jul
Feed
Google
on
Follow @gmail
Follow
Give us feedback in our
Product Forum
.
Get posts via email
Email:
Powered by
Google Groups
Useful Links
About Gmail
Gmail for Mobile
Gmail for Work
Follow