Episode Transcript

Ethan:

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

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, well, I speak for Karen and myself when I say that we are beside ourselves with joy to be speaking with Frank Chimero who’s here to talk to us about other things, including but not limited to his wonderful new website, frankchimero.com. Frank, thanks so much for joining us.

Frank:

Hi! Hello! Morning!

Karen:

But first! Some exciting news from our sponsor, Gather Content. On Thursday March 23rd between 4pm and 6pm GMT (UK time) or 11am to 1pm ET, they’re offering their amazing masterclass called Content strategy and delivery for website projects. Pulling off a responsive redesign means wrangling lots of content and stakeholders. The editorial and migration process can be one of the most difficult parts of going responsive. Managing the editorial processes in a responsive redesign is difficult enough, so make your team’s life easier, by learning from the experts in this masterclass from GatherContent. Go to https://gathercontent.com/masterclass to learn more and sign up. Thanks, Gather Content!

Ethan:

So before we dive in, just a really quick digression for our listeners. As you might know, we tend to focus each episode on a specific organization or brand that’s taken their site responsive. For the next few weeks, we’re going to be trying out something a little bit new, where we interview designers and developers and content folks that we really admire, and talking to them a little bit about how responsive design has intersected with their practice in some way. I’m personally really excited to have Frank here to help us kick that off. So Frank, thanks for indulging us in helping us figure that out.

Frank:

Oh yeah, of course. I’m sure I’m going to learn just as much from the two of you as anything that I’m going to say.

Ethan:

[laughs] You’ve never listened to the podcast before, huh?

Frank:

[laughs] No, I’m desperate here, guys. Help me out, this is hard.

Ethan:

[laughs] Well, as someone who’s got their Responsive Web Design for Dummies book open right now… Frank, maybe tell our listeners a little bit about yourself, a little bit about your background, what you do on a daily basis. The floor is yours.

Frank:

Yeah, of course. So, I’m a designer and an illustrator, and I do a bit of writing as well. Most of the design work, well, when I first started it was in publication design, so I was doing things like books and workbooks and that sort of thing. Then I started to find work doing web stuff; I started out on the web like a lot of other folks, just making weird little personal websites on Geocities and that sort of thing. Most of the client work wound up being like a lot of typesetting and type-heavy websites, catalog websites, and then eventually editorial sites as well.

That’s where responsive design comes in, actually. Most of that exploration around responsive came from reading your article, Ethan, and wanting to implement some of those ideas on my own site, and then that extended into having to worry about that sort of thing for my clients, as well. So at this point I would say my day-to-day practice is probably like two-thirds digital work with software or on the web, and then like one-third printed publications.

Ethan:

That’s great. And of your digital work, would it be safe to say that most of it is responsive in some way?

Frank:

Yeah, all of it’s been responsive for at least the last six years.

Ethan:

Yeah, about the same here. Well, I’d love to talk a little bit more about your client work. But before we do that, maybe we could talk a little bit about your website, because you just redesigned it, and I don’t know how you do it because you seem to redesign it every six months… [laughs]

Frank:

[laughs] Yeah, it’s an every-year thing.

Ethan:

Yeah, that’s a hell of a tradition. I really like that. But maybe tell me a little bit about how you think about the redesign of your site, and maybe this one in particular. It’s really interesting to see how you reinvent yourself every year and how you come across these beautiful responsive experiences that they don’t just fit on different sized screens, they really kind of feel at home. Tell me a little bit about some things you’re proud of this redesign, or how you approached that process.

Frank:

So on my own personal site, I redesign it every year because it seems like priorities change every year. Also, I find the process really fun. It’s sort of an opportunity to try new things or to learn new technologies. So this particular one, I was just moving the site over to Jekyll, which is a static site generator. At first it was just going to be like a direct port. It was just like let’s just move it from this codebase over to this rendering engine. Along the way, I was like, well, it’d be nice if we added a little page, just had a list of movies that I liked, and then I needed to figure out what sub navigation looked like, and then things just spiraled out from there.

When it comes to the responsive stuff, I actually have a pretty sizeable benefit over most of the client work that I’ve done and probably most other sites on the web, because the vast majority of my site is just text. So, there’s nothing necessarily there to really complicate the logistics of responsiveness. There’s no media players, there’s no carousels, there’s no advertising to think about. All of that stuff sort of comes “kit and kaboodle” with any sort of client work that you do, especially for media clients. So, I get to keep things really pure on my own personal site, which means I feel very obligated to keep it incredibly simple and to try to not do too many flashy things with it, and just to really let the type and the color choices and the structure of the website do the work for me.

So, that’s kind of where it began. There’s a few other kind of weird choices on the site. It looks a little dated, frankly, because there’s the side column, which is very, very reminiscent of 90’s frames. At least on desktop there’s this menu vertical column off to the side, but that’s mostly just a factor of having a lot of pages in the navigation on the website, and not wanting to make the navigation too convoluted, and not really wanting to hide the navigation underneath a collapsable menu or a hamburger menu on mobile, and just sort of being like, well, there’s like seven things here and let’s just put seven words up on the screen for you to tap on if you want. So yeah, that was kind of like the main mental mindset for walking into it, was just to make it look like what it is.

Ethan:

I really like that. There’s a couple of things I want to follow up on there, but let me start with two words you mentioned, which are mobile and desktop. I mentioned this before, but the thing I love about your redesigns—and your design work in general—but I really do feel like it settle in nicely with most devices I look at it on. Where do you tend to start your redesign process? We can talk about your website specifically, or more broadly about your client work. But do you tend to focus on mobile versus desktop first? Then how do you bring other devices and contexts into view when you’re working on a design?

Frank:

That’s a good question. I always start on mobile not necessarily because I need to remove elements that would be on the page on desktop and simplify it down, but mostly because, from a layout perspective, it’s kind of an easy problem to begin with. It’s simplified because most of the things that you’re going to do is choose the order of the elements on the page and then vertically stack them, just because most of the time you’re not going to have enough horizontal space to put things side-by-side. So, you’re beginning with really foundational design choices, which is how am I going to express the hierarchy with color here or through typefaces or type sizes? How do links look? What’s the navigational scheme, and how does that work on mobile? I’ve consistently made choices just to have the navigation always be present on mobile and not conceal it behind some sort of JavaScript interaction to show and hide a side panel or anything like that mostly because I really like the simplicity of how everything scales up. Because on mobile, everything is initially visible as well.

So from there it’s like this really nice narrow design, and if your hierarchy works there, then all of your design choices after that can just inherit it and you can just sort of cap off the width of it if you want to, or then you can begin thinking about how things can sit side by side, or if you want to go with a gridded layout for, say, a blog post, or something like a masonry layout or something like that. So, mobile-first for me is less about a technological stack or anything like that. It’s more about just the purity of the design problem that you’re trying to solve. It feels like you’re making the important choices first whenever you do that. In my mind, the way that I’ve worked, it ensures that those choices are good ones, which makes the work that you do after that a little bit easier.

Karen:

Frank, I can totally admire and respect your desire to focus solely on your own design problems and your own website. But maybe shifting gears a little bit, can you talk about your client work in general? I’d be particularly interested in your point of view on what’s challenging about a responsive design process in the client services framework.

Frank:

Yeah, it’s a very unique situation. Because as we know, responsive designs are not really artifacts, they’re like sets of rules for how content can adapt in its layout. So instead of having like the one thing to show around a company whenever you’re working with them, you’re actually working with them to develop a set of rules to make sure that things are responding and behaving appropriately based on whatever the context is. So that immediately changes the communication dynamics between you and the client, because immediately you need to get into what their priorities are, you know? Because it might be self-evident what the priority of how they want to show things on mobile might be, but whenever things need to grow, does the order of that still hold up? Are there extra components that we need to show if there’s extra space on the screen? So, that’s the first thing. It just changes the communication dynamics between you and the client.

The second thing is that it actually changes how the client works amongst themselves, because the work becomes a lot more collaborative. For instance, in my experience, I worked for about a year with NPR, and we were working on their music website and branding, and then after that we sort of rolled out into updating their player into a persistent player. Doing that responsively was a really interesting challenge, because all of a sudden it was this collaborative effort where I was acting as a designer thinking about how the page layout transformed, but also there were folks working in sponsorship thinking about how they could essentially make ad packages for the folks that advertise on NPR, and how those could behave responsively as well. The two of us collaborating together about how those ads could sit on the page, how they could be respectful of the audience’s attention, and really having to work together, me explaining some of the limitations about what we were trying to do and how we just couldn’t take over the full screen on desktop with advertising. But also them expressing some of the real needs that the advertisers were looking for whenever they were sponsoring NPR content, essentially.

So in my experience, it changes the communication dynamic because it just becomes a lot more collaborative, because so many of the choices don’t stand on their own, they’re influenced by all the other choices that are part of this system, which means that people don’t really get to specialize anymore, if that makes sense. They need a little bit of a working knowledge on the work that everybody else is doing to make sure that the content is well-written and well-structured and considerate of the fact that it’s going to show up in a bunch of different places in many different formats, that the design can adapt, that the sponsorship and the people sponsoring these pages understand that their advertisements might look different depending on how people access that website. So, the walls between these disciplines kind of get a little bit lower and there’s more interplay of ideas because the technology requires it.

Karen:

Let me just follow up on that, because you just addressed something there that I think is really important about collaboration, about how roles change in a responsive framework. Can you talk about how you see your role as a designer perhaps being different now that you are designing responsively? Or how your work and the work of other people that you collaborate with—whether that’s developers or writers or anybody else who might be working on the project—how do those roles shift and change?

Frank:

I think the role is really pronounced especially because I’m doing print work and a lot of responsive web design work. With the responsive web design work, it definitely feels more like my job as a designer is as a clarifier and specifier, if that makes sense. So, asking questions in such a way that I understand the priorities and the objectives of the work that we’re doing, and then coming up with a few different design solutions that I feel can address those needs, and then essentially looking around at the folks that are doing different kinds of work collaborating with me on this project and being like, “Is there anything weird about this?” because all of this work is braided together so tightly. That doesn’t necessarily happen in the print publication world because the tools are set up and the artifacts are so stable that the work can remain more autonomous. It’s more like it’s a sequence of handoffs, essentially, in that field, for the most part. Whereas here, everything is in play all at the same time.

As a designer, you sort of hit the logistical issues of bringing something into being a little bit sooner than the people who are acting in managerial role over it, or possibly even engineers, even though they hit this in a different way in their own field. But it’s more like you hit the points where you realize a certain segment of this project, there’s not a lot of definition there. You can go ahead and try to speculate and define it yourself, but really it’s a better idea to go around and ask folks to try to define their own thoughts about what they think this should be. So as far as my role as a designer, it seems like more and more it’s becoming not only like building these artifacts and defining and specifying, but also discovering the parts of the project that they had forgotten about, like these dark corners, and helping them actually define and come up with consistent ways to address those things so that you get a better whole system. So, really it’s just sort of like, “Ah, but did you think about this: X, Y, Z?” Or, “I realize after working on this for six weeks that we never talked about Y, and I completely forgot about it too, so now we’ve got to sit down and figure out how Y folds into this thing that we’re doing.”

So I feel like at this point of my career, working specifically on responsive design, there is a lot more of that than there was with the web design that I was doing before it. It’s mostly about trying to keep things consistent and stumbling across the points where those rule sets that you’re making actually break, and trying to figure out the points where it’s actually okay to be inconsistent versus needing to adapt the consistency for everything because you have this little spot that’s a little unusual compared to the whole. I’ve never had to deal with this until I started working on more digital projects and responsive projects, because there’s so much design systems that any time you come across something that’s a little bit different, you have to evaluate it against the design of the whole system. So a lot of times when you’re just sort of like heads down doing the work, you’ll come up against something that isn’t really well-defined, and then you have to go be the emissary for that ill definition and try to work with everybody to define it.

Ethan:

Something you just said, Frank, about evaluating patterns in context, I’d love to hear a little bit more about that. But maybe we could talk about that in the context of the tools that you use as a working web designer, and how those have been changing over the last few years. We can get real into the nitty gritty—are you more of a Photoshop person? Sketch? Do you do prototyping? What does your day-to-day tool belt look like?

Frank:

It’s honestly mostly Sketch just because I need to see what colors look like beside each other, and I need a nice color picker. Markup doesn’t give me a nice color picker, unfortunately. I’m sure there’s a tool out there, but I want to see these colors side-by-side, I want to see the typefaces and roll through a set of typefaces to see how they look when I typeset it appropriately. So, I still need some kind of canvas application. I’ve been using Sketch, but I could just as easily use something like Illustrator, it doesn’t necessarily matter that much. But for the most part, I just sort of hop over to markup as soon as I can. As soon as I make those choices about general structure and typefaces and relative type sizes and how the hierarchy is going to work, I typically jump over to markup. Especially if it’s on my own personal site, a lot of the markup is already there, so I’m just specifying new CSS for how I want things to behave, and it’s a lot easier just to change those values in markup than to try to go over and draw all of it from scratch inside of a drawing tool.

As far as prototyping goes, for the web stuff I don’t really do a lot of fancy animations or transitions or anything like that, so I haven’t really used any prototyping apps very much. When I was working with NPR on the player, there were a lot of transitional states, and we were doing quite a bit of work just in Keynote with the Magic Move slide transitions because that was the quickest and easiest way for us to bang something out and show it to somebody else to make sure that the flow of starting a podcast made sense, and to just generally toy with a possible animation style that would work to be descriptive enough to the engineers. We eventually got to a point where we were writing a little bit of markup with a little bit of JavaScript for the animation just as a prototype.

But for the most part I think it’s vastly diminishing returns on this, where these tools are enormously valuable probably like the first twenty-five percent of the work and then their value plummets after that, where it’s just sort of like you might as well just go work on the real thing and consider the work that you’re doing almost as scaffolding. It’s just like it’s a sketch; all the markup or the CSS that we have right here, we’re probably just going to throw it away, we’re just sort of feeling out what the breakpoints should be, or the measure on our type or something like that.

So, that’s the way that I’ve been working and it’s jived pretty well with most of the folks that I’ve worked with as well. Some folks that I’ve met that do a lot more work on mobile, they do more app-oriented work, they have a much more robust prototyping toolchain, than I do. But the work that I’ve done the past few years, it just hasn’t really necessitated it.

Ethan:

Leaping off of that, there’s this phrase that you’ve got on your “About” page that I really love, about how you kind of value “making modest things consistently well.” Some of the things you’ve written in the last few years are “What Screens Want” and “The Web’s Grain.” These are really beautiful pieces of writing I think, first and foremost, but I think in some ways you’re sort of trying to frame what a web native aesthetic might be in general for web design. It’s been interesting to see how that aesthetic has wound its way through your work. I know you and I have had conversations about things like web fonts and performance and how that’s a very early aesthetic question for you. I’d love to hear a little bit more about that, Frank, and just generally how you think about what the web needs as a design medium, and if maybe that was a question you were asking yourself just while you were working on your own website.

Frank:

One of the reasons that I think so much about what websites should look like, not just in specific terms like, “Oh, I have this client. What should their website look like?” but just in general, what should the experience of going from website to website feel like, it’s mostly grounded in the fact that I sort of see web designers repeating things that we’ve labeled as mistakes before. We did a lot of work in the early to mid aughts trying to iterate to people the importance of semantics and accessibility on websites, and the benefit to users of having consistent experiences across those website and having those experiences be driven by the interactivity of the browser, right? That’s why Flash websites weren’t so great, because every time you hit a Flash website, you didn’t know how to use it. I see us sort of repeating that at this point. There are sort of these marquee websites that are obviously for marketing but there’s a lot of whizzbangery around it because they’re meant to draw attention. But they have some of those fundamental usability problems that I think those early Flash websites had, and it’s really hard for me to look at them and not see them as cumbersome and bloated—and cool, but I find myself looking at them more than actually using them. Maybe that’s the intent, I’m not really sure.

So, that’s kind of one of the reasons why I was like is there an oughtness; is there an “it-ness” or an oughtness? Is there a way towards making websites that feel like they’re websites? I have a pretty good feeling about what that is and it doesn’t necessarily overlap too much with the whizzbangery that gets a lot of attention. So, wanting to really drill down and say, well, okay, what’s the web’s grain? Well, the web kind of wants you to stack things vertically on top of each other and have quite a bit of text. It wants to be fluid, it wants to scroll vertically, and it wants to probably use flat colors or simple gradients because that’s what’s easy to specify inside of CSS, and also you can take those aesthetic rules and stretch them out to boxes of indeterminate shape or boxes that might change shape based on how somebody’s accessing the website or how much content is sitting inside of that box. So, it’s like what is the aesthetics of fluidity? That’s really what the main question is, and a lot of it is dictated by what the tools make easy for you to do.

So, I think that you can make a perfectly great and serviceable website probably with just, I don’t know, 100 to 150 lines of CSS. It doesn’t take really that much. It doesn’t take a lot of JavaScript or anything like that. The old websites from the 90’s, they still work, their fonts just need to be a little bit bigger and they need to set a max width on their paragraph so it has a nice measure. Other than that, you go back and look at a bunch of the essays by Tim Berners-Lee and you’re like, “Actually, this still holds up. I’m not a big fan that it’s in Times New Roman, but that’s what they had to work with.”

So, that’s what’s interesting to me. It’s taking sort of a principled stance as a starting point, honoring the materials that you’re working with and believing that the web has a grain like how a piece of wood has a grain. You can work against that grain, and that creates interesting work that requires a lot of craftsmanship, but for the most part, if you’re building something, you’re going to want to go with the grain because it’s going to be sturdier, it’s going to be easier for you to work with and typically, hopefully, in the process it will be a little bit more beautiful, too.

We had a conversation about web fonts mostly in that, from a kilobyte perspective, they’re pretty pricey, and there’s all of these logistics to worry about if you want a performant website, about how they load and if you want the flash of unstyled text or using JavaScript to put conditional classes on bodies to change the body font after the fonts load and those sorts of things. My question was just sort of like, well, that’s really easy for other people, but every additional step that they need to take is an extra point of fragility, right? So, I’m just sort of wondering is it worth the effort.

Right now, my website is using two typefaces, one is called Fakt and the other one is called Arnhem, and the fallback immediately after that is San Francisco and Georgia. If I take out the web fonts, I like it nearly as much as if I had the web fonts in there. The vibe of the site changes a little bit, but for the most part most of the typefaces are of the same size, so it isn’t like a world of difference changing the typeface to these fallbacks. So it’s like, well, do I actually need those typefaces in there, or would it just be easier and more stable to have those system fonts being used? I kind of waffle on it, I go back and forth probably every single day, and I decided to leave them in because I was like, well, I bought them, let’s use them. But it is sort of like this interesting question whether these additional assets, what the trade-off for each one of these is. Because every additional element you add to a web page, it costs something, you know? It benefits in some way, but it also costs something, and eventually you’ve got to justify the cost, because we can’t communicate the size of web pages before they’re loaded.

Karen:

Frank, this has been fantastic. As we come to the end of our time here, I’d like to ask something that we ask of all of our guests but I think it’s particularly unique for you. What advice do you have for perhaps a young designer, a young developer that is embarking on a career and maybe thinking about the web as a medium or how their work as a designer would adapt to the web’s grain, as you say? What advice would you have for people for what they should do or how they should think about their work?

Frank:

I would say just learn a little bit about the work that everybody else is doing on the project. I think clearly that’s important for the project that you’re working on, but if you can learn about why they’re making some of the decisions that they’re making, you can fold that into the work that you’re doing. So as I said earlier, I think the walls between these disciplines, specifically on responsive projects, they’re a little bit lower than they used to be and they require a little bit more collaboration and better communication. If you can get into somebody else’s mind and sort of understand their values and why they’re making the choices that they’re making specifically, I think you can fold that rationale into your own work and maybe head off some of the complicated bits or address some of the dark spots that typically don’t get thought of until much later in the project, and get to those sooner.

Karen:

Frank, it’s been such a pleasure to talk to you. Ethan and I are sitting here chatting on Slack, like, “Wow, we wish we could just have you on the show every week and have more of you in our lives.” So, thanks for taking a little time out of your day to come and talk to us. I enjoyed it and I know everyone else will, too.

Frank:

Of course! Come see me in New York.

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.