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 cartwheeling with joy through my office because this week we have Erik Runyon, who comes to us from the University of Notre Dame. Erik, thanks for joining us today.

Erik:

Thank you, Ethan. It’s a pleasure to be here.

Ethan:

So, why don’t you introduce yourself to our audience and tell us a little bit about what you do at Notre Dame?

Erik:

So, my name’s Erik Runyon, I’ve been with Notre Dame for coming up on eight years. I’m presently the technical director for marketing communications, which we handle the majority of the public-facing websites at Notre Dame, which is probably around 460 to 470 websites.

We started doing what we referred to internally as “adaptive websites,” which are similar to responsive websites minus the flexible grid.

Ethan:

Wow, that’s pretty impressive. Well, of those websites, I think the one that I first became aware of was when you guys relaunched ND.edu, the main Notre Dame website, back in I think 2012 or something like that. I’d love to hear a little bit more about either that redesign or maybe your first responsive project—like, how you actually got your stakeholders at the university to go responsive. As you were trying to get them to buy in, did they have any concerns or questions, or were there any difficult discussions around responsive design as a methodology?

Erik:

So, it was a very iterative approach to get to where we are with responsive web design. We started doing mobile-specific stylesheets on our website back around 2007 or 2008, and then when the iPhone came out, we started adding in some iPhone-specific hacks to create a nice-looking view so you didn’t get the full website view where you would have to scroll in, and then shortly after, when Android phones started coming out, we abstracted that to webkit in general. Then when tablets started coming out, also being on Android, we realized that what we were currently doing wasn’t going to work. So, we started doing what we referred to internally as “adaptive websites,” which are similar to responsive websites minus the flexible grid.

I don’t recall right now, but I must’ve missed your initial responsive web design post on A List Apart, so we didn’t start doing responsive web design until more like the spring of 2011. So, we did a couple of client projects using adaptive; first and foremost was our magazine website. They were very interested in creating a website that looked great on both mobile and tablet and desktop, and so we did some work with them, created something that they really loved. It’s been updated since then to be responsive with a completely different look.

There wasn’t much discussion around responsive web design when we started using it, because to us it was just the next logical step going from basic mobile supports and then adaptive, getting into responsive.

But as far as our stakeholders are concerned, there wasn’t much discussion around responsive web design when we started using it, because to us it was just the next logical step going from basic mobile supports and then adaptive, getting into responsive. That proved not to be the greatest approach, because up until that point we were doing static mock-ups of all of the websites that we created. So, a client would have a JPG of what their website was going to look like. We had one client that we worked with on a lot of websites, and so we were building one of their sites responsive, hadn’t really brought up responsive with them, and at what point early in the build they resized the browser and saw things move around. They were concerned about that and came to us asking why, and so at that point we learned that we needed to start having some larger conversations with the campus communicators and the people that we worked with about what responsive was, why it was important, and that’s how we were going to be building sites going forward. So, we did a series of what we called “brown bags,” where we invited communicators to come and join us for a lunchtime meeting and we would sort of demonstrate responsive and the advantages of it. We received zero pushback at that point.

And so as far as taking our main website responsive, we were building out a new version of ND.edu in May of 2011, and we’d built it in that adaptive structure, where it did not have the flexible grids. But we had ordered your first responsive web design book, and that came in the week before we were going to live. And so after reading that, we quickly decided to go back and sort of reformat all of the grids to be responsive. And so when it launched in June of 2011, it was a fully responsive website—not mobile-first, because we were still very much into building desktop-first and then working our way down to mobile. It wasn’t until working on the 2012 redesign that launched April 1st of 2012 that we had a mobile-first responsive web design for ND.edu.

For all of our work that we do, we don’t hide anything from mobile users. Things may get shuffled around a little bit depending on the content priorities.

Karen:

Let me follow up on that and ask about how do you conceive the difference between what a mobile user might need and what a desktop user might need? I can remember right about that era, like 2011 or so, there was the sense from universities that I spoke to that students needed an app so that they could manage the things that they would need while they were on campus, but the idea that anybody would ever want to search for a college or explore potential schools that they might want to attend on their phone seemed faintly ridiculous. Do you have a sense today of what people’s expectations are around what mobile and desktop users need? Has that changed?

Erik:

So, internally it hasn’t changed. For all of our work that we do, we don’t hide anything from mobile users. Things may get shuffled around a little bit depending on the content priorities that we set forth when we’re working with a client early on. But we don’t allow discussions of “Oh, let’s just hide that; mobile users don’t need that,” because the fact of the matter is users will use whatever device they have to get what it is that they’re looking for. That being said, we did put up an m-dot site back in late 2009, but that was mostly utility things for the internal campus, not really geared towards external audiences or prospective students. It wasn’t until within the past maybe year and a half that we’ve actually had a native app, both iOS and Android. Up until then, we were primarily focusing on just mobile web and having a good responsive experience for everybody.

And one interesting thing that we found out early on is one of those modules in our m-dot site—we worked with the food services to essentially get a feed of the daily menus for the dining halls—and so we built out a section in our m-dot site that had the menus. When we started looking at stats, we noticed that a huge amount of the traffic was coming from desktop sites as well, primarily to that section, because that’s the only place where that data was available. So, that just drove home the point to us that be it desktop or mobile, people are going to use the device that they have at the time to get to the data that they know is there. So, we really try to focus on making sure that everything is available to everybody, regardless of the device.

Everything that we are essentially removing is still available through navigation, it’s just that a mobile user is not going to have to download the entire longform website, which results in a much faster loading mobile experience.

Karen:

Let me do a quick follow up on that and ask how did you make decisions about what to prioritize on all these different screens. I know you mentioned having to start with a desktop site and try to squish it down, and I think we all understand that there are some problems that arise with doing that. And when you think about going mobile-first, how did you make the tough choices about what to keep and what to get rid of, and what was the most important thing on every screen?

Erik:

So, the 2011 launch was the one where we did the desktop-down. When we did the 2012 relaunch, that one was done on a very, very quick timeline because our department was moved into a different overall department and our boss really didn’t like the current website, so he essentially came to us after reading the Walter Isaacson Steve Jobs book, and he had taken some personality traits out of that unfortunately, and said that he hates our website and wants us to re-do it, and “We have two months. Go.” And so, that was from when he said go to when it needed to be launched, that we had two months to do it.

In that one, we did take a step back, and it’s not ideal these days but we did break it down into mobile, tablet, and desktop experiences because the overall design that we were doing for that—and it’s the current ND.edu website that I’m discussing here… So, if you go on your mobile phone, you’re going to get a much smaller page than you would if you’re on desktop, and the reason being is that each of those sections below the top section on ND.edu are essentially subpages. So, we made the decision early on that we didn’t want to load the entire ND.edu homepage on a mobile device because that would be very large, because that desktop site at the time clocked in at about 2.3MB. So, we made the decision early on to really slim it down for mobile and a little less so for tablets and essentially use navigation to get users to that additional content. Everything that we are essentially removing is still available through navigation, it’s just that a mobile user is not going to have to download the entire longform website, which results in a much faster loading mobile experience.

Since then, we have optimized that homepage so it’s no longer 2.3MB on a desktop for initial load. By doing some lazy loading and caching, we’ve gotten that down to a little less than 500k, which is an improved experience, and a lot of the weight is still from that top image on the top of the desktop site. Now, that large background image and the subsequent data that you can get to by clicking on the link in the top-right didn’t actually make it into mobile because that was more of an experiential piece of the website, having the large in-depth photography. We decided to forgo that for mobile just because it didn’t seem to fit into the overall design. But the user’s not really losing much there from a content standpoint.

I see the two as completely separate entities from each other with different use cases. We have our main ND.edu site, which is more geared toward external audiences, and the m-dot, which is geared towards internal.

Ethan:

Erik, my ears perked up a little bit when you mentioned that you guys began with a mobile experience and then a responsive one, and then more recently rolled out a native application. Tell me a little bit more about that decision-making process. Like, how does the responsive design sort of fit into that ecosystem of a native app as well?

Erik:

So, the native app is sort of the next iteration on our m-dot site, which is more utility items for internal users. It does have some of the externally-facing things like news and events and whatnot, but a lot of it is things like getting to your university card to see your balance or seeing the status of the washing machines or computer labs or things for our internal audiences, where the main Notre Dame website is a little more geared towards external audiences. So, the m-dot site can be used by any device; it is now, more or less, a responsive site as well versus just a mobile-specific, even though it still lives at m.ND.edu. But yeah, I see the two as completely separate entities from each other with different use cases. We have our main ND.edu site, which is more geared toward external audiences, and the m-dot, which is geared towards internal.

Back in the day, we would do a full-on Photoshop comp. We actually had some clients who would compare it pixel-by-pixel to the final website, much to my chagrin.

Karen:

Let me ask about what you’ve learned over the last few years about planning and scoping a large-scale responsive project. Do you have to budget more time or do you have different tasks that you do, different activities that people perform than from the old desktop-only days?

Erik:

The big change, like most groups that have gone responsive, is the obvious lack of the Photoshop mock-ups. Back in the day, we would do a full-on Photoshop comp of “This is exactly what your website is going to look like.” We actually had some clients who would compare it pixel-by-pixel to the final website, much to my chagrin. But these days, it is extremely rare that one of our designers will create a full-out Photoshop comp, and if they do it’s more for their own purposes rather than for the clients. But there are the occasional instances where our responsive workflow that we’ve adopted—the client has a really hard time getting it. For those users, we’ll build out more of a complete mock-up.

Our process these days usually starts around discussions around the content, and we do content priorities about what’s the most important thing on the page.

But our process these days usually starts around discussions around the content, and we do content priorities about what’s the most important thing on the page, because they really need to understand the stacking order on mobile, that it’s not going to have this above-the-fold mentality. And so, we start with the overall discussion around the goals of the website and what the content is, and our designers will take that and work with the developers on any custom functionality that they might want to see on the website. But then the designers will do either sketching and then some wireframing—I believe they use OmniGraffle for that. And then occasionally if there’s some advanced interactivity, like animations or “You click on this thing and this slides over, this does that,” they’ll use After Effects to animate it out for the developer to sort of get the vision of what they’re after.

We do a mobile and we do a desktop wireframe for each of the main content pages. We don’t do a tablet wireframe.

Once the designer gets through the wireframing process, which we work with the client on, so they’re fully involved with things like wireframes and content priorities, the designer will also do a style prototype, which is an in-browser style tile, which is more of a static one. So, our designers are very much involved in the initial coding of the website. They’ll do all of the CSS for things like the buttons and typography and all of that.

At that point, the developers get involved and start taking the wireframes, which we do a mobile and we do a desktop wireframe for each of the main content pages. The developer will take those wireframes, along with the style prototype, and build out the basics of the website and all of the templates, and then it becomes an iterative process between the designer and the developer. We don’t do a tablet wireframe, because what will happen is the designer will get back into the code and start laying out things at the different breakpoints and adding in breakpoints where they think they need to happen. So, it’s not left up to a developer to try to read a designer’s mind to do what’s between the mobile and the desktop. They can get the two basics in and then the designer can go in and complete the process and then go back and forth with the developer if there’s any more advanced JavaScript or whatever that they need involved.

We always end up with a better product if we can get that content earlier in the process versus later.

But ideally we like to hit content as early as possible, which isn’t always the case in higher ed. A lot of times, content is one of the last things being put in and can hold up a project. But even if we can get things from the client, like the expected length of a content type, so that the designer is not just working with lorem ipsum or some early content. We always end up with a better product if we can get that content earlier in the process versus later.

We can start breaking up those content types and allow us to move the design more into the template and the CSS rather than making the client try to do it through the WYSIWYG editor.

Ethan:

One thing I’d like to hear a little bit about is when you are at a position where you actually need to introduce changes to a design that you’ve shipped. Whether a content author is starting to put information into a design system and things don’t quite look as you might’ve expected, or if you launch a site and you learn some new information from your users, have you ever been in that situation where you’ve had to rethink some of your responsive design assumptions?

Erik:

No, I don’t think we’ve ever run into that. Usually those problems become evident before the site launches, especially if the content that we’re provided doesn’t match the early assumptions that we were given when we start discussing the project with the client. Now, when you start getting into specific content-type pages, like a faculty listing or a course listing or something, the designer will often need to work with whatever the content that the client has put in and will have to take a step back and maybe break out those content types a little bit.

Our CMS does allow us to create custom data types for templates. So, if it turns out that what the client is putting in seems rather difficult to style across the different breakpoints, we may take it and break it up to where a person’s title is a different field vs. their role and then the description email address. We can start breaking up those content types and allow us to move the design more into the template and the CSS rather than making the client try to do it through the WYSIWYG editor. But usually those are caught well before the site goes live, which has proven to be advantageous.

It’s had to change how we think about content structure, at least. It’s required us to do more time upfront breaking up the different content types.

Karen:

Can you say a little bit more about that? I’d be curious to hear if these responsive projects have changed the way that you gather content from your stakeholders or have changed the way that you actually think about content types and content structure in the CMS.

Erik:

Well, it’s had to change how we think about content structure, at least. Because back in the day we could put together something pretty basic and the layout is not going to change, and so the image was always going to be next to the title and the name of the person. These days if you’re working in responsive, sometimes that image needs to be above the person’s name and the title and their content. So, it’s required us to do more time upfront breaking up the different content types.

Typically we are not gathering most of the content from the users. Our CMS is built with the goal to allow our clients to do the lion’s share of the content themselves, so a lot of it is around working with them to figure out what the content types are, getting those broken up into the CMS to where they can enter all the data themselves. At that point, it’s a matter of training them on understanding how things are going to change depending on layout.

It’s our goal to be the people who educate users on best practices and things like accessibility and performance, and then let them take care of the site content themselves.

So, like a recent issue that we’ve run into is we had a user putting in some content and they were referencing in the copy, “Click on the link to the left,” and so they were referring to the navigation column on the left-hand side of the page because they were considering that when someone’s on a small screen device that that’s going to be below the content, not next to it. So, that’s just a case where you just need to go back to the user and educate them a little bit on the different layouts that they may be dealing with and give them alternatives to getting the user to the content that they need. Rather than saying, “Click on the link on the left,” put the link right there in the content where the person is actually reading instead of trying to point them somewhere else.

But our goal ultimately is to try to get users doing as much of the content entry and management as possible because, like I mentioned, our CMS has 460-some websites. We definitely could not manage the content for all of those. It’s our goal to be the people who educate users on best practices and things like accessibility and performance, and then let them take care of the site content themselves going forward and then only coming back to us if they have questions or problems that they can’t tackle through the CMS itself.

We just make sure that there’s that open line of communication between ourselves and the clients and that we’re in constant communication, and so we can be very agile and change things.

Ethan:

I loved some of the collaboration workflows you were describing earlier. One I’d like to hear a little bit more about in particular are design reviews. Now that you’ve embraced prototyping a little bit more, how does that change the way in which you get a design up in front of a group of people and talk about what’s working and what’s not?

Erik:

So, the client is involved from the very beginning, like I mentioned, the wireframes and the style prototypes. They have a good idea of how things are going to be laying out, as well as interactions, because they can open the style prototype in their browser and hover over things and click the links and what not. So, they’re fairly involved early on and as long as they can make that mental connection between the wireframes and the style prototypes, it seems to go pretty well.

Now once the templates are completely built out and the styles are applied and they’re entering content, there can be some back and forth regarding different styles and how things are laid out on the homepage and what not, because what may have been wireframed may have changed during the build, or like I mentioned before, assumptions about content may not have proven accurate when we get down closer to launch. We just make sure that there’s that open line of communication between ourselves and the clients and that we’re in constant communication, and so we can be very agile and change things, really work closely with the client on design before the site launches.

Ethan:

Let’s talk a little bit about performance.

Erik:

I would love to!

As we’re going through the concepting phases for websites, performance is always part of the discussion.

Ethan:

I know this about you, Erik. [laughs] I’d love to hear a little bit about how you make some of these design decisions and content decisions around the speed of the sites that you’re designing responsively. How do you define what’s going to be a fast-performing interface at the start of a project? Do you evaluate it throughout the design process? Just tell me a little bit more about that.

Erik:

So, those discussions happen at the very beginning of the projects. Going back to the 2012 ND.edu, that website has a very large experiential image in the background. The original concept that we were going with was, rather than a large image, we were going to do something that we hadn’t really seen much of before. We were going to do a very subtle background video, which for 2012, those weren’t around much. But after looking at it and realizing the download size that was going to incur, we decided against it. Had we gone in and done that, we would’ve been way ahead of the trend curve in higher ed, which you can see a lot of those background videos these days—which we have done on some of our subsites, but it was decided early on that that was just going to be too much of a performance hit for our main university website, so we opted not to do it even though it would’ve been cool.

As we’re going through the concepting phases for websites, performance is always part of the discussion. And we’ve actually kicked off a meeting recently with one of our larger groups on campus about a redesign, and part of that initial kickoff was we took a number of peer institutions that they would consider competitors for the same students and we actually showed them side by side filmstrips from WebPageTest’s website, where you can put in multiple websites and then see side by side the rendering of each of those websites. We were able to show them, “Look, currently your site is rendering much quicker than your competitors, and that’s something that we don’t want to lose,” and they really appreciated that information. We talked to them about download sizes and rendering sizes and the type of things that they may want to avoid in order to keep that advantage that they have—things like “Carousels can be damaging to the rendering of a website as far as speed goes.” So, performance has become part of the initial conversations with the clients. Before that, it was just internal conversations—as we’re meeting with the designers and talking about a website concept, we’d be talking about performance. But now we are actually taking that into the initial client kickoff meetings as well because it’s become that important, not just for us but for the client as well.

They’re such easy labels, it’s an easy trap to fall into, and it’s hard to break out of once it’s there, especially when the reporting tools lend themselves to that.

Karen:

Talk to me broadly about how you measure or evaluate the success of these responsive designs. Like, what kind of analytics data are you looking at? Are you still looking at your data through mobile and tablet and desktop lenses?

Erik:

Yes, we still look at the data that way, and that’s how Google breaks it out, so it’s really easy to look at it that way even though it seems to be well agreed upon in the web design community right now that maybe we shouldn’t be thinking necessarily in those buckets. But they’re such easy labels, it’s an easy trap to fall into, and it’s hard to break out of once it’s there, especially when the reporting tools lend themselves to that.

We really try to focus more on things like what are the goals of the website and what’s the conversion that they’re trying to get out of it.

We do look at the before and after, things like bounce rate and mobile traffic. But we actually have some clients who are now on their second, and some clients are on their third iteration, of a mobile-friendly website, so it’s hard to say whether or not the most recent responsive design is affecting trends as far as bounce rates and what not. We really try to focus more on things like what are the goals of the website and what’s the conversion that they’re trying to get out of it.

The goal should be something concrete that we can point to afterwards. And so, we do like to revisit those later on.

So, “successful” …we would measure that less in the type of traffic and more “Are they seeing the outcomes that they’re after? Are they seeing more conversions on their contact form?” which can be a totally different conversation than mobile support. You can talk about things like is the form too long, are you asking for too much information up front, should you trim it down and maybe get some of that later after you have their initial contact information. So, as far as success of a website, a big part of it is does the client love what we’ve produced, and then are they seeing the outcomes that they’re expecting, which we do ask about up front. Like, “What are the goals of this website?” and it’s not just “We want something pretty.” The goal should be something concrete that we can point to afterwards. And so, we do like to revisit those later on. We haven’t done the greatest job in our postmortems, that’s something we are trying to improve on; revisiting a site six months later to see what do the stats say and how do things look. But that’s an area of improvement for us, and that’s something we’re looking closely at.

Having the developers and the designers in the room to ask the questions directly from the client and having the conversations is very valuable.

Ethan:

Erik, this has been a wonderful thirty minutes. I can’t thank you enough for spending some time with us. But before we let you go, I would love to know if you have any advice for other organizations, higher ed or otherwise, in our audience who are going to be embarking on a responsive redesign. What are some things that you’ve learned about designing responsively in the last few years?

Erik:

I would say some of the most important things are involve the entire team as early as possible in the client meetings. Having developers and designers in the room with the client to hear and listen to their wants and their needs and their goals for the website can really improve the overall product, so that way it’s not just a matter of a project manager, an account manager coming back and saying, “Here’s a document with all of the information.” Having the developers and the designers in the room to ask the questions directly from the client and having the conversations is very valuable.

In a lot of cases with things like scroll jacking and what not, we’re trying to recreate the days of Flash, which is unfortunate.

Also, really focus on—and this is my personal bent—is really pay close attention to performance. It’s disheartening to me to see all of these three megabyte to five megabyte-plus websites coming out these days. It seems like in a lot of cases with things like scroll jacking and what not, we’re trying to recreate the days of Flash, which is unfortunate, and we really need to get back into the performance side of things. Which is why I love seeing the work Filament Group is doing, and Tim Kadlec and the things that he’s done with WebPageTest, adding in What Does My Site Cost? data.

So yes, get designers and developers involved as early as possible and don’t forget about performance.

Karen:

Well, I think that is a wonderful note on which to send our audience off. So Erik, I will thank you again. This has been a spectacular conversation. I really look forward to talking more with you in the future and seeing what you’re up to. Thanks so much.

Erik:

My pleasure. It was wonderful to be here.

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.