Maria

How does one make something universally useful? In a way that both respects how people have used something in the past, and anticipates new behaviors?

If you are the front end engineering team for Gmail, you find compelling statistical data, but still observe real people in order to deeply understand how your ideas actually work. You make big code changes for minimal visual interruption. And you discover that the effort to implement the new while keeping the old leads to a single, stronger solution for everyone. What goes into engineering the best webmail experience?

Since its beta release in April 2004, Gmail has grown from a simple webmail service to one of the most widely used communication platforms with more than 425 million active users around the world. Brainstorming the next leap forward for Gmail in 2012, Maria and her team were charged with continuing to improve the productivity of Gmail. "We had worked for years on making Gmail available offline, it seemed hard to know what to do next to have that same type of impact." When her tech lead introduced the idea of streamlining the compose experience, the team (five engineers, a UX designer, and user-test experts) jumped at the opportunity. After studying how people actually used the current compose function, the team found that most people were sending fairly short emails, with a single-digit percent of users using any sort of rich text formatting in their compositions. Maria explains: "This last decade has seen a lot of changes in the way people interact with each other, with short text messages as opposed to long compositions, for instance. We wanted to make sure that Gmail was easy to use for shorter messages while still being great for longer compositions. We wanted to make this a simple, slick composing experience."

So how do you go about creating the Swiss Army knife of email compose experiences?

A streamlined and responsive experience across all browsers.

Based on the data from user studies, Maria and her teammates identified changes to improve speed and ease of use when writing emails. The first thing they did was create a new compose window called a "badger." Why badger? "In Gmail we have these little chat windows called moles," Maria explains. "So we decided to call the new compose windows 'badgers.' Honestly, we just picked a bigger animal."

Unlike the classic compose experience of that time, the badger window pops out of the bottom right corner of the Gmail screen. It allows users to write multiple messages simultaneously and read their email in the background while doing so. On top of that (literally) the team decided to make the badger window grow and shrink as a user wrote or deleted text. Making an editable field adjustable based on content is not particularly difficult in principle, but there were several unexpected browser behaviors that occur when resizing a content editable area in the smooth way that the Gmail team envisioned.

We had to come up with a lot of new code solutions to handle these interactions in such a way that they didn't jump, cut off parts of the line, or reformat text as the user typed.

As Maria says, "We were trying to achieve this experience where the text area would grow gradually, but only as far as the top toolbar goes, at which point it would scroll instead. A lot of this was difficult to do in a consistent way across the three browsers that we support: Chrome, Firefox, and Internet Explorer. We had to come up with a lot of new code solutions to handle these interactions in such a way that they didn’t jump, cut off parts of the line, or reformat text as the user typed."

Once the team started experimenting with this adaptive textbox, they found that — while this change was fine for rich text — it didn't support plain text very well. The easiest solution would be to just stop supporting plain text handling, but turning again to user research, the team found that there were many mailing lists that only accepted plain text. With an overarching goal of facilitating all types of conversations, ignoring this use case was simply not acceptable.

While plain text is typically handled by the textarea html element, rich text is handled by a contenteditable div. In order to preserve the plain text functionality, "We ended up rewriting how we handled plain text to start using a contenteditable div for plain text as well," said Maria. "We had to disable all the formatting features, and at the end of composition, strip all the tags and reformat as plain text. Making sure that the formatting of a plain text email stays correct when we are changing it from html to plain text is tricky. You can't just strip off the html tags and get the correct results, you have to understand what sort of formatting those html tags create in a document. Then, you convert that into what it would be like if it were written in plain text. It was actually really interesting — whereas the old Gmail used to have two completely different ways in which it handled text formatting, now we actually have one unified way of handling it."

As these ideas were developed, the team's UX researchers ran user studies to help the team prioritize and group product features. Testers would try out a wide range of tasks using the new compose and would fill in surveys about their experience. To keep feature development on track and inline with user feedback the team used a modified agile development process. "We were all sitting together, like the four of us engineers, and our PM and UX designers too, so we could really iterate really fast on these things," explained Maria. The combination of fast, frequent user data led the team to two-week iteration cycles, where new ideas were quickly incorporated into the overall plan for development and new stumbling blocks went back for further refinement and testing.

Making sure the uneditable to the editable didn't jump

A surprisingly difficult thing Maria and the team worked on in this way was creating a new way of handling email recipients. When users look at a recipient list in the new compose, each name is displayed in a non-editable box. But when a user clicks on these boxes, they become an editable field. "We had to find a way to align it so this transformation from uneditable to editable did not involve any jumping up or down." This was complicated by the fact that different browsers handle things differently (cue Captain Obvious), such that an input field in one browser is a different height than an input field in another. "We needed to create style sheets that would properly align everything in all browsers. And of course, with all the features in Gmail's new compose, every time we changed UI a bit, something would shift, and then maybe 2 out of 3 browsers would break, which we would then fix again. We actually ended up writing an automation test that would measure the height of the recipient list, then would click on it and measure the height again, checking that the heights didn't change in the process. Things like Webdriver came in handy to ensure our new features didn't break with different browsers, especially when dealing with recipient list changes."

Yet once that was resolved, a strange new bug emerged. A random unnecessary scroll bar would appear on the right of the badger when users zoomed into Chrome. Apparently, that was happening because the contents would suddenly become just a bit bigger than the surrounding box, which was surprising because the box was supposed to be sized by the height of the existing contents. "When we examined the heights, we discovered that the heights would differ by fractions of a pixel, e.g. the content would be 9px, but the box would be 8.98px. Turns out that when you zoom in Chrome, it turns on sub-pixel rendering mode. And in that mode, you could get a calculation for height that would have a rounding error. We ended up filing a bug, and it was fixed in the Chrome render, but we also had to work around the issue by carefully rounding the numbers we computed as heights as well to make sure this issue didn't happen."

Creating feature parity and integration

Then came feature parity. "Most people think of Gmail compose as this simple textbox that you type in, click send, and it's all good. But in reality, there are many features in our compose window, and you don't necessarily realize just how many there are until you examine the code. For instance, in Gmail you can label drafts inside of a composition, you can insert emoji, you can do all kinds of formatting, you can print drafts, you can insert photos and docs, etc. There are also a lot of labs that integrate with compose, like canned responses. Not only did we have to replicate all of those things in the new compose experience, we also had to find ways to integrate them into the new UI, which involved so many design challenges. It was pretty awesome to be able to see all of the inner workings of these features that are really unique, and then to find ways to reproduce them in the badger."

...we are perfectionists and we really wanted this beautiful, seamless experience without any jiggering.

Getting each and every element just right is key for a front-end project like Maria's: "Finding ways to create precise alignments throughout all features of new compose was quite interesting. Alignment of elements may sound trivial, but we are perfectionists and we really wanted this beautiful, seamless experience without any jiggering. It took us a couple of tries to get it right, but we hold ourselves to a high standard. It was worth it for the beautiful results."

"My favorite piece of feedback is from a user who said, 'It's like scratching an itch I didn't even know I had.' It's so nice to have been able to work on this project. All the time that we were working on it, I felt it had so much potential: it could really improve people's productivity when using their email, and that is a very impactful change."

Maria is now an engineer on the Chrome team and she also serves as a committee member for the Anita Borg Scholarship.