Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well Karen and I are turned up to eleven because we couldn’t be more excited to speak with Zach Forrest, who’s coming to us from Sonos. Zach, thanks so much for joining us.

Zach:

Thanks for having me.

Karen:

But before we get started, I’d like to say a few words about our sponsor, Media Temple. If you’re a web designer or developer, you need solid hosting with great customer support. Media Temple focuses on the needs of the design community, and is constantly improving their products to make hosting simple for you. That’s why they have one of the highest customer loyalty rates in the industry, with the average customer sticking around for years. If you’re looking for WordPress hosting, shared hosting, virtual private server hosting, or just want something better than a crappy $5 a month hosting plan, you want Media Temple. Go to mediatemple.net and learn about their hosting services and award winning support team. Use code RESPONSIVE to save 33% off the first three months of shared or Wordpress hosting.

Ethan:

Zach, for our audience members who may not necessarily know Sonos, maybe you could tell us a little bit about the company and your role there.

Zach:

Yeah, Sonos has been around, gosh, I think it’s been eleven or twelve years now. They were really ahead of the curve back in the day when they decided to create wireless speakers that could stream the music out of your hard drives back then, there was like a separate controller for it and everything. And then the iPhone came out and they moved to iPhone and then Android, and so it became streaming the music off of your device, right? And now everything is streaming, so. You can have up to thirty-two zones in your house and you can play the same song in every room, or you can play different songs in different rooms. I’m not really an audiophile, that’s the dirty, dirty secret, but I love it, I have plenty of these things in my home and I can’t imagine living life without it anymore.

My role there—I am a senior software engineer at Sonos, one of two front-end focused engineers, and I’m responsible for maintaining Suit, which is what we call our internal pattern library. We’re working on evolving this into a full-fledged design system, but that takes time. So, we’re working on a pattern library, we’re working on version three right now, and it powers Sonos.com and a lot of different other web properties that we have.

It was rather difficult, getting designers and stakeholders to understand what was happening. It took a long, long time to get people to think differently about how you designed a page.

Ethan:

I’d love to hear a little bit more about Sonos the website before we get into the larger ecosystem at Sonos. Can you tell me a little bit about when the decision was made to go responsive, specifically any conversations that might have happened around that time with stakeholders who had questions or concerns about responsive as a methodology? Yeah, I’d love to hear a little bit about that origin story.

Zach:

It’s not glamorous. [laughs] I came on board at Sonos around 2013 and I quickly realized that no one had really heard of responsive web design. I don’t think anyone had heard of it, I don’t think anyone had seen it. We had the desktop site and then we had the mobile site, which was hardwired at 320 pixels wide or something like that. Everything was about pixel-perfect designs and perfect images at one resolution. And we were outsourcing a lot of the work because they didn’t have enough people to do all of the front-end work that they needed to, or the website work. So I came in and I was lucky enough to have a boss at the time, my first boss that I reported to at Sonos, whose name is Jack Margo, he instinctively understood what I was trying to say.

I had been building pattern libraries at Citrix before then—GoToMeeting, GoToWebinar, those products—and I couldn’t imagine regressing back and re-engineering modal windows and all those things I was used to having in one place. So I convinced him to basically leave me alone while I developed it just as a prototype and as a demo. I think it took me four months, I built it off of Zurb Foundation because I didn’t have the team or the bandwidth to build those kind of components from scratch. So I inherited Zurb Foundation, built my layer on top of it, and gave a demo to the company—the only time I ever demoed Suit proper. One of our VPs was in there watching, and when I started moving the windows around and all the elements on the page started reflowing, just simple little prototype pages that I’d put together, his eyes kind of widened a little bit. He came up to me afterwards and said this was awesome, it’d be great to get this into the product.

About the same time we were moving from a homegrown CMS to a CMS that we bought, Sitecore, so at the time, we lifted all the content and transferred the existing design and made it responsive, which was very difficult because the existing design wasn’t built to be responsive. So, I had to come up with a lot of creative ways to make what was there look the same but be responsive and be willing to move forward in a responsive space. It was rather difficult, actually, in getting designers and stakeholders to understand what was happening; that the pixel wasn’t in a certain X and Y coordinate on the screen but could move, that was very difficult for them to grasp and it took a long, long time to get people to think differently about how you designed a page. It was very, very hard.

I have been doing a lot of thinking around this idea of a cross-platform UI pattern library. I think it’s possible with ReactJS and React Native and building your components using that framework.

Karen:

I’m always interested to talk to organizations that are dealing with the responsive web but also with a large app environment, app ecosystem. So, obviously Sonos is on a variety of different apps. Do you think of all of these patterns that you’re creating and think of these responsive processes broadly as something that would apply to apps too, or is it really only web?

Zach:

Right now, the existing ecosystem is mostly a very definite line between native and web. This is changing, like we just now finished a project, I think it was our first or second story where there’s a web page inside of the app.

But to your larger point, I have been doing a lot of thinking around this idea of a cross-platform UI pattern library. I think it’s possible with ReactJS and React Native and building your components using that framework. And I think that when you use React, you’re just changing the rendering context, one rendering context being the DOM, one being iOS, one being Android. I’ve experimented with this on a very, very small level, but it’s something that I can’t get away from and something that I keep talking about. And even if the next step is we have patterns for the web but we have corresponding patterns built for iOS or Android, even if that’s the intermediary step that I have to take, then I’m willing to do that because I honestly believe that you need to.

I can’t remember who said this, but someone I read on Twitter lately said, “You need to design the way you design.” When you talk about pattern libraries and design systems, you’re really talking about products that serve other products. So, I can’t get away from those concepts, and even in some places like Sonos where it really feels like I’m kind of shoehorning responsive designs and pattern libraries into the ecosystem, I’m doing it for very good reasons and because I want to improve the overall product.

It’s very much a content problem trying to define who those users are, what they need, what they’re looking for, and giving them the appropriate content. Right now it’s kind of like one-size-fits-all.

Ethan:

Zach, if I could just circle back on something you mentioned before, you mentioned that before the responsive redesign went live, Sonos was balancing a separate m-dot experience and a desktop site. When you were transitioning into something that was more device agnostic, were there conversations that came up about the needs of the mobile user versus the needs of the desktop user? Is this something that Sonos still talks about, and how do they think about the needs of those two different contexts?

Zach:

So, a little history. When I was at Citrix and I was building a pattern library, I did it on the product side, I did it for when you locked into the GoToMeeting or the GoToWebinar product, and I never penetrated the marketing side of things. On Sonos, I went into the marketing side of things first and then I’m slowly penetrating into the product side. Initially, there weren’t a lot of conversations about the needs of a desktop user versus a mobile user until we started talking about image bandwidth, and that was about the same time that Picturefill was becoming popular—we never used it because Zurb Foundation had a different solution for those kind of things.

It’s been pretty recent where people have started to consider that a desktop user has very, very different needs sometimes when it comes to our marketing, comes to our product as opposed to mobile users. This idea hasn’t penetrated our UX or our designs very much yet, I’m working on that at this time. It’s also a content problem, it’s very much a content problem trying to define who those users are, what they need, what they’re looking for, and giving them the appropriate content. Right now it’s kind of like one-size-fits-all.

Changing that conversation was difficult. It was really an education process, getting them articles, everything that I could find about responsive web design.

Ethan:

Tell me a little bit more about that, Zach. Specifically as you’ve been having these continuing discussions about what the needs of your audiences are, and as you’ve been supporting a more responsive experience, how has your design process changed at Sonos? How are you actually circulating designs internally? What kind of applications and tools are you using? Are you doing most of your work in-browser or are you doing some in Photoshop and Illustrator? Just tell me a little bit about your day-to-day and how that’s changed.

Zach:

I’ve always done most of my work in the browser. Any designers that work with Sketch or Photoshop or any of these other tools, the conversation that I’ve been working on with them is—to that earlier idea—changing the way you think about the design page. Not looking at a design like a poster and saying, “That’s how it’s going to look on a web page,” but to take those ideas and the visuals or the carousels or the content pieces, and the components, is what I like to call them, and break them down into individual things that can scale to many different viewports, can work on many different devices.

Changing that conversation was difficult. It was really an education process, getting them articles, everything that I could find about responsive web design, everything I could find about considerations that you have to make when you’re designing for multiple viewports. It was a novelty for a lot of the people I was working with. That has very much changed. Over the last thirty months, I think the conversation has been completely different. And while sometimes they’re still not grasping how a certain pattern or interaction affects a mobile user versus the desktop user in different ways, maybe something like hover versus click, they are very much coming along with the conversation and are excited about learning new things, and it’s really the conversation between me and them is no longer me versus them, but me along with them and really increasing the way that they think about these ideas.

When I have those tests running every time I commit code to a build, all of those tests are executed and I can make sure that there’s no regressions and there’s nothing that I need to worry about.

Ethan:

Let me switch on to something that is really interesting to me, which is testing and QA. Obviously with a relatively small digital team, you’ve been able to do quite a bit with the responsive redesign. Tell me a little bit about how you’re actually able to see how this is performing on different devices. Do you have any infrastructure for that? Do you incorporate testing into your design process? Tell me a little bit more about how you actually figure out how to support all these different devices you’re designing for.

Zach:

So I discovered pretty quickly after launching Suit v1 that the dependencies that I had, like Zurb Foundation and even my own plugins that I’d written and some of my own patterns that I’d extended, could quickly break. So I went about working on how to write automated tests with the Selenium server, even writing unit tests with Karma or some other unit test framework. I ended up going through a few different iterations. At this time, the people that were working on the website, the QA people, had never done automated testing before, and it was rather new to me too, like I had to do a lot of research and education on my own part. So after a few different iterations, I ended up using a tool called WebdriverIO, and what I love about it is that you can boot up a Selenium server that will run Chrome, or Firefox, or even Safari sometimes, and you can run your automated test and it will click on buttons and it will move over, verify text, and it will verify CSS properties and it will verify interactions, and you can even take screenshots for visual regression to see if elements on the page have moved.

I’ve been doing a lot of teaching and workshops with the web QA people, teaching them JavaScript so that they could write these tests. We’ve also hooked into BrowserStack, which WebdriverIO completely supports, and we can run our tests on any browser that BrowserStack supports. WebdriverIO also supports Appium, you can run the iPhone simulator itself—I think you can run the Android one too, I haven’t tried it, though. But I actually have JavaScript tests that boot up Safari on the iOS simulator and will actually click on buttons and verify everything that I want to be there, to be there. So, it’s really been a great help, especially when I have those tests running every time I commit code to a build, all of those tests are executed and I can make sure that there’s no regressions and there’s nothing that I need to worry about. Because I deploy up to, I think my max one day was five times, and no one noticed, nothing was broken, and being able to move that quickly and deliver continuous improvement is something that’s very valuable to me.

You can’t really just make a responsive website the size of Sonos overnight, it’s just not gonna happen.

Karen:

Let me ask broadly, how do you measure the success of this website or measure the success of this responsive redesign? What kind of analytics or data are you looking at?

Zach:

Oh man, there were two particular cases that we completely dodged the bullet on, and without us even knowing it. The first one that I can completely remember is that Google came out with changes to their algorithm back in 2014 I believe, where if you didn’t have a mobile-friendly site, they were going to kind of knock you down in the algorithm or in the SEO, or whatever. But they were starting to put those mobile-friendly tags in their search results when you were on a phone device, right? And if you didn’t have that, then that would’ve reflected poorly, I don’t know how, but it was all over, I think I read about it for two or three days. We had been on Suit for over a year at that point, and what we had before was completely not responsive, it wouldn’t have worked. It would’ve been chaos to see that story, have it circulate in the company, and then try to come out with some sort of solution to fix that, because you can’t really just make a responsive website the size of Sonos overnight, it’s just not gonna happen.

We also were tracking Google Analytics as well as some other tracking tools that we have about how the users were using our site, and we found that our mobile usage just skyrocketed after we implemented responsive design. We had an m-dot site before that, but the numbers didn’t compare to the responsive one. It wasn’t even in the same ball field.

If you’re going to do a responsive site, it’s going to be hard work, it’s not going to be glamorous, you’re not going to feel like a hero.

Ethan:

Well Zach, Karen and I can’t thank you enough for coming on the show to share a little bit about what you’ve been able to do at Sonos. Before we let you go, however, I’d love to hear if you have any advice whatsoever for anybody in our audience who might be starting a responsive redesign today. What’s something they should keep in mind?

Zach:

I would say that in my own personal experience that if you’re going to do a responsive site, it’s going to be hard work, it’s not going to be glamorous, you’re not going to feel like a hero. Even now, sometimes I feel like a lone wolf in the forest. But I would say that when I look at where we were thirty months ago and to where the Sonos website is now, I can’t help but be a little proud of it. I also see all the things that I keep wanting to improve and that I want to change, but we’re going to get there. All I can say is take your time and do your work well and leave it at that. I don’t think I can have any other piece of advice that’s going to serve you better than be persistent and just do your job.

Karen:

Well Zach, I think that’s great advice for anyone. Thank you so much for taking the time to talk with us today. It’s really interesting to hear what you’ve been doing at Sonos and I look forward to continuing to use your product.

Zach:

Thank you very much. I am glad to be here. Thanks for having me.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast. Thanks also to our sponsor, Media Temple. Go to mediatemple.net for easy to use hosting and 24/7 customer support.

If your company wants to go responsive but you need a little help getting started, Karen and I offer a two-day onsite workshop to help you make your responsive design happen. Visit responsivewebdesign.com/workshop to drop us a line—we’d love to hear from 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 episode at responsivewebdesign.com.

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