Subscribe Now

This Week’s Guests

Ben de Jesus

Senior Website Programmer

Ben de Jesus is a full stack web developer living in Lexington, KY. Over the last six years he’s overseen online education projects, social media and email marketing campaigns, ecommerce, and a responsive website redesign. When he’s not coding, Ben enjoys travelling and reading graphic novels.

Chad Compton

Database Programmer and Independent Consultant Design Language System

Over the past 17 years, Chad has served as an independent consultant for the United States Dressage Federation (USDF), a national non-profit organization. In his work with USDF, Chad designed an intricate custom database system, as well as all internal programs used by staff to capture, process, and track information needed to update data, essential to the fundamental operations of the organization. This also includes designing and implementing needed data extractions and reports. Additionally, he is instrumental in creating the back end of the USDF interactive website, along with its interconnectivity to the database system, for populating dynamic and customized pages. In addition to his work with USDF, Chad provides programming and consulting services, as well as the creation and maintenance of websites, for a number of other clients, both local and beyond, such as Southwoods & Summer Trails Daycamps, Advanced Regional Surgery Center, and Creative Coffees, just to name a few.

Episode Transcript

Karen:

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

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week, well, I might as well confess that Ethan and I have been trading horse puns pretty much all morning in our excitement to talk to Ben de Jesus and Chad Compton, who are here from the United States Dressage Federation. Welcome!

Ben:

Hi, everybody.

Chad:

Thank you.

Ethan:

As many of you might know, it’s hard work to get good, quality content for a website. Content needs to be planned, produced, and published, often coordinated across multiple teams, and

To overcome these challenges, you need a content delivery plan. This helps you to establish a solid workflow, and anticipate some of the challenges that often crop up on every website project.

Thankfully, you’re in luck: the good people at GatherContent have released a free book called Content Delivery. That’s right—free! It’ll help your teams put content first, and give them the techniques and know-how they need, to deliver content on time. From upfront planning, to getting a team and process in place, to implementing your content delivery plan, this book shares practical advice for every step of the way. Regardless of whether you’re part of an in-house team, or an agency working with clients, this book is for you.

Thanks for tuning in, and thanks again to Gather Content for sponsoring our little podcast. Karen and I are thrilled to have them involved.

Karen:

I’m going to try to not work too many horse puns into our conversation here, mostly because I want to keep the attention on your fantastic redesign. So, maybe we could start this off with both of you introducing yourselves. Tell us a little bit about your role with the USDF and maybe just give a little bit of background on the project itself.

And my name is Chad Compton. I’ve been here since seventeen years, and I kind of do all the back-end fun things that started the company out, from database building to all their programs, and I started the website and then tagged it off with Ben.

Karen:

So, tell us a little bit more about the decision to go with a responsive web design. Did you have to convince any of your stakeholders, or have any conversations with people about what it meant to be responsive?

Ben:

Yeah, there was definitely a learning curve. We just recognized that a lot of our users were getting to smartphones and tablets, and our older website wasn’t responding, it wasn’t fitting to their devices, and some of our menus weren’t working like they should have. So, it wasn’t difficult to convince our stakeholders that we needed to go responsive, and once we showed them some demos, they really appreciated the advantages and new features that it allowed.

Ethan:

As you started thinking about the needs of mobile users vs. desktop users, did you decide that, depending on the class of device they were using, that a user might want different kinds of information, or did you decide that mobile users and desktop users are basically just users and they all kind of need access to the same content and information on the website?

Ben:

Yeah, so we did find that the mobile user and the desktop user needed different things. One of the features of our website is that people can apply for membership, register a horse, participate in membership activities through our website. And we usually require a lot of information along with those applications—biographies; a lot of data-heavy information—for that experience, having a desktop website, for the most part, is what we’ve stuck with for all of these years. But as smartphones and tablets are becoming more prevalent, we’re seeing almost half of our web traffic coming from mobile devices now, and we wanted to make sure that we were servicing that demographic as well. So, those were some of the considerations going into whether to go responsive or not.

Karen:

One of the subjects that I’m always interested in is how organizations think about whether to be responsive or adaptive. So, I might say that a site where you maintain an existing desktop experience and then had the site drop down to a separate mobile experience might be considered adaptive. Could you talk a little bit about what you might have done in the past and how you might have made the decision to go responsive, and what the trade-off benefits were?

Ben:

So, we were using an adaptive approach for the website before, and the mobile-only website was, again, very pared down, but it was also managed separately from the desktop version. So, if we had some sort of change that needed to be made to the desktop site and that needed to be made to the mobile site, some of the information didn’t display as well on a mobile. We have a lot of tables and graphs that might not appear appropriately on a mobile device, so that just became a tedious process.

Chad:

And also during our paring down process, we did check the most frequented pages and sections of our site that were being used by mobile devices and tried to actually focus on those instead of actually going through the many thousands of pages that we do have on our site, to help pare down the process.

Ethan:

That’s really interesting, Chad. Maybe that’s a nice segue into talking a little bit about the design process. So, as you’re kind of reviewing the entire site that needs to be responsively redesigned, looking at difficult graphs or tables or different page types, how did you actually start coming up with the new design for those pages? What kind of tools did you use? How did you actually start managing that process?

Ben:

Luckily we have a lot of helpful volunteers and members of our organization, and so when we decided the design process, we were getting a lot of feedback from a web advisory working group that we had established. It started off with just paper and pencil, sketching, moving over to Photoshop and getting some mock-ups done, sending that to our web group, and getting feedback on what a design might look like. We set up a test environment where we had a beta website where people could go and visit, and that was another way to get feedback from those volunteers. Staff also had access to the website here locally before we deployed it for everyone to see.

Karen:

Talk to me a little bit about how you get the content on the website. Who’s responsible for creating it, and did anything have to change for either the people who are writing the content or for your in managing the content, in this new redesign?

Ben:

So, we get content from our different departments. We have, education, competition membership, and those individual staff in those departments are sending that content to us. We didn’t really see any major change in how that content got to us, but how it was displayed in the end became a little bit different. Maybe somebody had a mock-up that they wanted to include that now their images or their text would flow in a different way. But basically that process didn’t change.

Ethan:

I think you mentioned that there was a beta website where folks could opt into the new responsive experience. I’m always curious, from a design standpoint, if, while you were working on the redesign, there was any feedback that you might have heard from your users that caused you to rethink parts of the design, or anything you might have changed as part of that beta experience.

Ben:

Yeah, so that was definitely a helpful experience that I had seen on other websites, and something that we wanted to use here when we were rolling this out, because it was going to be such a drastic change in look and feel. So, for the first few months before everything went responsive, we let users know that a new website was going to be coming. They got an email that said to look for our new website soon, and then once they visited our website, they were greeted with a little footer popup that let them know that this was the new website, and if they wanted to still visit our old website, they could still do so. And so we had both sites up, available for people to go back and forth to. We got email responses and feedback on people liking the new look, the way images were presented, and how it was fitting onto their devices. Some changes for how things were sized and laid out—we were able to incorporate those changes during that AB testing, before moving completely over to the responsive design.

Ethan:

That’s really great. Maybe, as part of that process, I’d be curious to know if performance or different devices might have been things you were focused on. Specifically, not just figuring out how to make a responsive website that’s as flexible as possible, but also that’s loading as quickly as possible. How did you actually plan and test for that?

Ben:

So, it was kind of a trial by fire, really. A lot of our pages were either not used to having image sizes that were a hero image that might not load as quickly for some of our users… We’re kind of unique in that we have a vast variety of users. We have dressage enthusiasts who are working in areas where they might not have WiFi or high-speed internet connectivity, and then we also want to serve the customers with the newest devices. So, making sure that our pages load quickly for everyone was definitely a priority and a concern. So, any way that we could improve that we tried our best to do.

Karen:

Given that you’ve launched this beta site, how are you looking at metrics or data to see how the site’s working for you, and maybe identify things that need to change for the future?

Ben:

So, we do use a couple of analytics programs to track our web traffic. We review that on a monthly basis to see who’s using our website and on what devices. Most of our feedback isn’t necessarily on the design or the website redesign. It comes from maybe a navigation issue, or users who aren’t comfortable with a specific way to reach our website. One of the big things was that we moved some of our sites to be behind a secure connection, and they were using an old URL to get to our website. That’s not really design or responsive related, but just addressing those one-off cases. So, using that information, we try and service those in the best way possible.

Ethan:

Now that you’ve actually launched this responsive redesign, I would love to hear if you have any advice for our listeners. If there’s someone out there in the audience who’s listening to this podcast or reading this transcript and they’re about to start in on their own responsive redesign, do you have maybe one or two things that you learned over the course of working on USDF that you’d like to share with them?

Chad:

I would actually say question your actual users, or people besides anyone working in the office with you. I think they gave us our best feedback, because we know a certain way we want to do it while we’re coding it, or what we think it should look like. But for the everyday user, when they actually were surveyed and when we questioned them about certain things, they gave us some enlightenment that we had no idea that it would even be possible to go that way. It’s just certain ideas that they had that made us change everything that we were doing about certain topics or certain pages.

Ben:

So, this was my first responsive redesign project, and I wasn’t familiar with Bootstrap and the interaction of CSS and JavaScript and what all that meant for going responsive. So, any advice that I would give is to just get familiar with responsive frameworks. Look at the options that are out there. Think mobile-first; that was some good advice that I learned. Take your most complex page and see what it’s going to look like on a mobile device. Anything from that is going to come more easily when you plan for mobile and then expand out from that. And just look for resources. Responsive web redesign is complicated, and there’s podcasts and a lot of good information out there, so take that all in and try and learn as much as you can.

Karen:

Well Ben, Chad, this has been such an enjoyable conversation. I think you’ve done great work with this project and I’m really thankful that you took the time to come talk to us about it.

Ben:

Thanks Karen, thanks Ethan. We really appreciate your time.

Chad:

Thanks for having us.

Karen:

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.