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, Ethan and I are not worthy. “We’re not worthy!” We have Chris Coyier and Katie Kovalcin here to talk about CodePen. Welcome!

Chris:

Yay!

Katie:

Hi!

Chris:

Thanks for having us! “We’re not worthy”? I have the Responsive Web Design Podcast page open and it’s like if anybody’s not worthy, it’s me. You’ve got NPR on here, The Toast—I almost feel like I should just be sitting here asking you questions about The Toast. But we’ll do that another time.

Karen:

If only you had a podcast, Chris.

Chris:

Oh! Good point!

Ethan:

Wow, cross-marketing. I love it.

But before we dive in, I’d like to take a moment to mention our sponsor, Harvest. I’ve actually been using Harvest for years, so I was incredibly excited when they approached us about sponsoring the podcast. Harvest bills itself as a beautiful business tool for tracking time spent on client projects. I’ve worked with a number of teams who love it. They love how easy it is to track hours across projects, how beautiful and well-designed their reporting tools are, and I’ve heard from a lot of folks that I’ve worked with that Harvest really helps them stay on time and keeps their project under budget. Now, personally, just speaking for myself, I love its invoicing and expense management. I can update my projects in Harvest with my web browser, with my mobile device, and regardless of the size of the screen I have closest to me, it’s a real joy to use. So if you’re interested, you can check out Harvest at getharvest.com today. What’s more, after the free thirty-day trial, you can enter coupon code RESPONSIVE at checkout and save fifty percent off your first month.

Karen:

[laughs] Well, I’m sure people know who you are, but I would love it if you would both just introduce yourselves, tell us a little bit about who you are, what you do, where you work. Chris, why don’t you go first?

Chris:

Okay. CodePen is my product with two co-founders of mine, Tim Sabat and Alex Vazquez, that we started, oh, three/four years ago, making it. And it’s a “web app,” whatever that is, for… sometimes we refer to it as a “playground” for front-end developers. So the heart and soul of it is you can write HTML, CSS, and JavaScript right in it, it’s kind of a web browser/code editor. But you sign up for it, and then as you make those things, which we call “Pens,” they save to your account and you have a little online version of yourself that is a repository of those things that you’ve built. I’m still working on my elevator pitch for it; it’s a little weak, really.

But yeah, CodePen is kind of my baby, and super-recently we undertook a major redesign of it, which Katie, in a sense, headed up. It wouldn’t have happened without Katie, because back in the day she expressed some interest in working on it, and it went from there. So take it, Katie.

Katie:

Uh yeah, my name is Katie and I am a designer at Sparkbox, which is a design/development/backend software development shop in Dayton, Ohio. And yeah, we worked with Chris and Tim and Alex at CodePen to redesign it and it’s been a lot of fun, and we’re kind of right in the middle of it right now, about to start phase two.

Chris:

Phase two… Design can happen in phases? That’s so cool.

Katie:

[laughs] Yeah, I guess that’s my short elevator pitch about what I do and what Sparkbox does.

Karen:

So normally at this point I like to ask a question about how did you convince your boss that you should go responsive, but I’m going to bet that that wasn’t much of a question.

Chris:

[laughs] I saw that on the list of questions that we might be able to expect here and I’m like oh, this is so funny, because it’s like, “How do you convince your boss/the team who’s going to be working on this project to go responsive?” I’m like, “I am both of those things.”

Today as we speak on CodePen, we’re ninety-five percent responsive I’d say, like all the way down to the “fully squeezy.”

Karen:

You’re like, “I am in charge here.” So what I would love to know is actually a question that is near and dear to my heart, which is the balance and the trade-offs between responsive and adaptive. So, the way that I might phrase this question is: some organizations opt to use some adaptive designs on the front-end to solve for a particular layout or particular device-specific problems that they maybe could handle responsively but they opt not to. And Chris, I have used your example, I think you wrote a blog post a couple years back about mixing responsive templates with separate mobile templates for CodePen. So, I would love to hear both of you talk about how some of those trade-offs have been made as part of this redesign, and if the product is not fully responsive yet, why is that?

Chris:

Hm… There’s so much there. That’s a massive one.

Ethan:

Bring it on.

We’re either full-on squeezy or we have some kind of distinguishing cutoff in which an entirely different set of assets get served for a particular page, and there’s a handful of cases where that is.

Chris:

Sure. I think the thing that you’re referring to, which is still in place today as we speak on CodePen, we’re ninety-five percent responsive I’d say, like all the way down to the “fully squeezy.” And when I think of adaptive, I think of, “At this value, we’re going to swap to this layout.” It’s not “fully squeezy,” or whatever. So I don’t know if that’s still the difference between fully responsive and adaptive, but that’s how I think of it, anyway. We really don’t make that distinction very much. We’re either full-on squeezy or we have some kind of distinguishing cutoff in which an entirely different set of assets get served for a particular page, and there’s a handful of cases where that is.

I really wanted to serve a completely different experience to that page based on some kind of—our best guess if you’re on a small screen mobile-ish device or not.

So the editor, the thing I was explaining, the code editor in the browser part of it, which we’ll refer to as the editor, is one of those pages in which that just some CSS breakpoints and some conditional JavaScript and stuff wasn’t enough, at least for us, to make that page happen. I really wanted to serve a completely different experience to that page based on some kind of—our best guess if you’re on a small screen mobile-ish device or not. So, it’s one of those pages that just has a different kind of architecture to it than the rest of the site. But whereas on the homepage, you come to that, everybody gets the same homepage, design decisions are made based on largely the width of the screen and stuff, so. I can get more into that if you’d like, but that’s kind of the thing. And as we were working with Katie and the team at Sparkbox, mostly we didn’t broach that. It was mostly just a design deliverable. Like, we really didn’t redesign the editor as part of phase one of this design, so it didn’t come up in the redesign all that much.

To handle a lot of the responsive decisions, a really, really big help in knocking that out was Chris actually came to the office and worked out of our office for a week.

Katie:

And then to handle a lot of the responsive decisions, a really, really big help in knocking that out was Chris actually came to the office and worked out of our office for a week, and then Chris and I were able to sit down and just look and pair, and look at everything on the screen at once and just go through in probably annoyingly nitpicky detail, where I would say, “Hey, let’s try changing this around.” We would pull it up on different devices thinking of a couple key pages that people probably would get to via Twitter on their phones. So, like, profile pages and maybe just how a Pen looks on a mobile device and things like that. We didn’t want to get too segmented, but we were able to refine and address some of those problem areas in person and that was a really big help.

Chris:

That was cool. The idea of pairing, that was when we were at our best when we were working on this project. Some of the stuff was more slow-going and none of it was really skippable, like, “Let’s do a bunch of research and let’s come up with some design deliverables and stuff,” like just a round one design deliverable. Then I would take it and be like, “Okay, I’m going to use my front-end developer superpowers to turn this into an actual web thing,” knowing that it’s going to go through rounds of revisions. And then once that existed, once like a first cut of it was happening on the web, that’s when we really excelled in working together.

We just referred to it as “pairing” because it would often be two of us sitting and looking at the same screen and making decisions on what things look like and what the possibilities were, and what should we try next, and fixing up little mistakes, and going through the squeezy process and fixing things there.

We were using the actual Pens and usernames and things like that; it looked exactly like codepen.io does. It was just this separate test site where we were able to work with the real content.

Katie:

And an interesting part of that, in relation to the content, is Chris, you and I’m not sure who else on team CodePen, made that separate database of this test environment that had the real CodePen data. So we were using the actual Pens and usernames and things like that; it looked exactly like codepen.io does. It was just this separate test site where we were able to work with the real content—maybe not the totally most up to date live content, but at least real enough where we weren’t just guessing in a lot of the ways that I was in Photoshop, kind of just like, “Oh, here’s what a Pen would look like, a whatever Pen.” We were looking at how actual Pens with the actual colors and textures and things like that, and names that could break line links and stuff like that. So that was a really, really big help.

CodePen was a really great opportunity for us to be pretty experimental with our process and see how that looks and write about it and find what was working and what didn’t work.

Ethan:

That’s great. I guess I’d like to hear—and Katie, this might be a question for you—but before you guys settled into this, it sounds like you really focused on rushing to a prototype and getting things into a browser as quickly as possible. But I guess I’d be curious to hear, how did Sparkbox come up with a scope and structure for this process? I mean, Chris is all like, “I want to redesign CodePen!” But how, like as an agency partner, did you guys actually start to get your hands around how you could actually make that happen?

Katie:

There’s, right now, just a team of two of us that are kind of the full-time designers, not really working in code and doing the strategy, research, and design kind of stuff. So, CodePen was a really great opportunity for us to be pretty experimental with our process and see how that looks and write about it and find what was working and what didn’t work. So that’s kind of… the scope wasn’t very limiting because it was just us wanting to figure that part out. So that was actually a really nice luxury of this project in being able to just do it the way that we would want to if there weren’t really constraints. And then, yeah, Chris figured out how that worked with the people running Sparkbox and what would be like a little fair trade.

It was mostly just like a green field, like, “Please help me make the site better.”

Chris:

But it really was me just being like, “I think we should redesign…” I don’t have like some grand vision of—I mean, I do; I’m not trying to say I have no vision for CodePen, I have plenty of vision for CodePen. But when I approached you, I just knew that you’re a great designer, I know Sparkbox does great work. I wanted to just let it be like what does it look like to work together to bring good design to this project, where so far it’s been just me and thus rather mediocre design to it.

So it was mostly just like a green field, like, “Please help me make the site better.” I had no idea; I wasn’t like, “I have X, Y, and Z goals, this has got to happen, this has got to happen, this is the page that’s got to happen first because Tim needs to do this first.” There was really just none of that, which was probably somewhat helpful and somewhat harmful, because I bet in the very early days it was a lot of shrugging and, “I don’t even know how to approach this thing.”

Katie:

Yeah, it was interesting from both sides because the three of you were all like, “Well, we’ve never done a formal redesign or kickoff meetings” and stuff like that. And then from our side, we were like, “Yeah, we want to do those things.” So we’re all figuring it out together, which was a pretty cool relationship throughout the project.

It ended up being more formal than I expected, and it followed what seemed like a very professional and adult-like redesign process.

Chris:

It ended up being more formal than I expected, and it followed what seemed like a very professional and adult-like redesign process. There was a lot of legitimate research, which took the form of audio interviews and stuff—and Katie led most of this, so you should probably be talking about it. But it started out with research and then moved on to scoping it out and we had this big, fancy official kickoff meeting, which I’ve never done before. I even have the document right here in front of us, like they invented personas to typify some of our users and then imagined what they would need and want out of CodePen in the future kind of thing, and those personas guided our way through the redesign. I was like, “Fancy!”

The other really nice advantage about the CodePen community is how willing and open and excited all of the people that use and love CodePen are to give feedback and participate in those things.

Karen:

Katie, let me follow up on that and ask how did you do that initial research and prioritization? One of the big questions that seems to come up with responsive designs is how do you make good choices about the priority of different objects or different features as they reflow across different screen sizes. How did you know how to make those decisions?

Katie:

Yeah, so CodePen’s pretty interesting in that the people who use it are generally some sort of web person doing something to do with front-end design and development. So, that’s already a pretty specific user. And so then just getting kind of nuanced in the different types, and we did different surveys to get, kind of generally, the big numbers.

The other really nice advantage about the CodePen community is how willing and open and excited all of the people that use and love CodePen are to give feedback and participate in those things. So, reaching out and finding users to interview and talk to was totally easy and great; people really wanted to be part of this conversation and be part of this redesign—which I’m getting sidetracked, because there’s a lot of that I want to say about this.

We have the separate redesign site where we were documenting everything about our process in the open, so people were following along, which really helped to tap into that community of people that really love CodePen and want it to be this really awesome thing, this community that they want to be a part of. So, we really were lucky to be able to utilize those people to inform a lot of those decisions. So through talking to users, doing some one-on-one interviews, going and watching different people—obviously people around the Sparkbox office use CodePen and love it. So, being able to just talk to a lot of different people and see the ways that people are using it, we were able to distill down to a couple of core different types of use cases, maybe not necessarily the type of user but the way that they use it.

I think we broke it down into browsers—not the kind you use to access the internet, but people who browse CodePen—which I consider myself one of those types of users, where maybe you just search through it and find inspiration and you bucket that to your collection, or save it for later, or use it as a communication piece on your tool, or you’re really just soaking up all of the awesome content that other people are creating.

Then there were the super-users, like the people that create that beautiful artwork and are using all of the different features, the presentation features, private Pens, all of these more robust features. They love CodePen, they blog on it, all of those different things.

And then we had just kind of the, like, regular user who dabbles in a little bit of that stuff. And there are also more of the fringe use cases, like teachers and presenters and stuff like that, where we were like, “Well, those numbers aren’t necessarily as high,” which those features are definitely important and we definitely want to cater to them, but that was something that we were like, “We’ll set that aside for a later time and just focus on these specific use cases.”

We built out different flows for all of those different kinds of people; that’s where those personas came in for all of these different user flows. And then really being able to take that information and apply that way of thinking to come up with some different key design features, like on the logged in homepage, we’ve now added this sidebar that has all of your recent Pens, because that was something we heard over and over again, like, “I wish I could get to my Pens easier.” So, again, just taking that feedback from the community that was so willing to help us was really a key part of making those UX decisions.

There’s so much that’s lost in translation from getting that out of a mock-up into the browser that it’s like, let’s just get really detailed once it’s in browser.

Ethan:

That’s awesome. If we could maybe step back from CodePen for just a second, I’d love to hear a little bit more about design process in general. I mean, both of you guys are pretty talented designers, you’ve both worked on some fairly large-scale responsive sites in your day. Have you found that your design process has changed as you’ve been doing more, I don’t know, “squishy,” “flex-y” work in general?

Katie:

Yeah.

Ethan:

Okay, alright. [laughs]

Katie:

[laughs] The short answer is yes. I feel like I do actually less designing the more nitty gritty the responsive site gets. Not necessarily that I don’t design, but it’s kind of like trying to do as much planning and documentation upfront, all of that research stuff and figuring out what key templates there are and how to document this into a growing style guide and all of that stuff, and then also getting it into browser quickly.

That middle part of actually doing the “visual design,” which I know is a phrase that people are not into using, but for lack of a better word, that part of the process I feel like is getting smaller and smaller because there’s so much that’s lost in translation from getting that out of a mock-up into the browser that it’s like, let’s just get really detailed once it’s in browser.

Deliver me some kind of pretty good-looking flat mock-up in Sketch or Photoshop, but let’s not treat that as sacred at all, let’s get that into a prototype.

Chris:

I’ve learned most of my new process stuff from Katie because she’s so good of a designer, and particularly good in not-browser tools but prefers to be in browser tools, which is so strange but kind of awesome, you know? So it’s like, deliver me some kind of pretty good-looking flat mock-up in Sketch or Photoshop, but let’s not treat that as sacred at all, let’s get that into a prototype. Then look at it and talk about it as a prototype in the browser, and then maybe she’ll grab it and take it back—like even just as a screenshot—take it back into Photoshop, try some new stuff, deliver that again. Or we just talk it out if it’s easy enough to be something where it’s just like, “Oh, just move that down a little bit,” those kind of easy tweaks that just happen right in the browser through that pairing process.

Before that even started though, I was a big fan of some of the kickoff exercises that we did which involved more people than normally happens in design. So everybody was involved at CodePen in the early kickoff stuff, and there were some exercises that I’ve never done before that I think are… I don’t know; I don’t know how common they are.

When you ask everybody involved in this thing, it was like we got crazy ideas. “It should be this everlasting flowing stream of random stuff.” Like, whoa. Are you drinking this morning already?

But, for example—there were many of them, but this was just one of them—was have everybody sketch an idea, and it was so eye-opening. So it’s like we’re having Tim, our server and database guy, sketch what he thought the homepage of CodePen could be, was like way out there. I found that I was the most conservative one. As somebody who is probably making the most decisions on what these pages are actually going to have and look like and be on, I probably have the final say in all that, my ideas for what the homepage would be were minor variations to what we already had. But when you ask everybody involved in this thing, it was like we got crazy ideas. “It should be this everlasting flowing stream of random stuff.” Like, whoa. Are you drinking this morning already? That was kind of my reaction.

But then you step back and you’re like, “Wow, that’s so interesting. It’s interesting that you think that’s where CodePen can go,” and we got so many good ideas from that. I think probably the sidebar layout for the logged in homepage now with quick links to “my recent content” kind of thing, that was born out of one of those episodes, I think. I was way into it. Pretty much all I’ve learned about design process recently has been from this.

It was not a surprise, I don’t think, to anybody that this was coming and what it was going to look like and what it was going to do.

Karen:

Let me ask about your rollout process. I heard you mention “phase two,” and I’m always particularly interested with organizations that have a loyal and passionate and frequent user base, how they make changes to a product that people really love. How did you think about staging the rollout and communicating changes to the product to your customers?

Chris:

We lucked out in some ways in that because this was—part of the deal of working on this was to document the design process and we have a—much like you have done with The Toast and explain what’s up and who is on the team and what we thought about and all that stuff, there’s one of those for this project as well, it’s codepen.seesparkbox.com, that we kept up to date throughout the months of working on it.

Our approach was not to break it up by front-end/backend/whatever, but it was a timeline, it was month-by-month what we were working on and what we were thinking. And because that was so out there and people were seeing it, I don’t think it was a mystery to people that this was going on. There were screenshots and we were posting little things on Dribbble. It was not a surprise, I don’t think, to anybody that this was coming and what it was going to look like and what it was going to do. And it was for a long time; it wasn’t like, “Ooh, teaser shots! Last week! Okay, next week it’s live!” It was a long ongoing process, so I think people had plenty of opportunity to see what was coming before it came.

The rollout was fast and swift once it came, which also came a little arbitrarily.

And then we decided to just drop it all. We definitely had plans… Some people do rollouts with like, “Ten percent of people are going to get it and then we’ll see how they react and then we’ll roll it out to twenty-five percent.” We thought about that and had the tech in place to do that and then we were like, “Eh, let’s just drop the thing.” [laughs] So the rollout was fast and swift once it came, which also came a little arbitrarily. It was like, “Let’s just pick a date and really sit on that date, rather than”—

We saw the launch as an opportunity to get more feedback to iterate on.

Katie:

I think because it’s such a large product, we were like, “We could spend years working on all of the stuff we want to fix, so let’s just get it to like this spot where we feel good having it be public-facing and then we’ll continue to refine it after that.” We didn’t really see the launch date as, “This is the end. We flip the switch and that’s that and we’re done.” We were just like, “Let’s just get it out there and then we’ll go back and fix some of the things that aren’t working.”

We thought it would be really helpful to get people’s reactions and feedback so maybe all of these hypotheses that we had about, “This would be a really great new feature!” and we implement it and maybe people actually hated that and we would have to fix it anyways. We saw the launch as an opportunity to get more feedback to iterate on. And Chris, I think it was you or somebody at CodePen that had the great idea of setting up a GitHub repo for all of the issues once it launched because we knew there were going to be tons of things that we didn’t get to.

Chris:

Like, literally bugs. I didn’t launch it knowing about any particular bugs, but just because it’s a major web project, there’s going to be some, for sure. And there were, of course. And having, ”This is where you go to report them; of course we’ll take them any way you got ‘em. You want to tweet us? Great. You want to post them on our Facebook page? Fine. You want to email us, into support? Great, that’s what we’re used to.”

But we thought, as an experiment, let’s open up a GitHub repo that allows people to put it there, and that was even better in that, I don’t know, people just took to it.

Katie:

It kind of, like, QAed itself. Like, we did QA, we did lots of QA and device testing and stuff, but—

Chris:

There’s no way you’re going to get that kind of QA coverage, though, with a team of four.

Katie:

Exactly. So there was just, you know, everybody using whatever their normal browser device was, putting in their reports, “Well this is what I see on this one page,” and, “Oh, whoa, yeah. We definitely didn’t catch that.” So, that was amazing.

Chris:

And then it was all hands on deck when it dropped. It was, “We’re not just going to gather these up and then next month we’ll address them.” We’re like, “We’re going to drop this and we’re going to be closing these issues as they come in.” So it was really a week of that, like: issue gets dropped, somebody’s on the case, fixing it and getting it out and stuff. It’s still up; it’s been a month and a week maybe since we dropped this, and our plan is to close that repo this week. So, we haven’t had a new issue in a number of days and I think people are just reverting back to the normal way of reporting bugs by emailing us or using our support form.

But I would recommend that to anybody, if you can point people to that kind of thing. It helps you too because there’s less duplicates, because people can see the open issues and be like, “Oh, I’m having that one too. They’re on it,” which is great, rather than having to triage every single one. Anyway, that was a minor thing.

It’s always my favorite thing when you see like, “I redesigned Facebook and posted it to my Behance,” and like every single photograph is beautiful people with wind blowing in their hair.

To a point Katie made earlier about the rollout process, we really did make a—having a staging server isn’t particularly rare, but it was cool to have one that was an exact duplicate of the live CodePen that anybody could use if you had the password to get into it. So, it was not one of those—we weren’t working with mock-ups.

Being able to make design decisions based on that ever-changing content of what people build on CodePen was pretty cool.

It’s always my favorite thing when you see like, “I redesigned Facebook and posted it to my Behance,” and like every single photograph is beautiful people with wind blowing in their hair and stuff. It’s like, “But homepages are way more gnarly than that.” And the homepage of CodePen changes every twenty minutes with new stuff, and a lot of times there’s weird clashing colors and who knows what-all in the Pens that people make. So, being able to make design decisions based on that ever-changing content of what people build on CodePen was pretty cool. And then they were testing the real thing on the real server, just 100% accurate version of CodePen. That was pretty nice; that was good for QA reasons before launch.

Katie:

Yeah, and that was some really informal feedback that we were doing. We were asking people that we knew were big CodePen users or just kind of like close friends and stuff, like, “Hey, can you go to this URL and here’s the password and stuff, and just like can you poke around and let me know if anything is seeming weird?” We’ve all been staring at this for six months, so maybe getting some fresh eyes. So we were able to catch some different design choices that we maybe overlooked or didn’t fully think was—or maybe we thought it was cool and then we heard from several people, like, “Oh, you know, that’s kind of confusing.” So, we were able to make some minor changes leading up to launch.

Chris:

And they were able to do it on their own computer, in their own homes, you know? Like if you’re going to do user testing, that’s the best place to do it they say, right? Rather than being like, “Oh, we don’t really have a live version of this, we’re working on it. Use my computer and we’ll watch you,” it was, “Just go to this URL.”

There was a lot of stuff like dealing with how Pens are handled and how heavy they are, and how we had to make design decisions based on that.

Ethan:

That’s fantastic. I’ve got to ask, since we’re talking about getting this in front of users as quickly as possible, and also because Katie has a very fantastic podcast on this topic, was performance part of the design discussion at all? Not just how this thing was going to look and function, but how quickly it was going to be working?

Katie:

Yeah, that was actually a big discussion because, like I was saying earlier through the user research, part of one of the personas of the people who browse and stuff, I was like, “Oh, well, for browsing it makes total sense that we should show more than six Pens at a time. That’s such a tiny number. Let’s show more.” And then that was like a really big performance hit, which Chris can probably speak more to. But there was a lot of stuff like that dealing with how Pens are handled and how heavy they are, and how we had to make design decisions based on that.

Chris:

Yeah… That’s a weird conversation. Not really. But it’s like when you go to the homepage of CodePen and it loads up, it’s not just one website that’s loading, it’s seven. So, we’re already in—because each one of the little previews, the little iFrames of what people are working on, are little full complete websites, and they’re iFrames, which aren’t particularly known for their speed already. So, anything that we can do to address speed in those iFrames is a good idea, which meant a lot of server-side caching and whatever, kind of helping people make good performance decisions inside of those things. And then that reduces our performance budget, as it were, for the rest of the site. But as far as guiding design decisions, it didn’t affect a ton.

Six ended up being the right decision for performance reasons and layout grid reasons.

That number of six is kind of a big deal, that Katie mentioned. Six is also just a good number because it splits into grids pretty nicely. In fact, at responsivewebdesign.com/podcast, I noticed that there’s six shows that you show because it’s 3x2 at widest possible screens, and then as it narrows down it goes 2x3 to across three down, and then goes down to the single column later. That’s the same number we chose at CodePen because of how grid-friendly it is. In the early days of CodePen, we had twelve or something, and then we broke it down to nine, and then eight, which is 2x4, and then six. And it was just a nightmare of trying to get the pagination working properly, because you don’t want to request too many when people paginate and then remove one because that’s a waste of bandwidth. And then if somebody sends somebody, like, /page/4, it depended on how many Pens we were showing that would paginate that far. It was kind of a nightmare. So, six ended up being the right decision for performance reasons and layout grid reasons.

Katie:

We were also pretty conservative with the amount of fonts we were loading and stuff. That was something that we kept in mind throughout the whole design process, not getting really wild and out of control with loading in tons of those, trying to just keep it around to I think maybe like four or five we’re using. And so there were definitely conversations around it.

During the redesign I was just like, “Let’s just not screw it up. Let’s stay where we were or better” as far as number of requests and the size of those requests.

Chris:

Fonts? I think it’s less than that. I don’t know. Yeah, we’d run speed tests on pages that weren’t heavy grid pages, because those are so variable with what people do in there. I’d test something like the “about” page or something that loads less and base performance budget type decisions based around that. We were already pretty okay, like I try to keep a pretty good lasso on that as far as speed, and we were in a pretty safe zone already. So, during the redesign I was just like, “Let’s just not screw it up. Let’s stay where we were or better” as far as number of requests and the size of those requests.

Katie:

I did see a couple comments on Twitter that people said it feels faster, so that was a win in my book.

Chris:

Oh, that was so random. Everybody agreed—even everybody at CodePen was like, “Oh yeah, it’s way faster now.” I’m like, “What are you talking about? We didn’t do anything!”

Ethan:

[laughs]

Chris:

Literally nothing. I think there was one little change that was a perceptive change that was the root of all this, which was it used to be so you’re looking at a grid of six Pens and then you click the button to go forward and it loads six more of them, we used to have a little artificial delay in there that would fade them in order. So, it’d go like one-two-three-four-five-six, really slight. And it was just CSS that did it, with a kind of animation delay on it. I think that was not a good move, maybe. I was really hesitant to remove it because I thought it would work the other way, like cognitively it’d seem like they were loading faster because the delay was so short. But removing that seemed to be the trick for making it perceptually faster even though we actually did nothing for performance at all. But I don’t think we screwed it up.

Not being too attached to anything is super helpful for being that malleable process, especially once it is in browser and we’re seeing how stuff is actually working together.

Karen:

You know what I bet both of you have, is some really good advice for other people. I would love to hear from both of you, like if you were talking to people who were about to embark on a big responsive redesign project, what have you learned? What would you tell them to do?

Chris:

Sketch a lot, that was pretty valuable during it, that I’m all about now. I’m even like one of those “I carry a notebook around with me” things because it’s such a useful thing, so many good ideas come from that.

Katie:

I think not being married to your ideas is a really big one. I’ve definitely done several projects in the past where I get really into an early idea where I’m like, “That’s it, that’s going to make it the full way, that’s a really great idea,” and the more you find out or the more you build out, maybe that idea wasn’t so great. So I think not being too attached to anything is super helpful for being that malleable process, especially once it is in browser and we’re seeing how stuff is actually working together. I think that’s a really, really big help.

I’m way more into the what-if scenario, like, “What if this was way different now?” I get more excited about big, drastic changes that it’s almost addictive.

Chris:

I would say it even gets a little addicting. Like, that’s another one I got from you, in that I think early on I was pretty bad about that actually, like the, “No, from the grid you used to be able to get directly to the full-page view and you can’t now and that’s unacceptable,” you know? And then I would lose some of those battles over time, being like, “No, that’s just a stupid feature that nobody cares about anyway,” or whatever. “What if it wasn’t there? Can we at least talk about the implications of what if this feature moved or was different than what it is now?” And now that enough of that has happened, this kind of, “Don’t hold things dearly,” I’m way into it. I’m way more into the what-if scenario, like, “What if this was way different now?” I get more excited about big, drastic changes that it’s almost addictive.

Katie:

Yeah, a lot of this redesign I think came down to removing a lot of things, or rethinking, or questioning everything on the site, like, “Do we really need that?” And then that also maybe aided the performance and stuff as well.

Chris:

Yeah, possibly.

Katie:

I know there was a lot of, like, when we were pairing I was like, “Oh, rip that out, get rid of that, let’s just leave that. Do we need that? Get rid of that.” [laughs]

Chris:

Yeah, and now I’m like, “Yeah! Rip it out! Yeah!” I’m like, addicted to removing features now. The best one that I was so happy that we ripped out was we had this concept of a flyout menu, so you’d like hover over a Pen and in the hover then another little—like, basically the burger showed up on hover, and then you’d have to hover over the burger also, and that would reveal a menu for extra power-user feature things, and it was so complicated. Like, if you think hover-only interactions are bad, this was a double hover interaction. There wasn’t anything that was that valuable in there, and we were able to address a few of the things that were valuable in there, and now that’s gone and it feels good. Farewell.

Karen:

And with that, let me say thank you to you both. This was amazing. I have been so excited to get to talk to you and hear what you have to say, and I would talk to you all day if I could. But alas, I will have to let you go and just say thanks so much for being on the show.

Katie:

Thank you so much for having us.

Chris:

Yeah, it was wonderful. This really seals my legacy, I feel like.

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.