Episode Transcript

Karen:

Hi, this is a responsive web design podcast, where we interview the people who make responsive designs happen. I’m your host, Karen McGrane.

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week… Welp, we’ve got some guys from a small, somewhat unknown, little startup. You may have heard of them, the company is called Google. We have Malte Ubl and Wahbeh Qardaji, who are here from the Google+ team. Welcome.

Wahbeh:

Hello.

Malte:

Hello. Great to be on the show.

Karen:

We are so thrilled that you are here today. I’m really excited to hear about some of the fantastic stuff that you’ve been doing at Google+. I’d love it if you could just start off by introducing yourselves, tell us a little bit about what your role is at Google.

Wahbeh:

Sure. My name is Wahbeh Qardaji. I’m a software engineer at Google, and I’m also the tech lead manager of the Google+ web team. We worked on a responsive web design for Plus.Google.Com. We shipped our first version of this design in February for mobile devices, and we’re continuing to work on that and improve it.

Malte:

My name is Malte. I’m also a software engineer at Google. My focus is on infrastructure, so I don’t work on the product directly. I rather support lots of products at Google, making their stuff on the web really awesome.

Over the past few years, we’ve been noticing that a lot of our users are using Google+ and other products on mobile, so there was a huge direction from our leadership to go mobile-first.

Karen:

And awesome it is, I have to say. I’d love to just start off by asking broadly: How did you guys decide to go responsive for a product like Google+?

And I’ll follow up on that and say in the world of responsive design, there’s a lot of debate about whether responsive solutions or adaptive solutions—device-specific solutions—are the right way to go. There’s some high-profile examples within Google itself of implementing more adaptive solutions rather than responsive. How did you guys make this decision?

Wahbeh:

Well, as with all things at Google, we care about data a lot. Over the past few years, we’ve been noticing that a lot of our users are using Google+ and other products on mobile, so there was a huge direction from our leadership to go mobile-first. What that meant for Google+ was mainly focus on making the native apps really good and really nice. But that left web in this weird place, where we had a very big desktop site and a mobile site that was not really that responsive, not really that amazing of an experience. It was tailored mostly towards lower-end devices.

It took some convincing to show our leadership that we could go fully responsive, that we could just build one single codebase and serve all browsers.

So, as with most things in Google, a group of engineers got together and we decided, “Let’s build a prototype and show that we can build a responsive web design that was truly mobile-first and that could extend beyond mobile devices.” It took some convincing to show our leadership that we could go fully responsive, that we could just build one single codebase and serve all browsers. But we built a nice and small prototype, we did our first demo to our leadership, and their reaction was just amazing. They were like, “Oh, this looks really, really nice. This works really well. In some sense, this feels like our native app and it performs well in the browser,” and this is how things got started.

As we saw more users on mobile devices trying to access Google+, we took a step back and said, “We should provide all features on all platforms, no matter what device you use, no matter what browser you’re on.”

Ethan:

That is incredibly exciting to hear. I’d love to hear a little bit about how Google+ thinks about two of my favorite words, which are “mobile” and “desktop.” Karen and I speak to a lot of organizations where there’s a lot of thinking that mobile users and desktop users are somehow completely distinct entities, that they need different things depending on the device or the context.

Since you guys love your data, I’d be really interested to hear as you’re thinking about designing a more responsive experience for Google+, how do you actually think about who needs what information and on what device?

Wahbeh:

Well, we really want to provide all our features to all our users no matter what device they use. When Google+ started, a lot of the features were desktop-only. But as we saw more users on mobile devices trying to access Google+, we took a step back and said, “We should provide all features on all platforms, no matter what device you use, no matter what browser you’re on.”

Basically the process was that we built the web application, then first rolled out to all Googlers, asked for their feedback—a process called dogfood.

Karen:

Talk to me a little bit about how you roll something like this out. For example, we talk to some organizations that implement a really long-term beta strategy, where they’re checking in on the data on a super-regular basis as they roll it out in stages to various groups via search, or social, or other, more targeted fashions. Can you talk about how you planned to roll this out to customers, and what kind of analysis you did before you flipped the switch entirely?

Malte:

Wahbeh can later talk about the data aspects of it, but just to talk about the rollout in general: You need to understand, we have this big desktop website, and we have this somewhat smaller and not-as-complex legacy mobile app. What we decided is that in order to move really quickly but not have very old browsers where we don’t have any experience, we would use our existing mobile application of the legacy user so that we could concentrate on the relatively new browsers and make something that’s really nice for them.

We basically built a solution where we can serve entirely different versions of the website on the same URL space to different user agents.

So, we went ahead and decided that we would initially roll out to our mobile users on Chrome and largely iOS, and then basically the process was that we built the web application, then first rolled out to all Googlers, asked for their feedback—a process called dogfood.

Then what we did—and this is kind of an interesting challenge—is that we decided because we wanted to have our existing desktop app serve kind of on the same URL space, but we didn’t feel like we could immediately roll out to them, we basically built a solution where we can—on the same plus.google.com URL space, at the same URL—serve entirely different versions of the website on the same URL space to different user agents.

We’re currently only launched to mobile web and the mobile users and tablet users, and more is in the pipeline.

Wahbeh:

And the rollout process is still not complete. We’re currently only launched to mobile web and the mobile users and tablet users, and more is in the pipeline. We’re continuing to iterate, add features, and make the design more responsive.

We have an amazing product management team that helps us set the goals for our products, what set of features we should include, what is the minimum set of features that we can include in order to ship it.

Karen:

Let me ask sort of a related follow up to that, which is: How do you scope and plan an initiative of this magnitude? As you’re thinking about prioritizing the features that you want to build or rebuild responsively, as you’re allocating time and resources for this staged effort, how do you know how long it’s going to take, and how much it’s going to cost, and who’s going to be involved?

Wahbeh:

Well, we have an amazing product management team that helps us set the goals for our products, what set of features we should include, what is the minimum set of features that we can include in order to ship it. Based on that, we take these features and a group of engineers—the team working on it—sits together, comes up with a list of tasks and tries to come up with time estimates for how long this will take. Based on that, we start working; we usually modify the scope after we begin on the product if we see that it’s necessary.

As we basically built the product side of things, we had this similarly large project of actually building the infrastructure out.

Malte:

One thing also to note is that as we basically built the product side of things, we had this similarly large project of actually building the infrastructure out to make the product team as productive as possible and to actually make the things that they had in mind possible, and feel really good.

They come up with what they think the website should look like in Photoshop and Illustrator, and then they come up with different mocks for different devices.

Ethan:

I’d love to hear a little bit about the applications and tools your designers are using right now to talk about this more responsive look on Google+. Are they really doing a lot of early ideation work in Photoshop or in Illustrator, using mock-ups primarily to talk about the design? Or is it much more prototype-focused?

Wahbeh:

It usually starts with a mock-up. They come up with what they think the website should look like in Photoshop and Illustrator, and then they come up with different mocks for different devices. Then it goes through a process where they iterate the design, and then they identify different breakpoints in terms of screen width and height, and how things should flow on the screen, how things should be rearranged in order to extend to different screen sizes and different platforms.

One important insight is also that you don’t necessarily need to have different mocks for your web app and your native app.

Malte:

One important insight is also that you don’t necessarily need to have different mocks for your web app and your native app. There’s many situations when you basically want them to look the same, especially if you develop for Android with varying different screen sizes, but the same with iOS—that has at least four different common screen sizes. You kind of have to solve the same problem, and there’s no apparent reason why they shouldn’t be solved exactly the same way on all those problems, independent of where they use HTML or some native technology for the delivery side of things.

When we get a certain set of requirements, a certain set of mocks, we go ahead and rapidly prototype.

Ethan:

That’s great. I’d be interested to hear about how responsive design might’ve changed the way your team has worked—between designers and developers—how they’re collaborating together. And has that changed the way you hire for different roles, or how you’re organizing design and development internally?

Wahbeh:

Working on a responsive web design requires very close collaboration between the designers and the developers because you often don’t get a feel of how things will perform on a web browser unless you have a prototype that is ready. So, what we usually do is when we get a certain set of requirements, a certain set of mocks, we go ahead and rapidly prototype. We try to get some version that we can run in a browser, and then usually involve folks from UX and get their input on what we can change, what we can tweak, and how we can make the experience nicer.

Our first goal is to get something on the screen, get the barebones, get the wireframe running, and then get it in the hands of as many people as possible and get early feedback.

As we started working on this new responsive web design, it also encouraged us to start this sort of prototyping iterative approach to web development and software engineering, where our first goal is to get something on the screen, get the barebones, get the wireframe running, and then get it in the hands of as many people as possible and get early feedback, and continue to iterate to make it better.

One of the rules that we have is if you can’t animate it at sixty FPS, we don’t do it.

Malte:

When I just said that you could use the same mocks for native and web, mobile and desktop, one thing I want to say to contrast that is one thing we definitely learned is that you need to really embrace the platform. That doesn’t necessarily have to find its way into the mocks or the motion videos, etc.

One of the rules that we have is if you can’t animate it at sixty FPS, we don’t do it. That brings some pretty dramatic restrictions on what you can do. For example, in web browsers, in the general case, you cannot animate the widths or the heights of things, or the font size, because that requires re-layout on every single frame of the animation.

Instead, you want to do things that you can run on the GPU, which is the graphics card on your device or computer. So, there’s some pretty stark restrictions on what you can do, but we kind of want to do the best thing within that framework.

It’s a back and forth between engineering and UX. UX might say, “We kind of want this motion to look like this,” and an engineer would go and say, “I can make it almost like this, but it runs completely on the computer’s GPU, so it’s going to be completely smooth,” and you kind of iterate on that until you have something that looks the way the motion was intended to be but can also be implemented in a way that’s fast and feels really smooth.

Basically we’re just continuing to try to find areas where we’re not as performant as we should be, and then try to change that.

Ethan:

One thing I’m hearing from both of you guys is this idea of that back and forth you mentioned, getting something out there and adopting this test-and-learn approach. Can you tell me if there’s been any elements of Google+’s responsive design that you’ve released into the wild and realized it wasn’t as successful as it could be, and you might’ve reworked it? If so, what might’ve been the driver there?

Wahbeh:

No, I can’t think of anything in particular. But as with most things you roll out to a large number of users, you get feedback from the instrumentation that you added from whatever errors that you can detect on the client and so on, and that gives you signals on what is going smoothly, what is working, what is not working.

Basically, we go over feedback we get from the users, feedback we get from our tools, whether there were any JavaScript errors on the client and so on and so forth. We go through these almost on a daily basis and try to determine what went right and what went wrong. I can’t think of any specific things, but basically we’re just continuing to try to find areas where we’re not as performant as we should be, and then try to change that.

We never come with just a laptop. So, there’s always going to be obviously a phone, a tablet, a computer, and we kind of go through all of those.

Karen:

What about reviewing this responsive work with executives, or product managers, or other stakeholders within the broader organization? Has that changed at all? Or do you look at anything differently or talk about anything in a different way?

Malte:

I think the simplest answer to this is that we never come with just a laptop. So, there’s always going to be obviously a phone, a tablet, a computer, and we kind of go through all of those. I would say most of the focus is on the mobile devices, but we have the desktop spec up and see how it looks there.

Wahbeh:

Yes, whereas before we’d just get our laptops and show them how the screen looks, we now get our laptops with the browser open, and resize it in front of them and show them how things work, and then open the webpage up on a mobile phone, on a tablet, on a lower-end mobile phone, and show them that it works well on all platforms, and how we think it can change in order to suit different needs.

If there’s a device that has a decent browser but just can’t keep up with the animations, it’s always a good option to just not run it on that device, because it’s better for the user.

Ethan:

One thing I’d really love to hear from you guys about is this idea of support. You guys are designing for an incredibly broad range of browsers and devices, and you mentioned the sixty frames-per-second metric as being obviously very important to you and your users, but how does that impact the way in which you think about designing responsively and building responsively?

And then I’d also love to hear, just generally speaking, how the QA process works with a responsive interface at Google+.

Malte:

If there’s a device that has a decent browser but just can’t keep up with the animations, it’s always a good option to just not run it on that device, because it’s better for the user. Animations are always nice, they kind of can make some latency appear smooth, and that’s one of the successes of the first iPhone—it was really slow, but it was always animated—so, that’s a great aspect. But if those aren’t smooth and it’s not possible on some five-year-old Android 2.3 phone, then it’s better to not show them the animation.

We have what I like to call our “sixty to the five rule.”

I think it’s fine to sometimes say to kind of just scale it down. It’s the same thing where we have this legacy mobile site, I think it’s great that you have links—if you’re on Twitter and if there’s a link to a Google+ post, it should always give you that post. I think that’s very important. But it’s less important that everyone gets the latest thing. It’s fine to sometimes say, “We’re not going to concentrate on this in particular.”

Wahbeh:

We have what I like to call our “sixty to the five rule,” which is for all browsers, all devices, do not download more than 60k of HTML, do not download more than 60k of JavaScript on initial page load, do not download more than 60k of CSS on initial page load, make sure all the animations are sixty FPS, and make sure that your average latency is .6 seconds. This has been built into our engineering processes, and it’s really required coming up with a platform and a JavaScript framework that helps you achieve these goals that we set forth. Malte can probably talk more about the framework that we’re using and how it helps us achieve this level of performance, this “sixty to the five rule.”

Having these devices access your developer’s workstation is somewhat questionable.

Malte:

Right. Before going there, I wanted to go back to the QA question. The biggest problem for us is actually to enable both having all these devices for testing, which mostly is a question of buying them, which is easy, but the other problem is they might not be very secure, and people still use them. So, having these devices access your developer’s workstation is somewhat questionable.

One of the things that luckily our testing teams built was a solution where basically you can securely access your workstation, your development, and your staging servers during testing from any device without having the risk of something from that device leaking into our network, which you really wouldn’t want.

What we actually found has the most impact and what has some of the most unsolved problems in web performance is size of CSS.

Ethan:

Wow, that sounds fantastic. I’d love to hear a little more about that JavaScript framework though that was mentioned earlier, the “sixty by five.”

Malte:

What we actually found has the most impact and what has some of the most unsolved problems in web performance is size of CSS. So, my colleague, Shubhie Panicker, talked about this at CSSconf EU in Berlin last year. This has been the most tremendous improvement for us in a long time, which is to have a CSS module system. What we can do is for every page we give you, all our templates say, “We need this CSS module,” all the JavaScript says, “We need this CSS module,” and all the CSS modules say, “We need this other CSS module.” And so given a page to render, we can say exactly what CSS we need.

We can basically pinpoint exactly the CSS you need for a particular page—which more importantly involves which CSS we don’t need—and then delivers only that subset.

Where most properties use a single big CSS file, or maybe two of them, we can basically pinpoint exactly the CSS you need for a particular page—which more importantly involves which CSS we don’t need—and then delivers only that subset. The savings compared to the entire universe of CSS we have is just amazing. So, that’s like kind of the underpinnings of what even makes great performance possible.

Another thing we’ve focused on—I’ve actually written about this extensively—is server-side and client-side rendering. That involves lots of tradeoffs; it doesn’t necessarily make things simpler. What we do is whenever you’re on some external site and you click on a URL that goes to our server, we’ll deliver you that HTML that you requested as a thing. It’s going to run not a single line of JavaScript to render exactly what we want you to see. So, that’s our number one rule.

We can render every page we have on the server and the client. That was definitely a major project, but that’s been working really well.

On the other hand, once you’re on that page and you click any link that doesn’t go externally, we won’t do that full roundtrip and render everything again. You’ll have client-side templates, we’ll just go download the data, download the templates, and Perl and then render on the client that next page, update the URL, et cetera, so we can render every page we have on the server and the client. That was definitely a major project, but that’s been working really well.

I just want to emphasize: When JQuery first came out, you had all these plugins, and what they would do is they would find some piece of HTML that was rendered on the server and they’d make that datepicker look a bit different. So, that’s one of the things we just do not allow—everything on the template has to be rendered in the first pass the way it’s supposed to be so that when the page actually appears, all the browser has to do is render and it’s done. That’s kind of the key to excellent performance.

Having said that, we just spent lots of time in the Chrome profiler and Chrome timeline, just optimizing things until we’re happy.

Wahbeh:

Lots of time, definitely. [Laughs]

We have certain key metrics that we like to measure and see how changes in UX, changes in the website itself, changes in the design can affect these metrics.

Karen:

Talk to me a little bit about how you broadly measure the success of this responsive redesign. You’ve mentioned several times that you’re really focused on data. So, how do you look at analytics data or other data you have about user engagement to know if this responsive design is working?

Wahbeh:

Well, we look at the action the user takes on the website that we ship, whether they’re spending more time. We monitor latency; we see what is our median latency, what is our ninety-ninth percentile, and we always think of ways to improve that.

Then we have certain key metrics that we like to measure and see how changes in UX, changes in the website itself, changes in the design can affect these metrics, and we often run experiments and see whether small changes can affect user behavior, and we try to learn from that for what we can do better next time around.

What we, at Google, learned super early on is that, at scale, your ninety-ninth percentile performance is actually incredibly important.

Malte:

Yeah, I think what Wahbeh said about the ninety-ninth percentile is often overlooked. When we look at performance, you have the average performance and the median performance, so where half the people see something worse, half the people see something better. But what we, at Google, learned super early on is that, at scale, your ninety-ninth percentile performance is actually incredibly important. Even if only one percent of your users have that experience, that’s still a large number of users if you have lots of users.

It’s really important to not only look at how things perform on average, but really look at these outliers who are drastically slower than everyone else and try to identify why that is.

The other thing is if you have, maybe over a cycle of a visit to a website, one hundred requests and your ninety-ninth percentile performance is really bad, then each user will potentially hit one of those. So, it’s really important to not only look at how things perform on average, but really look at these outliers who are drastically slower than everyone else and try to identify why that is. It’s obviously often because they’re on a really crappy mobile connection, but then you can still optimize for that situation and then it’s going to be better for everyone.

I’ve been very pleased to see how natural things in the end feel, and how the effort is compared to doing them side by side.

Ethan:

Well, I know I’ve learned a lot from you guys in the last half hour, so maybe we could close with this question: If any of our listeners are, today, thinking about undertaking a responsive redesign, what would your advice to them be? What have you actually learned from this process?

Malte:

The thing that I’ve learned is that it was actually the responsive side of things that were easier than I personally anticipated, and I would definitely never do anything else. It seems, in retrospect, completely ridiculous to do anything specific for each platform. I definitely don’t want to spend that time ever again. Maybe that’s a bit too crass. Sometimes devices are very, very different. But I’ve been very pleased to see how natural things in the end feel, and how the effort is compared to doing them side by side.

The lines between different devices are really blurry. You have phones with big screens, tablets that you can connect to keyboards, and laptops with touch capabilities.

Wahbeh:

Definitely, and now the lines between different devices are really blurry. You have phones with big screens, tablets that you can connect to keyboards, and laptops with touch capabilities. So, you really need a website that has both touch and keyboard support and that can scale to several screen sizes. Responsive web design is really the way to go there.

Just take a step back and try to understand the platform that you’re developing on first. Try to understand what the web provides you.

If you’re starting to build a new website and you’re considering responsive web design, just take a step back and try to understand the platform that you’re developing on first. Try to understand what the web provides you. The web was designed so that you can only download what you need and what you use, so start from there. Make sure that your site is very performant. Always monitor the size of the HTML/CSS/JavaScript that you’re sending to the client. Spend a lot of time in the Chrome profiler and go from there.

Karen:

Well, I have to say that is fantastic. I know I speak for Ethan here when I say that when we got the invitation to have you guys on the show, we were both just beside ourselves with excitement, because hearing what you guys have managed to pull off on a platform of the size and scale of Google+ is really exciting, and I know that all of our listeners will have enjoyed it as much as we did. So, thank you so much.

Wahbeh:

Thank you for having us.

Malte:

Thanks for having us.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast.

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Thanks for listening, and we’ll be back next week.