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, I’m frankly somersaulting through my office because we are so excited to speak with Louise Halliday and Jake Grimley, who are coming to us from the Royal Albert Hall. Louise, Jake, welcome.

Louise:

Thank you very much.

Jake:

Hi.

Ethan:

So, why don’t you both introduce yourselves and tell us a little bit about what you do?

Louise:

Okay, I’ll go first. My name is Louise Halliday, I am head of marketing and digital at the Royal Albert Hall, and I’ve been here for just about the same amount of time as our project to launch our new website has been running. So, it’s been my baby.

Jake:

And I’m Jake Grimley and I’m the CEO of a digital agency called Made Media, and we’re a kind of a long in the tooth agency that deals with websites, particularly responsive websites at the moment, and we sort of specialize in performing arts—that’s our “niche,” if I’m going to be American.

Karen:

But before we get started, I’d like to say a few words about our sponsor, Harvest. I have to make a confession: I hate, hate, hate tracking my time. It always makes me feel like Fred Flintstone chiseling out his time boulder before he slides down that dinosaur’s back so he can go home. But using Harvest doesn’t feel like punching a time clock. Harvest is a beautifully designed tool that lets you track your time on client projects, start a timer from a web browser or mobile device, and it even lets you send invoices when your time tracking is complete. If you’re a responsible business professional you should be keeping tabs on which clients and projects are making you money—and the way to do that is through careful time management using Harvest. So check out Harvest today. Go to getharvest.com and start tracking your time. They’ll give you a thirty day free trial. When that’s up, enter the code RESPONSIVE at checkout and you’ll save 50% on your first month. Don’t hate tracking your time. Get Harvest.

There’s a brave new world out there of beautiful sites that work on a range of devices and we knew right from the onset, from the start, that that’s what we wanted.

Ethan:

[laughs] Brilliant. Well, I’d love to hear a little bit about the decision to go responsive. I mean, the new Royal Albert Hall site is stunning, frankly, and really made an impression on both Karen and I. Tell us about some of the discussions around why go responsive with something like this.

Louise:

I think it was fairly clear from the whole side, from even before we sent out the RFP, that we wanted a responsive website. We knew that our traffic already, even in 2013, was moving more and more away from PCs and desktops. There’s a brave new world out there of beautiful sites that work on a range of devices and we knew right from the onset, from the start, that that’s what we wanted.

When we encounter an RFP for a new website design, I’d say almost invariably pretty near the top of the list of requirements is a responsive design.

Jake:

Yeah, and I’d back that up and say that maybe for about three years now, when we encounter an RFP for a new website design, I’d say almost invariably pretty near the top of the list of requirements is a responsive design. I think we’re getting to a position now where certainly organizations within this kind of industry understand the benefits of responsive design and don’t need a lot of selling on that concept.

If I recall this RFP in particular, I think one of the questions on it was, “How are you going to make sure our website works on all different kinds of devices?” but I don’t think there was any serious expectation that we were going to come back and say, “We’re going to build an app for each different device” or something like that. I think it was pretty clear in the context that the correct answer was going to be that they were looking for a responsive website.

Mobile is probably just the most accessible web browser that people have these days, so perhaps we shouldn’t be presuming that just because someone’s got a mobile phone they’re actually sitting in the Hall.

Karen:

Let me follow up on that a little bit and ask if you think that mobile users and desktop users need different information or different services. One of the things that we have heard from other guests sometimes who are dealing with information that will be presented on a mobile device in a local context is that a desktop user is probably planning in advance, they’re researching, whereas the mobile user is going to be actually physically in the Hall and may want information prioritized or presented in a different way. How did you talk about the difference between mobile and desktop users?

Jake:

Well, there was a little bit of debate about that question actually, and we’ve certainly ended up in a place—I don’t know if we were 100% thinking about the place we ended up in—there’s still more exploration to do around that issue, I think. So early on in the process, there was an additional agency who we were sort of consulting on strategy and so on. In fact, it was Blue State Digital, who are quite well known for their work on the Obama campaign, and one of the things they were looking at in the strategy was should there be a very sort of geolocated mobile experience. And there was some debate about following that strategy, and I don’t think we feel today that that’s a bad strategy. But I think Made Media’s line was a little bit more that, actually, the mobile is probably just the most accessible web browser that people have these days, so perhaps we shouldn’t be presuming that just because someone’s got a mobile phone they’re actually sitting in the Hall using the mobile phone.

We’re seeing—even before we had a responsive website—almost fifty percent of our traffic was on mobile or on tablet.

Louise:

I think that’s right, and I don’t think we see necessarily that the pattern of use is that more people are using the website on the mobile just because they’re sitting in the Hall. We’re seeing—even before we had a responsive website—almost fifty percent of our traffic was on mobile or on tablet. So, however many, six million users a year, were not in the Royal Albert Hall. So I think, because transactionally it was almost impossible to book a ticket on the old website using anything other than a PC, we were definitely seeing people booking tickets through PCs or through desktops. But I don’t think that necessarily meant that people were browsing the website, even when it wasn’t very friendly to their device, on anything other than a PC, if that makes sense.

Because of the nature of that scoping and client/agency relationship, there’s still a lot of responsibility to really define what it is we’re trying to build and what the scope is.

Ethan:

Yeah, that makes perfect sense. Something I’m also a little curious about would be scoping. Jake, maybe this would be a question for you: As you’ve worked on a number of responsive projects, how do you and Made Media tend to approach structuring some of these agreements? How do you actually think about designing the scope for a responsive redesign?

Jake:

If I really had the answer to that question, I’d probably be a lot better off than I am now, because actually defining scope on my projects is the hardest thing about the job. I think on this job, we took a slight departure from how we would ordinarily do it and it worked out quite well. For us, when we look at wireframing and UX, that’s kind of fulfilling two roles. On the one hand, we’re trying to figure out what the best user experience is and how it’s going to work for the end user. But at the same time we’re also trying to use that process to kind of define the scope of what it is that we’re going to be building. So for us, that kind of wireframing/UX/prototyping part of the job goes hand-in-hand with scoping features. And although we try to work in an agile context more and more, because of the nature of that scoping and client/agency relationship, there’s still a lot of responsibility to really define what it is we’re trying to build and what the scope is so that the client knows they’re going to get value for money.

This method of working was actually instigated by the Hall, they suggested they would like to see not just responsive but really a mobile-first approach to design.

In the past, there’s been lots and lots of flat mockups and Photoshop comps and things like that, but in a responsive context, that’s harder and harder to use as a tool, because you’re never really giving the client a sense of what the responsive design is and how it’s going to work.

Other than early comps that are all about look-and-feel and brand, as soon as we moved into design it was pretty much prototype, liquid, responsive templates from the get-go.

In this particular project—this method of working was actually instigated by the Hall, they suggested they would like to see not just responsive but really a mobile-first approach to design. What we did, effectively, was that we started out with wireframes that presumed everybody was on mobile. We were trying to figure out the function and the interactions with the website purely from a mobile point of view, from the perspective that if we’re looking at functionality and it has to work on mobile, that’s the most stripped down way to look at those user interactions. All the wireframing was mobile, and then as soon as we’ve used that to help define scope and experience and so on, we move very quickly from mobile to responsive prototype templates, where wireframes are starting to move into design.

Other than early comps that are all about look-and-feel and brand, as soon as we moved into design it was pretty much prototype, liquid, responsive templates from the get-go. That was a change to our standard approach, and I think it involves a bit more trust in some ways, but in other ways it really helps you to really show what you’re delivering. And from that point of view, I think that went very smoothly; we were very happy with it, we would certainly do it that way again.

It is quite a simple layout, which was definitely informed by designing mobile-first and then scaling up rather than designing PC-first and then scaling down.

Louise:

From our perspective, it was great because for those of us who were not necessarily entirely sure how a responsive site was going to work, we had these responsive templates where we could really, really visualize exactly how it would be on all the different devices, and explain breakpoints and things to people who were non-techy in a visual way. That was really helpful. We also did some usability studies early on with just very, very raw mobile-first wireframes. Just seeing how real users interacted with the wireframes did inform quite a lot of decisions we made about button placement and design and stripping things back. What we found was that designing in a stripped back, simple way actually meant that we could scale up, and it made the website more beautiful because it is quite a simple layout, which was definitely informed by designing mobile-first and then scaling up rather than designing PC-first and then scaling down.

All we did was to say to everyone, “We have this new beautiful website. Please don’t ruin it by giving us rubbish pictures.”

Karen:

Let me ask a little bit about the actual content, the program descriptions. Can you talk about how your writing or your editing process for how you describe things. Did that change at all as you were thinking about supporting different sizes of screens?

Louise:

I’d love to say it did. Yeah, we just said, “Fewer words, please!” to all of our promoters. Because the Royal Albert Hall is predominantly a receiving house, the majority of the performances that are put on here are brought to us by promoters, so they will give us their photographs, which are very often terrible quality and stretched and non-usable formats and inserted into Word documents. So we have to make the best of what we possibly can of what they’re giving to us. All we did was to say to everyone, “We have this new beautiful website. Please don’t ruin it by giving us rubbish pictures, and we will edit your copy down to this many words.” This is specifically on event pages, because those are the pages that we don’t really have so much control over in terms of content.

And it’s really, really difficult to make everything, from “Nutcracker on Ice” to Champions Tennis, to the opera, to Bob Dylan—absolutely everything—look like it’s part of the Royal Albert Hall website because it’s such an eclectic program. So even if all of the artwork and all of the copy is fantastic and clear and clean, it is very, very different. But what Steph, our major designer, did—which has been incredibly helpful to us—was to build in this panel where you select a highlight from an image, and the side panel which goes with that image is taking the palette from the event photograph and that immediately gives the page a designed look and feel, which has just changed the overall quality look of the website dramatically.

In the main, it’s PDFs being exchanged with comments and they’re starting life in OmniGraffle.

Ethan:

Speaking of look and feel, I’d love to hear a little bit more about some of the applications and tools that your designers actually use to bring this design into life. Jake, you talked about that transition from very stripped down mobile-first wireframes and then sort of evolving those into prototypes and then actually layering on some aesthetic. What programs and tools were you actually using to make that happen?

Jake:

For wireframes we’re really just using OmniGraffle. At the state that we’re wireframing, we’re still pretty old school with wireframing; we’re just starting to use InVision, actually. But in the main, it’s PDFs being exchanged with comments and they’re starting life in OmniGraffle. Actually, since then, we’ve started looking at using Keynote as a wireframing and prototyping tool quite seriously, which forces you to strip things back to another level as well. For sure we’re still using Photoshop a lot for initial mood boards, brand treatments, and so on. So yeah, Photoshop is still in the mix for all of that sort of stuff.

We have an HTML and CSS pattern framework that has patterns for a lot of the common use cases that we come up against.

Illustrator is making a comeback in our toolset because we’re using SVG graphics so much. Actually, there’s a lot of intricate work with venues like this because they have these extremely large and comprehensive seat maps, which is quite a big part of the job, and there’s a lot of Illustrator involved in that.

But once we get into the responsive templates, we’re really into HTML and CSS, and because we have that kind of specialism with this type of client, we have an HTML and CSS pattern framework that has patterns for a lot of the common use cases that we come up against. We’re often having to do things like, calendars are very important, date selectors, there are standard things associated with marketing events, information you need, certain panels of information and so on.

Over the years, we’ve developed an HTML and CSS framework that has some of those patterns. The use for them is different for every client, but what it does mean is that we have a library to go to as a starting point, where some of the issues around responsiveness and so on have already been considered, and so we’re not working from a complete blank canvas. So that allows us to get something up and running quite quickly, and then through iterations with the client and finding out what’s really genuinely unique and different about that client and that design, we’re able to refine and polish until it’s really finished.

There’s a reason why websites are prototypical, why they kind of conform to a specific layout, and that’s because it’s what people expect and it’s because it’s probably the best way that people can navigate your website.

Louise:

Something really early on, something that Steph, the designer, said to us which really resonated with us was that you don’t want something which is too fundamentally different for the user. There’s a reason why websites are prototypical, why they kind of conform to a specific layout, and that’s because it’s what people expect and it’s because it’s probably the best way that people can navigate your website. So, we kind of really took that onboard because we were thinking about doing really crazy creative things, like because the Royal Albert Hall is round we thought, “Well, maybe we should have some kind of circular navigation system and do something a bit different.”

Because we’re quite complex, because we’re a charity, and we have members, and we have an education and outreach program, and we have all these different events, we used to have a very, very complicated top-level nav. We were persuaded by Made Media very early on to really simplify it, because even when we had that very complex nav, we found that people were going to one or two of the main buckets of content. So, simplification was absolutely essential.

When we had a process that was very much about static comps, everyone was trying to cover their back to make sure that everyone understands that design was signed off.

Karen:

Talk to me a little bit about how these new processes and new tools change the way that you review work-in-progress. As an agency working with a client, how do you solicit feedback on prototypes, or how do you communicate to a client that a pattern library is different from static comps?

Jake:

One of the interesting things about it is—when we had a process that was very much about static comps, everyone was trying to cover their back to make sure that everyone understands that design was signed off: That pixel was in that place in that design, therefore if that pixel is in that place in that screen, the design has been achieved. I can certainly remember five to ten years ago I would literally have an eye for the pixel space so that I could walk past a designer’s screen and say, “We said eleven over eighteen and you’ve got twelve over sixteen there, so we have not done the design that’s been signed off by the client.” We can all agree those are dark days we don’t want to go back to. [laughs] Also, it’s kind of denying your responsibility as a designer by asking the client to sign off on some very specific things that perhaps aren’t all that important to them, just so that you can say, “This design was signed off, and that’s what happened.”

Fundamentally I think doing responsive design requires a high degree of trust between client and designer, and that can only be a good thing.

The first thing we have to look at, before we talk about techniques and methods and things like that in the sign-off process, is that fundamentally I think doing responsive design requires a high degree of trust between client and designer, and that can only be a good thing. When we’ve been working responsively, sometimes we’re having to say to clients, “You know what? We’re not actually 100% sure where that breakpoint is going to be or exactly what size that text is going to be at within that context, on that given device, at that time.” There is going to be a bit of a degree of playing by ear, refining, polishing to get things right, where we may never be able to pinpoint where the client signed off that comp.

Inevitably, if you can get to actual working responsive prototypes and templates as fast as possible, that really helps build confidence because people know what they’re agreeing to.

The flipside to that is that the client has trust that you’re trying to do the best and that you’re going through all these different devices and so on. We have trust that the client is not going to be holding us up to absolutely every pixel, saying, “When you sent me this comp, it looked like this and now I’m on my strange tablet device and things are looking slightly different.” That trust has to be established. I guess what that goes back to is the education process, the working together on the big picture rather than just asking for sign-off on design comps. I guess that’s what builds the trust.

I think that enthusiasm and positivity carries through the process, so sign-offs and approvals become easier, not more difficult.

That said, if you can get into that mode of working, I think inevitably, if you can get to actual working responsive prototypes and templates as fast as possible, that really helps build confidence because people know what they’re agreeing to and can see that it’s moving in the right direction at an early stage. With the proliferation of devices—at that stage in the project, it’s still very exciting, and it’s exciting for the agency and exciting for the client to be able to just grab all the different devices they’ve got and have a look at the prototypes and see how it’s behaving differently. I think that enthusiasm and positivity carries through the process, so sign-offs and approvals become easier, not more difficult.

Louise:

I think that’s probably typical and that is true. But in our case, there are a lot of cooks. And also we were going through a rebranding, so we knew from the very beginning that we were going to be redesigning the whole look-and-feel of the brand, not just the logo, so that was definitely an added level of… It was a bit chicken and egg, because you were designing the templates and we had no idea what our color palette was going to be, even.

Web projects just take longer these days, so I think it’s becoming more and more common that there’s a rebrand in the middle of a web design project.

Jake:

Mhm. So, this is interesting because it’s really the opposite of how you would expect a design process to work maybe five years ago, which is, “Let’s get our brand identity fixed and sorted, let’s make sure we’re doing a design that complies with the brand that is then signed off.” Really, I suppose we’re expecting a lot of the clients to say, “Here’s a design that we’re asking you to go along with, but we’re using an old brand, but we know it’s going to be a new brand and we don’t know how it’s going to work, but we’re working around that,” and asking people to understand that. I guess it’s a big ask.

Everyone, client-side and agency-side, is effectively being asked to abstract things a lot more in their heads to be able to recognize the separation between content, branding, layout, navigation.

But I also guess it’s not that uncommon because I think people are rebranding more often. Web projects just take longer these days, so I think it’s becoming more and more common that there’s a rebrand in the middle of a web design project; it’s almost becoming standard, actually. So I think everyone, client-side and agency-side, is effectively being asked to abstract things a lot more in their heads to be able to recognize the separation between content, branding, layout, navigation. It’s a big ask from someone who doesn’t come from a web design background to separate those things out in their head. Maybe we just got lucky with a great client this time. [laughs]

Louise:

Maybe you just got frustrated with us a lot and had to keep reminding us. [laughs]

Jake:

[laughs]

Ethan:

I love all the talk of trust going around. It just made me think that one of the things that erodes trust pretty quickly in a responsive redesign project is all these wonderful browsers and devices we’re designing for. I’d be curious to hear of how discussions of browser support came up in the project. How did you manage QA? How did you actually talk about how experiences might change from not just different sized screens but browsers that might be more than just a couple years old?

Jake:

Well, I suspect if I was to go back to the original contract for the project, which was probably drafted a couple of years ago now—or our original proposal—there was probably a list of devices and browsers in that which technically we were contractually obliged to deliver for. And I suspect if I opened that contract now and looked at the list of browsers, it would be laughable.

Almost certainly during the course of the project, all kinds of new devices and browsers were coming out as well, and some were becoming obsolete whilst new ones were coming onto the scene.

Louise:

I know, because we have a spreadsheet and we did test against every device, every browser, every operating system that was in the contract.

Jake:

Yeah. So it was discussed, it was specified. But almost certainly during the course of the project, all kinds of new devices and browsers were coming out as well, and some were becoming obsolete whilst new ones were coming onto the scene. If I recall correctly, we probably would’ve originally based our device list on measurable proportions of traffic. We would’ve looked at a certain cutoff point in the Google Analytics and said, “If it falls below this percentage, we’re just going to hope that it sticks to the web standards and it’s usable and it’s functional. But if it’s above these percentages, it’s on our device or on our agent or browser list and we’re going to formally test it on those devices.”

When it comes to content and so on, you tend to be able to—if the devices are using standard compliant browsers, which there tend to be a couple of mobile variants and so on, it tends to be okay on the content side. Where it starts to get particularly nitty gritty is on those more technical, difficult features like the seat picker, things like that, where the peculiarities of devices and browsers and operating systems really start to show themselves a bit more, and that’s where we expect to see more significant differences between devices.

Louise:

Since we launched the new site, we have had a couple of customer feedback items, one of which someone was complaining they couldn’t use it on iOS 2, which we thought was interesting. It’s a miracle you can do anything on iOS 2, but yeah. And someone complained that they were suffering from vertigo on their particular browser because the parallax was causing them to feel dizzy. So we’ve had some pretty interesting user feedback.

We’re not just expecting the website to be available on people’s own devices but we’re also going to be using parts of it around the building.

Karen:

Speaking of feedback: I’d love to know, how do you measure or evaluate the success of this redesign? Like, what are you looking at to know if the responsive design worked for you?

Louise:

There are three things that we were looking at. We’ve got a digital strategy and there are three touch points for us which are essential. One is more tickets, less waiting; so, there’s concurrency measures and orders per hour—and so ticket sales, basically. One is more interaction in more places. So, we’re not just expecting the website to be available on people’s own devices but we’re also going to be using parts of it around the building. We’re going to install tablets and bits, like the time machine or the history section, we will have available around the building and we’ll push people to that content. And the third one is to tell the full story of the Hall. The way that we’re measuring that is about dwell time, the amount of time that people are actually spending on the website.

Jake:

In terms of hard numbers, the site has not been live very long but one of the metrics we’ll be looking at is the improvement in actual transactions on mobile devices. So, actually the people who complete a transaction in checkout using a mobile device, which is a bit of a sitting duck as a target, if we’re honest, because on the previous site it was almost impossible to checkout using a mobile phone—just too tricky. So, we’re expecting to see a large improvement there.

The site has really grown to be an editorial site as well as a transactional site, and I think that’s predominantly going to be measured through, well, time.

As Louise says, the ticketing metrics are quite hard and fast, and quite clear, and will be easy to measure, but that was only a third of the digital strategy of the whole that we’re trying to accomplish with this redesign. If you visited the site previously, you would have known there were a lot of shows on that you could book tickets for, but you may have had the sense that you were at some website run by a management company that managed the event at the Hall or something. You didn’t get much sense of the rich history and the work that the Hall does. The site has really grown to be an editorial site as well as a transactional site, and I think that’s predominantly going to be measured through, well, time.

I think we’ll also see an impact on transactions as well. When people look to buy tickets, they don’t always have to buy them from the Albert Hall; there are other places they could go to buy tickets. What we’re looking to do is—apart from just selling tickets as effectively and quickly as possible—we want people to build a relationship with the Hall so it’s the place that they come back to and a place that they understand the good work that the Hall does, and want to become a supporter of the Hall as well as just a purchaser.

It’s a much more revisitable website than just, come to the site, book your tickets, go away.

Louise:

That’s actually changing our behavior as a marketing team. So for example, last night there was a prom which featured Nicola Benedetti, the violinist, and she’s returning in September. But we didn’t just send an email out today which said, “Book tickets for Nicola Benedetti when she comes back in September.” We sent an email out which was much more about, “Here’s the pictures and reaction from last night. Share your comments with us, we’ll collate them into a memories page and you’ll be able to come back and relive the experience. We’ll host the recording that BBC made of it.” So, it’s a much more revisitable website than just, as Jake said, come to the site, book your tickets, go away, and you might come back to just plan how to get here on the night and that would be it, that would be the level of your interaction with the website.

We started looking at visuals far too early in the process and confused the situation because we hadn’t put in the groundwork of thinking about “what’s the purpose of this content?”

Ethan:

Well Louise, Jake, I have to say, this has been a really fascinating discussion. I’ve been learning quite a bit and it’s amazing to see this website launched and live. I’d be curious to hear, as you’re coming to the end of this redesign project, do you have any advice for our listeners, folks who might actually be starting their own responsive redesigns right now, about lessons that you’ve learned or things you might do differently?

Jake:

I think there were a couple of mistakes we made along the way. I mean, certainly I think the design product went very smoothly overall, and buy-in, and it worked well. But there were definitely some mistakes that we made and some lessons that we would probably pass on.

Slowing the pace down, doing that thinking as a partnership has a massive impact on building that trust and understanding, and allowing your client and the client stakeholders to understand why you’re doing things.

One of those is to resist the pressure to go too fast into a styling consideration. I think this is something that we felt pressure on, but it was not really coming from the client, we’re just used to this pressure so we were trying to fulfill it. So we leapt a bit too early into trying to show visuals of how it would look, how the brand styling would work and so on. Actually, we did that because usually we find clients want to see something very early on; they’ve been wading through contracts, looking at proposals, now they just want to see something. We felt we should show something and actually started looking at visuals far too early in the process and confused the situation because we hadn’t put in the groundwork of thinking about “what’s the purpose of this content, why are we featuring this on the homepage?” We had always intended to address those questions, but we were trying to provide some instant gratification with some visuals early in the process.

I would probably recommend to people embarking on this process: do take the time to think things through and do make sure, if you’re in an agency situation, that you’re involving the client in that thinking-things-through process rather than presuming that, because you get it, you’re going to come up with the right kind of solution too early. Slowing the pace down, doing that thinking as a partnership has a massive impact on building that trust and understanding, and allowing your client and the client stakeholders to understand why you’re doing things. I definitely advise people to, in some senses, slow down that early phase of the project.

Louise:

And then don’t leave the horrible jobs until right at the last minute. [laughs]

Jake:

[laughs]

Louise:

My piece of advice would be don’t try and put a 5,000-seat auditorium onto a mobile phone because it’s almost impossible to do, but we kind of had to do that. We came up with this solution, which I do think works really well, but we don’t just have one 5,000-seat auditorium, we have ten different versions of that 5,000-seat auditorium. And we had one sort of select your own seat plan which worked brilliantly, but we had nine that didn’t, and we left drawing those until too late and that was extremely stressful. So, I would definitely recommend getting the nasty jobs out of the way early.

Karen:

Well, contrary to that, this has been a real pleasure to spend some time with you today. I have so much enjoyed hearing this story. I think you have fantastic perspective, and Ethan and I just want to say thanks to both of you and we’ll look forward to hearing more about what you’re up to.

Louise:

Thank you very much.

Jake:

Thanks. It was a pleasure.

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.