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:

I’m your other host, Karen McGrane.

Ethan:

And this week, we are beside ourselves with joy to be speaking with Paul Strandlund and Dylan Rogowsky, who are here to tell us a little bit about the responsive redesign of the City of Edmonton website. Paul, Dylan, thank you so much for joining us.

Paul:

No, really, my pleasure. Thank you for having me on the show.

Dylan:

Yep, great to be here.

Karen:

But first, a word from our sponsor, Gather Content. Wouldn’t it be great if you could snag a REAL bargain for your holiday shopping? This year, you can! On December 8, Gather Content is offering a free masterclass — that’s right, absolutely free! Their online session on content strategy and delivery for website projects will help both agency and in-house teams create and deliver web content. This course is a $700 value and it’s yours absolutely free.

So go to gathercontent.com/masterclass and sign up. Then show up on December 8 at 4pm UK time, 11am Eastern time for a two hour session where you’ll learn practical, tried and tested techniques to help deliver content during website projects.

Ethan:

So before we dive into the interview, maybe you could both introduce yourselves to our listeners and tell us a little bit about what you do, and maybe tell us a little bit about the City of Edmonton’s website. Paul, do you want to go first?

Paul:

Sure. So, as you said, my name’s Paul Strandlund. I’m the web operations manager for the City of Edmonton, so it’s really my job to lead the team that operates all of the city’s different websites. I’ve been either fortunate or unfortunate enough to be in this business for quite some time, working on the internet since ‘87 and the web since ‘92—and yes, I do know the difference between those two. And really, I’ve never really worked for a design shop or anything, I’ve always worked on the client-side of things, and this is now my fourth major redesign, so kind of exciting to continually see how the web’s expanded since the early ‘90s, when it was nothing more than white pages with black text.

Dylan:

And I’m Dylan Rogowsky, I’m a developer with Yellow Pencil. We worked closely with the City of Edmonton over the past couple months on the responsive redesign project. I’m primarily a back-end developer working with the Enterprise content management system that the city has, but I’ve always dabbled a little bit with front-end side and the user experience side of things on this project.

Ethan:

Well, once again, welcome to both of you. I’d love to talk a little bit about how the design process for Edmonton.ca came about, because it is a really beautiful piece of responsive design work. I’d love to hear, once you were kicking off this redesign or the initial stages of planning it, were there any concerns that came up from stakeholders or any questions that came up around responsive design specifically?

Paul:

So, the process started I guess just over a year ago, it was in last July. We determined that we had enough mobile traffic to really put us onto that tipping point to move from a site that was focused on desktop to one that would be much more responsive. And we knew that we did not want a separate mobile instance, we didn’t want it to be adaptive. We really were looking for a responsive site—as we were saying: all screens, all the time.

So we had had a long-lasting relationship with Yellow Pencil and we went to them to really help us with the design. We did do stakeholder workshops off the front, we set out some principles quite quickly, and along with that we wanted to validate—so we actually did some external validation with both City of Edmonton employees and citizens of the city itself; we did a couple of online surveys to make sure our assumptions were valid. So we really did build it in a very collaborative way. It wasn’t a dictatorial, “Do it this way or else,” it was much more we wanted to look to see what citizens were asking for, as that is our biggest philosophy when it comes to our website, is that if the citizens don’t want us to have a website, we wouldn’t waste taxpayer money having one. So really, everything we do is for that end user. For the rest of it, it really doesn’t matter. If it’s not going to add value at the end of the chain, we’re not going to waste our time on it.

So to do that, we not only looked to our citizens and what they wanted, we also looked out to see who was doing it well in the real world, so we looked at other municipal sites, other government sites, we looked at some private corporations, and we kind of cherry-picked the best of the best and really said to Yellow Pencil, “Is there a way you can get all of this together?” And thankfully Dylan is the best programmer I’ve ever experienced and was able to cobble a lot of it together for us. So at early stages, stakeholders were informed and helped us shape the site, and really, they didn’t identify any massive problems for us.

Dylan:

We were also very fortunate that we had several analytics tools that would allow us to see how citizens interacted with the site, and better inform and confirm our design choices.

Karen:

I’d like to ask a little bit about your commitment to delivering the same information across all screens and not doing a separate mobile instance. So, Ethan and I have talked to other organizations, other civic organizations, and the team from Code For America really emphasized the idea that as more people, perhaps low-income people or people without access to the internet through other means are reliant on their smartphones, they really wanted to make sure that everything was available to everyone. We also talked to the team from Boston.gov, where they talked about having certain mobile scenarios that they were focused on—things like what happens if you get a parking ticket on your car. Can you talk about how different mobile scenarios, or maybe the difference between a mobile user and a desktop user, might have played into your decisions?

Paul:

Really good question. When we did this design as well, and as we continue to look at traffic numbers, and mobile traffic continued to increase, we actually shifted the design focus to be mobile first, so the desktop designs all came second. We said if the majority of our users are from a mobile device, then really that’s the audience we should be spending more of our time to ensure that it works for them. So, it really did flip everything on its head in that the desktop experience isn’t the important part for us anymore.

But part of that as well, as we said, as a government agency, we knew that we had to make some subtle changes. So one of the big ones that we did is when you do get it right down to the phone size and people are viewing the website, we do strip a lot of imagery and other pieces to ensure that we’re not impacting people’s data plans as much. We wanted to make sure that we didn’t cost them money by using the site on a mobile device, as much as we could have. So we stripped things down to the point where it was much more bare bones but the information is still all there.

Dylan:

And one of the interesting observations that we had while looking through the analytics was how people actually got to the city’s site. They didn’t actually start from the home page and navigate through the site, they came to the site from Google or another search engine. So we had to give some strong indication, to people just being plopped into the middle of the site, where they were within the existing site structure.

Ethan:

Dylan, I’d love to hear a little bit more about how Yellow Pencil approached scoping this responsive redesign. When you were sitting down to first plan this, did you approach it differently because it was responsive? Do you have to write your contracts differently with responsive design as a perspective to keep in mind?

Dylan:

In terms of the contracts and that side of things, it’s no different than any other project that we’ve done in the past. In terms of scoping, this one was more of a challenge where we were basically taking an existing site and making it completely responsive. So in terms of scope, we basically had to account for everything that is currently in the site, clean up the content models a little bit, simplify the number of modules and whatnot that we have within the site, standardize things, and make sure that what was there before is there after the redesign and still functional.

Ethan:

Nice. And how did that carry over into the beginning of the design process? Specifically when you’re looking at an existing site and trying to walk through how it’s going to be turned into a device agnostic responsive design, how do you start showing that layout to clients? How do you start introducing that idea of a more flexible layout?

Dylan:

I think we started with identifying the content models for the different components within the content management system used on the site, and from there we basically stripped back the unique aspects to it, and came up with a basic content model and then wrapped it with a wireframe and then presented that to the client.

Ethan:

That’s very cool. And would you say that this is a fairly prototype-driven approach to circulating the design with the client, or was this a little bit more comp-driven? What were you actually showing to talk about aesthetics?

Dylan:

It was definitely prototype-driven and iterative. We had prototypes that existed outside of the existing site with sample content obtained from the site; designed that. We had basically a static version of these things that we would throw up on the web and let the City of Edmonton take a look at it, provide feedback, play around with it in their browser and on their smartphone devices and iterate through any challenges that we had.

Karen:

I’d love to ask about the content modeling process that you just referenced. If I know anything about these sorts of civic projects, you undoubtedly have lots of people across the city that are responsible for contributing to the site. How did the content creation process work, and do they have a new way of publishing to the website now?

Paul:

So, we do have a decentralized authorship model. We have approximately 250 to 350 trained content authors who interact with the system on a sometimes regular, sometimes infrequent basis. My office then, we do all the quality assurance checks on that. So we actually do train all of those authors on how to write for the web and how to best write for the different devices. In the past, we were more focusing, again, on writing for desktop, and now we’re starting to teach them more on writing for mobile devices as, again, that is our focus going forward. So, we didn’t really change the content, though, when we did this migration. We did a quick check, we learned approximately ninety percent of our content was still good, ten percent would not work in responsive design; some of it was tabular, some of it just didn’t quite play well. So my office really went through that, we fixed those pieces where we could. Otherwise we looked to Yellow Pencil and ourselves to find alternatives, maybe we could fix some stuff, and we really will be fixing content on a go-forward basis to make it much more mobile-friendly.

The one thing that we didn’t do is we didn’t change the navigation when we did this redesign. As anyone knows when you do a massive change like this, you usually invite a lot of complaints just because people can’t find what they’re looking for anymore. So we wanted to give our regular users a touchstone. We wanted to make sure that everything was still where they left it the week before when they left the site, and when they came on that Monday when we launched the new one, it was exactly where they expected it to be, none of their bookmarks or favorites changed, the Google links and everything still worked. So now we’ll change some of the navigation and we’ll continue to work with the writing. Yes, as a civic agency, sometimes we do get into the wall of text idea, and now it’s getting people to write much more succinctly.

Ethan:

Given that this is a civic website, I’m guessing you have a fairly tight feedback loop with your audience, which I think is wonderful. I’d love to hear a little bit more about, now that the website is out there and live and you’re actively publishing content on it, have been any parts of the design that you’ve had to rework since the site’s launch? And if so, why?

Paul:

So since we’ve launched, we have received exactly zero complaints about the site itself. We have received a couple of comments about some of our applications that hang off the site, and we’re working with our IT group to get those fixed. But again, it’s a website, it is a living, breathing entity, and my team started looking for changes approximately five minutes after we launched it. So the changes that we have made so far have been quite small, we are making a couple more little tweaks here and there as we look at our analytics to see what people are saying. But in terms of the feedback that we did receive with the launch, it was all extremely positive, and we are actually adding in more feedback loops over the coming weeks here that will give people much more opportunity more to tell us specifically if the content is working for them, not so much the design itself. So we will be adding a feedback loop, much like we have on our intranet, that does say, “Was this information helpful? And if it wasn’t, what can we do to improve that content?”

Karen:

As you’re thinking about improving the content in the future, can you talk a little bit about how you got feedback either from people within the city or maybe constituents, on the site redesign? How did you review this with everybody who had a stake in it?

Paul:

Well the one thing we definitely did not want to do is we did not want to do design by committee. So we started out with really working with Yellow Pencil, and as I said, we did some stakeholder work at the start—Photoshop comps, the vaporware side of things—and really helped design the principles which would then help influence the design. Once that was done, we did do some focus groups with a working demo site. We picked four key groups: a group of seniors, a group of millennials; a group of newcomers, so people who have spent no more than one year living in the country, because we really wanted to get their input on that; and then the other group that we looked at and we brought in was a group of influential new media stars, so bloggers, vloggers, that type of group, to find out what their input was as they really have much more of a good pulse on what the citizens are asking for, sometimes people are much more comfortable speaking to people that aren’t in government. We really got some good feedback from all of those groups. Not that we had to change the design—the design, everyone said, was really solid right from the start. Every single group said they were really happy with it. It was much more a couple of little tweaks on some of the services we deliver and some of the ways that we deliver our content. So, it was really good validation.

Ethan:

That’s great. Dylan, tell me a little bit more about how you talked about browser support in the context of this responsive redesign. This is something that a lot of organizations struggle with when they’ve moved beyond the desktop and then they have all these hundreds and hundreds of mobile devices to support as well. How did you actually structure the QA process for this? How did you do device testing?

Dylan:

Well, we first started by looking in Google Analytics for what devices people were using to access the site, and from there we narrowed it down to a core set of mobile devices on the main platform, the screen sizes of those devices. Then on the desktop side, looking at what browsers people are using. So we actually have a bit of a test suite full of physical devices that capture the most popular ones out there, and we also did a bunch of simulating testing for the browsers and devices that we didn’t have readily available. In terms of the QA testing, because there were thousands of pages to check, we actually implemented an automated testing program. So every time that a designer or developer made a change to the site, it would get deployed and the test suite would begin to run through all of the different browsers that we were concerned about, and it would flag if there were any substantial differences that were unexpected, and from there we would actually investigate it further manually with the device to make sure that it was an intended change, or if it wasn’t, we would correct the issue.

Ethan:

That sounds great. I want to circle back to something Paul mentioned very early on in the cat, which was talking about being mindful of the size of the web pages they were designing and making sure that constituents weren’t paying for more features or data than they actually needed. How did you actually talk about performance and page weight in the context of this redesign?

Paul:

I’m not entirely sure we did. We’ve always been fairly aware that we needed to run a relatively lean site as it was. Performance is always one of those items that we really do look for, and because our whole model is managed hosting with Yellow Pencil, that we’ve got incredible service in that we never really run into issues in terms of speeds or anything like that, that we really do want to make it as easy as possible for our users to get the information they want as quickly as possible.

Dylan:

And from the technical side, we made sure that all of our JavaScript and CSS were compressed and minified; made sure that the imagery coming out of the content management system wasn’t at the native size that content authors put in, because we’ve experienced in the past where some authors put in huge images. So, the CMS will resize images down to the appropriate size for the content area.

Karen:

How do you look at analytics, data, or other research to know if the site’s working for you, or what might need to change in the future?

Paul:

That’s actually one thing that we’re always checking. So, we do use Google Analytics to do the basic stuff for us. Now that we have our search information in there as well, we can see specifically what people are using in terms of terminology and what pages they’re getting to, and even what they’re searching for within pages if they do go to the search engine. So that allows my content strategists to constantly be tweaking the taxonomy of the site to ensure that we’re using the terminology that our users expect. One of our best ones here that we tell people is that even though the group is called waste management, on the site it’s all called garbage, because that’s what people are looking for—they want to know when their garbage is being picked up, not when their waste is being managed. So we tend to really use the language that people expect.

We also have a number of other tools that we use. We do have some that gives us exact click tracking so we can see what people are clicking on and where they’re going. It really gives us that hotspot type of information that we’re looking for. It allows us to see when they’re breaking down in the process, or giving up. We have a number of tracking pieces on our various application pieces, so we can see, if it’s a transactional piece, are they making it to the end, are they giving up ahead of time? We even put that on our Youtube videos, to see are people watching to the end of them or only watching a portion of it and then giving up. So really, the analytics side, I wish I had more people that could manage that and really do a lot more data mining, but it is something we’re always aware of. I have dashboards up on my screen 24/7.

Ethan:

Well Paul, Dylan, it has been a real joy speaking to both of you today. Before we let you go though, I’d love to hear, have you learned one or two things, in the course of redesign Edmonton.ca, that you’d like to share with our listeners? If someone out there is starting their own responsive redesign today, what’s one thing they should keep in mind?

Dylan:

I think the thing that surprised me the most was how incredibly important it is to have concise and detailed content models, making sure that you account for the content that content authors are going to be putting in, and making sure that all of that is set up from the start of the project.

Paul:

Yeah, and I think from the client side, what we learned from this one is, as with any project, there was scope creep, but as with that we also ensured that we gave the extra time. So, Yellow Pencil delivered us a working UAT site months in advance of when we would have ever expected it on prior redesign projects, and that extra time really did allow us to do extra QA to ensure that we delivered a site that was as close to 100% complete as we possibly could. So it really was an issue here for us where, as with most government organizations, we do set artificial deadlines, and on this one we didn’t. We said, “We are not going to launch this until we are happy with the state that it’s in and we think it’s ready for prime time.” So we didn’t do a big announcement, we didn’t set council up saying, “This is the date we’re going.” In fact, we didn’t even tell council we were launching until two weeks before we were launching, which was one of our go/no-go decisions. So really, we took that extra time to do extra QA and it really paid off in the long run.

Karen:

I love hearing all of this. I think this is a great case study and it really shows in the quality of the eventual site you got. So Dylan, Paul, thank you so much for coming to talk to us today. We really appreciate it.

Dylan:

Thanks for having us.

Paul:

Thank you very much. This was great.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, GatherContent. Go to gathercontent.com and take control of your content production process today.

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

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

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