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, if Karen and I were co-located, we’d be high-fiving each other with glee because we are speaking with Dave Olsen from West Virginia University. Dave, thanks so much for joining us.

Dave:

Thank you very much for having me.

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 really 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, even, and it lets you send invoices when your time tracking is complete. If you’re a responsible business professional you should be tracking 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.

My role here is as an evangelist on the responsive design side, that this is really a good way to go. It’s a functional and sustainable way to deliver content to mobile.

Ethan:

Ethan:

So Dave, maybe you can introduce yourself for our audience and tell us a little bit about what you do at West Virginia University and how responsive design plays into it.

Dave:

Okay, well I’m sort of, in my day-to-day, very much a jack of all trades. I sort’ve do project management, back-end development, and then try to help the front-end developers with JavaScript and some of the more fun functional stuff. And then along with my day job here at WVU, I also work on open source projects like Pattern Lab. We’re trying to think about how patterns can be used to help develop brands or just websites in general.

So, my role here is as an evangelist on the responsive design side, where we’re just trying to explain not just within our own unit but within the community at large, both stakeholders and developers, that this is really a good way to go. it’s a functional and sustainable way to deliver content to mobile.

Ethan:

Well that’s great, and we’re really excited that you’re here, because as I recall, WVU.edu was one of the first big higher ed. responsive redesigns that I remember, is that correct?

Dave:

Yeah. We actually started with an m-dot and then fairly quickly went to responsive design, and then again, just trying to spread the word. It has trickled out to almost everywhere now on campus, is a responsive website. That’s a lot of websites—we’re talking like 500-600 websites.

The m-dot was okay, it worked. It was just it was a separate silo, a separate thing to have to update and manage, and this content didn’t flow well into that framework.

Ethan:

Wow. Well, that’s fantastic. Tell me a little bit more about that origin story. When you were working with stakeholders of the university, that “we should be moving away from a mobile site,” what was that transition like? What was causing that initiative? And did you hear any concerns about responsive design as a methodology back in those days?

Dave:

The thing that was sort of driving it was just this understanding that, at least at a university, most of our content is not functional, it’s very dry. Like, “Here’s financial aid and marketing,” and it couldn’t all fit within one thing, one m-dot. The m-dot was okay, it worked. It was just it was a separate silo, a separate thing to have to update and manage, and this content didn’t flow well into that framework.

When you tend to get the good feedback, the really good feedback, is when a stakeholder happens to open up an email that has a link in it.

In terms of engaging stakeholders, for the most part we sort of did it behind the scenes. I think that’s one of the really nice things about responsive is it’s on the designer and on the front-end team to implement, and so they can just kind of go ahead and do it without anyone having to be like, “Yes, this is what we will do.” There’s no check-off. We just do it and say, “Your website’s mobile-friendly,” and everyone is happy from there on out.

I think most stakeholders are obviously looking at it on the desktop for the most part, and they’re happy with the design and that’s great. When you tend to get the good feedback, the really good feedback, is when a stakeholder happens to open up an email that has a link in it, and they open up the website and they’re like, “Oh, this actually looks good and I can actually get something done as well.” So, it’s worked out well, it’s been very organic; we’ve just sort of forced it on people and everyone is happy.

We’ve just made sure that responsive is there for everything. I guess our mobile strategy is just everything is mobile-friendly on the web. It’s pretty simple.

Karen:

Dave, I remember talking to somebody from a university a while back who, when I asked them about their strategies for mobile, said, “Well, students have an app,” and there was this notion of “Well, no one is ever going to want to do their college research from a mobile device. That’s what desktop computers are for.” How does the discussion around what people need on mobile vs. desktop, and if people need different things on mobile vs. desktop—how does that play into your conversations and your strategies?

Dave:

So, we kind of break it down into two silos. The one would be, for me, academics and that really day-to-day use, and that’s really good for an app plus making sure everything is responsive regardless. But what we find is, especially at West Virginia, we have this population—their first computer is that cell phone, truly; their first high-speed internet connection is the cell phone. I know at my house, I have LTE and 700k dial-up. So for us, being able to deliver a mobile-friendly solution because we know those people are on their phones and actually using that as their fast connection to learn about the schools, to tell their parents kind of what’s going on. We’ve just made sure that responsive is there for everything. I guess our mobile strategy is just everything is mobile-friendly on the web. It’s pretty simple. [laughs]

We’ve been trying to implement a new brand at WVU and because it’s very much print-driven, we’re trying to find the edges of where the print design stuff is failing on the web.

Ethan:

That totally works for me. I’d be interested to hear, Dave, about how you scope a responsive project. Specifically, I’d be interested to know has that changed since the first big redesign that the university went through onto some of the more recent responsive redesigns you’re seeing today?

Dave:

Most of our stuff is probably relatively simple in terms of we’re dealing with two, maybe three, templates; we’ve gotten pretty good at standardizing stuff, so there hasn’t been a ton of overhead in doing a responsive project.

Once you come up with patterns, everything seems to be kind of a piece of cake, to a degree.

Where we’ve found more complications, in terms of realizing maybe we’ve been out of scope, is doing more of our recent pattern work, where what we’ve been trying to do is implement a new brand at WVU and trying to implement that in a responsive way. That’s been sort of challenging because it’s very much print-driven, and so we’re trying to find the edges of where the print design stuff is failing on the web, and that’s adding extra work and trying to figure out, in terms of size of type, in terms of columns and all sorts of things that they have in their head that works really well in print but that we’re having issues with.

So scope-wise, I think it’s been fairly straightforward for the most part. It’s been implementing a new brand that’s actually added a lot of extra work on the responsive side. But hopefully that goes away again. Once you come up with patterns, everything seems to be kind of a piece of cake, to a degree.

It’s not even thinking about responsive or content for a smaller screen, it’s more “How do we do content well?”

Karen:

Can you talk a little bit about how you make decisions or how you coach all of the different stakeholders who are involved in the redesign process on how they make new decisions about how to prioritize and structure the information on the page? Like, how do the patterns help with the prioritization decisions?

Dave:

On the prioritization decisions, the one big case that we’ve been dealing with right now is admissions, where we’re going to a whole new site, this is a whole new brand, and trying to make a really big effort in doing content and doing it in a smart way. To be honest, it’s been a struggle. They sort of had their way for a decade or more in doing content, so trying to bring them back into the fold and to explain not just “Hey, here’s a different viewport” or whatever, but just the fact that “you guys are missing opportunities in terms of how we organize content for how it looks on Google,” even that’s been a challenge—when you’re trying to do navigation in a smart way.

It’s not an easy conversation because there are these core fundamental issues that are busted regardless of content on the web.

I think we have these deeper structural issues—it’s not even thinking about responsive or content for a smaller screen, it’s more “How do we do content well?” and I think that may just be a higher ed. problem regardless, it’s not just necessarily us. What I think higher education has done over the last ten years is sort of divvied up and said, “Hey, you guys your content the best, go ahead and do it,” and we’ve had—not spectacular failures—but, to a degree, failures. Now we’re kind of coming back and saying we’re going to take the power away from individual stakeholders and tell them what to do and sort of do it for them; I think that’s what we’re going to end up doing here with admissions. So, it’s a struggle. It’s not an easy conversation because there are these core fundamental issues that are busted regardless of content on the web. So, it’s not great.

It just comes down to what artifacts can get sign-offs and get sign-offs fairly easily from fifteen people.

Ethan:

Dave, in the conversations that you have at the university either with front-end developers or other site owners, I’d be curious to hear how they think about the design process. Has that been changing as they’ve been doing more multi-device work?

Dave:

I think we’re still a little bit stuck in the past, in terms of Photoshop comps, more than I would personally like. I’ve definitely been pushing for more in-the-browser, faster iterative approach. It just comes down to what artifacts can get sign-offs and get sign-offs fairly easily from fifteen people.

You end up learning that you can do things faster in Chrome than you can in Photoshop to a degree, because you get that real thing, you’re not debugging on the fly.

So, the process currently is we use a product called Conceptboard, they post something there, they get feedback, then we kind of go into Markup and then move from there. To me, it’s really slow and cumbersome because nothing is true—very much not true. I was just reviewing a concept and the person came back with “Well, I’ll change that when I go to markup.” It’s like, “Well, yeah, why don’t we just go to markup in the first place and we could’ve all been on the same page instead of wasting a week.” So, we’re still in this mode of trying to get people to do more in markup right away. It’s still a bit of a bear. It doesn’t seem like a new concept, but it really is a new concept to kind of come out of Photoshop and take some time, and you end up learning that you can do things faster in Chrome than you can in Photoshop to a degree, because you get that real thing, you’re not debugging on the fly, essentially.

It’s the approval process that’s very linear, it’s not necessarily the development that’s linear. So, it’s a little cumbersome.

Ethan:

Oh, so that’s interesting. So maybe tell me a little bit more about how teams collaborate currently. Is it a little bit more waterfall-driven, a little bit more linear?

Dave:

I think it’s a little bit more linear just because… So at WVU, we have kind of a core team in marketing who does a lot of the bigger projects, like the homepage or admissions, for example; kind of the big outward-facing things. Then we have individual colleges. We have fifteen colleges here at the university, and so each college has their own designer and they’re doing their own thing helping individual departments because there’s so much work. Especially now with the new brand and trying to have everything on brand, these individual designers out in the colleges do mock-ups, they get approvals from a department or their dean or whoever. They come back to us, we sort of collaborate a little bit on design, and they go back and do their own thing, and we help a little bit further technically. But it’s the approval process that’s very linear, it’s not necessarily the development that’s linear. So, it’s a little cumbersome. To me, it’s challenging. But it’s the way all the print people seem to know, so that’s the way it’s being done now.

We’ve definitely tried to put much, much more emphasis on getting individual stakeholders for content to be thinking about “Let’s go do a content audit, let’s go look at your analytics.”

Karen:

Let me follow up on that and ask about how the process that you use to wrangle all the content contributors and all the content stakeholders—has that changed as part of this process? Do you do that earlier or differently?

Dave:

So yeah, we’ve definitely, in the last probably four or five months, tried to put much, much more emphasis on getting individual stakeholders for content to be thinking about “Let’s go do a content audit, let’s go look at your analytics,” and we’ve taken a much stronger position from a central standpoint of going “Here are the tools. We’re going to sit down with you and look at stuff.” That came primarily out of our own experience with, again, this big admissions project, where obviously I wanted all the data to back up all of our future decisions, what we were going to do, and try to understand where we were at, where we were going to go. So, we did a content audit.

We’re a party school, I can’t really say we’re not; we’ve been in Playboy’s Top Ten for a long, long time.

Then luckily for admissions, they have a ton of data in terms of surveys where students said, “Hey, I didn’t attend because of X” or “I did attend because of X.” So we can take that data and we can kind of turn it around to say, “How does that reflect on the content?” So, we’re a party school, I can’t really say we’re not; we’ve been in Playboy’s Top Ten for a long, long time. [laughs] So, it was kind of clear from that data that we didn’t need to hit on campus life anymore. Everyone in the world knows what campus life at WVU means. It means you’re going to go and probably party. If you’re a higher ability kid, you’re not going to come, or you’re less likely to come.

So what we needed to do rather than focus on campus life, which is what we had done for the last decade—and you can see it through all of the content pieces that we have done, it’s all very much “You come to WVU for an experience” … We had to kind of turn it on its head, and it seems a little odd but we did have to do it here, where we had to focus more on academics. So doing a content audit and talking to departments and going, “Look, what kind of content do you have? Does it fit into this mold?” has been really really beneficial because we’ve sort’ve all been missing a core component. Now that we can address that earlier on in the process, that influences design, which influences hopefully our final messaging, which is you get good academics at a good cost coming to WVU.

The content management system itself doesn’t really know about patterns, it’s the theme that knows about the patterns.

Karen:

What is your publishing system? What content management system do you use and how does that hook up with the pattern library, if it does at all?

Dave:

The primary content management system we have is called CleanSlate and it’s an in-house Ruby on Rails-based application. Currently, it doesn’t quite fit into the patterns. Basically each site has a theme, and the theme can snarf in patterns. So the content management system itself doesn’t really know about patterns, it’s the theme that knows about the patterns, the designer who knows about the patterns. So from that standpoint, we don’t have anything great going on.

We’re trying to do a much better job of having content patterns; they’re not necessarily design patterns, but they’re content patterns to say, “This is what a major is, this is the bits it has.”

What I’m hopeful that we can get going moving forward is this idea of content buckets, where we can have content stored within the system and reshare it sort of easily. We’ve been using a product called Gather Content for this admissions project, and one of the key components is majors. We’ve had majors in its own silo but the data has never been accessible, there’s never been an API or anything along those lines. So, we’re trying to do a much better job of having content patterns; they’re not necessarily design patterns, but they’re content patterns to say, “This is what a major is, this is the bits it has, and by the way if you want to use it in your other website, you make this sort of call.” We’re not right there yet, but I’m hopeful here in the next less than six months we’ll be in a position where a designer can implement a content pattern within their website—so, not just majors but directory information—and get good, useful, tested quality content that’s going to work everywhere.

As long as the breakpoints are based on the content, we feel really comfortable that, moving forward, regardless of device, the responsive design is going to hold up really, really well.

Ethan:

Dave, talk to me a little bit about how teams at WVU define support in a responsive design. We talk to a lot of organizations—publishers, educational organizations—they really struggle with these old models of browser support basically, trying to update them for the QA process as we’re moving further and further beyond the desktop. How do you see teams dealing with that at WVU?

Dave:

The thing that we’ve pushed while we do a certain level of testing is kind of let the content be the guide on breakpoints and how look is going to function. So, you know, Stephen Hay: “Start small, go big,” and let the content sort of let everything fall out in how it’s going to look. We found that we don’t have to do a ton of testing beyond that.

We’re not doing anything really crazy functionally, where we have to worry about a lot of incompatibilities. Again, this is—I hate to call it brochure-ware, but it sort of is. We’re just dealing primarily with strictly flat content. So as long as the breakpoints are based on the content, we feel really comfortable that, moving forward, regardless of device, anything can go in the future, that the responsive design is going to hold up really, really well.

It’s a tough sell. As a guy who wrote a chapter on web performance, it is an amazingly tough sell.

Ethan:

That makes sense. I guess the other side of that would be performance. Is that something that you see entering into the conversation around responsive designs over the last couple of years?

Dave:

Yeah, we definitely push for that notion of responsible web design as much as responsive web design. It’s a tough sell. As a guy who wrote a chapter on web performance, it is an amazingly tough sell. But we’re striving to be better in that area and kind of get the word out that web performance can make a difference.

The better customer service we give, the more likely those kids who are on the fence would be likely to come here and give us money and have the best four years of their life.

Really what I think it’s going to come down to is us coming up with some metrics and letting people know how their metrics compare to competitors. So it’s one thing we’re going to try to do with admissions, is to kind of say, “If we can have a faster website…” I’ll just pull somebody out of the hat, University of Pittsburgh—not that we’re a competitor with them, but somebody like that—and say, “Hey, if our website is faster than them, we’re going to have a better experience and people are more likely to have a good view of us.” The more we can kind of look into this notion of the “halo effect,” the better.

So, that’s kind of the way I’ve been trying to pitch performance, and just in general responsible design—the better customer service we give, the more likely those kids who are on the fence would be likely to come here and give us money and have the best four years of their life. So I guess that’s the way we’re trying to push it, is as a customer service angle and “How can we make them compete against other people? How can we compete against other schools?”

Once we went responsive, we went from seven percent traffic to the main homepage to something like over twenty percent mobile traffic on the homepage.

Karen:

Let me broaden that question a little bit and ask about how you measure the success of your website or of a responsively-designed website. Like, if you’re looking at your analytics data or trying to evaluate the broadly conceived performance of the website, how do you know if this is working?

Dave:

To a degree, we don’t. I know in admissions we have really clear goals. What we’re working more towards is trying to track an entire path for a user. So, somebody can jump from the homepage to admissions, to financial aid, back to admissions and can we see how, through all of that, somebody’s gotten to a goal. Can we look and see have we had an uptick in mobile, that the person was actually able to go on particular devices and be successful. In general, we’ve always had pretty good numbers. Once we went responsive, we went from seven percent traffic to the main homepage to something like over twenty percent mobile traffic on the homepage. That didn’t include tablets; I think tablets would push us over thirty percent.

We’ve always had good numbers. It’s more a matter of trying to find good goals.

So, we’ve always had good numbers. It’s more a matter of trying to find good goals, and that’s been sort of difficult from our perspective because you can’t just be like, “On this website, there’s just a generic goal.” You want to say, “Hey, for this communication going out, we wanted them to be able to do X, Y, and Z, therefore they accomplished it,” and we’re not in that pipeline to be able to look into the communication, the original email, to get the analytics to say, “Goals were achieved.” So there’s nothing really good; I haven’t found anything amazingly good. I was hoping with this admissions project we would actually end up getting some better numbers, but we’re about to to the common app and that messes up your entire yield, so I won’t know how well we did with that. But I guess we just sort of crossed our fingers and saw that there was a general uptick in stats, so that’s good. I have no idea. [laughs] You can edit that out. There’s nothing good.

Get that baseline in terms of just doing a content audit and doing your analytics, and that will give you an amazing insight into where you actually need to focus your efforts.

Ethan:

“There’s nothing good,” that’s the tagline, I think, for today. [laughs] No, that’s great. But while we’re talking about learning, we’re reaching the end of our time and I’d love to hear if you have any advice for any other organizations who are listening today who are embarking on a responsive redesign. Of all the projects that you’ve been involved with and everything that you’ve learned over the last few years, what would you say that they start thinking about now?

Dave:

Content. I mean, content is by far… Get that baseline in terms of just doing a content audit and doing your analytics, and that will give you an amazing insight into where you actually need to focus your efforts.

The second thing I would say is, especially for higher education, is to kind of lift your head up and not be in this industry silo, and go to an An Event Apart or go to even a local meetup, like a Refresh Pittsburgh or something along those lines, and realize that you’re part of this larger industry with very, very similar problems to what you have. There’s nothing incredibly unique about what we have. Bureaucracy is bureaucracy. You can learn a lot from talking to a lot of different people and commiserating and realizing, again, we’re not really behind the times, we just have to kind of embrace all the things that cool people like you and Karen are doing and not just try to do it all on our own. That’d be my advice.

Karen:

Well, I think that’s fantastic advice and I really appreciate your taking the time to talk with us today. I’ve always been super interested with what you’ve been up to and I will look forward to hearing more about what you do in the future. Thanks, Dave.

Dave:

Thank you.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast. Thanks also to our sponsor, Harvest. Go to getharvest.com and start tracking your time painlessly.

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.