Episode 19: Implement the Design (w/ Ethan Marcotte)

Hello, this is the Web Project Guide podcast and this is episode 19, Implement the Design. I'm Corey Vilhauer, Director of Strategy at Blend Interactive and co-author of the Web Project Guide. Later we'll be joined by Ethan Marcotte, partner at Autogram and author of Responsive Web Design and Responsive Design, Patterns and Principles. But first, I'm joined by the other multi-time author of the Web Project Guide, Deane Barker.

Multi-time author, Corey?

You've had multiple books just like Ethan.

That's true. That's true. I have. Okay, fair. I'll take it as a compliment then. Here's my beef with Ethan that I will bring up during the interview. Corey, it may amaze you to know that I invented responsive web design.

That is amazing. I don't believe it.

I did. I invented it in my basement 20 years ago. I came up with the idea and I didn't go anywhere with it, but it was mine, and Ethan, he didn't know that I had invented responsive web design, Corey, but he should have.

So this is real the same way that people, they go to church camp, and they have a girlfriend that's in Canada.

Responsive web design is the Canadian girlfriend of my life. Hey, we're going to talk to Ethan about front end development, which I will freely admit I am no good at anymore. It used to be that we did everything, right? You did the back end, you did the front end, but front end has just accelerated so much and fractured so much, right? I mean, when you say, "Well, I do front end development," the only appropriate question after that is, "Well, using what stack?"

Yeah.

Right? React, Svelte, and whatever, there's a million different stacks out there now, and I don't envy front-end developers because I think it is the area of web development that is accelerating and fracturing so fast that it's really hard to keep up with. And I think as a front end developer, you sort of had to back a certain horse. If you sort of got to pick a horse to back, I hope that it's the one that kind of wins the technology race and you don't get stuck working in an obsolete or disfavored technology.

(02:19)
So it really has done some amazing things. And in addition to, what I'm going to call the animation of the front end layer, meaning the activation of it with JavaScript and all these JavaScript frameworks, the proliferation of screen formats and sizes that your information product now has to render on is amazing. Front end design at this point is merely a suggestion. You can sort of suggest that your design looks this way on one particular device and sort of hope that everything comes together to make it look that way, but clearly Ethan is the guy to talk more in depth about this.

It makes me kind of sad because front end was the part I felt like I used to be able to understand. I know you've got HTML, which is how stuff's laid out, and you've got CSS, which is how it's rendered in color, styles, and things like that. And then I was able to ignore JavaScript, which is what I continue to do, is ignore JavaScript. I'll accidentally open up what I think is JavaScript and it's just 7,000 random characters and it's just like, "I don't know what to do here."

That's called Minified JavaScript, is what that is.

Sure. But beyond that, yeah, you're right, I mean, it's gotten to the point where it feels like everything is sort of another layer on top of it and I don't even understand things like React and What was the other one that you mentioned?

Svelte.

Svelte.

I read an entire book on React, and I remember sitting in the Berlin airport when I finished it and I remember closing the book, thinking, "Well, I'll never do anything with that." I have written an application in Svelte and really enjoyed it. And if you look at the State of JavaScript, it's like a survey that's done once a year, Svelte is the big up and comer now.

(04:10)
I mean, React is still kind of the 800 pound gorilla in the space, but Svelte is gaining some ground. But the larger point there is that there's probably, I don't know, a dozen frameworks with some level of penetration in the market. And as a front end developer, I feel like you're expected to know one of them. You're expected to have some understanding of how at least one of them works and which one is that one.

Sure.

And I worked on the CMS vendor side and we have customers that come to us wanting to use a specific front end framework. So as a designer, if you were to engage one of these customers, they know the execution parameters in which they want the thing to run and do you support that? The days of designers working simply in Photoshop, remember those days? We used to cut up a Photoshop?

Yeah. The idea of cut up just is gone. It's not a thing anymore.

And they would send us this zip file of images, at least one of them would be named BGJJGDK, right, the background? Those days are long gone and it's a much more kind of interactive, fluid space. Like I said, I maintain that as a front end developer, you influence how you want it to look, you don't dictate.

Yeah. Well, we will be speaking with Ethan here in a little bit. Ethan is a partner at Autogram who is dedicated to helping navigate the intersection of design systems in CMS, and he also coined the term responsive web design, which we'll definitely talk about. He's author of Responsive Web Design, the book, and its follow up, Responsive Design, Patterns and Principles. But first, the Web Project Guide podcast is sponsored by Blend Interactive, a web strategy design and development shop that's dedicated to guiding teams through complicated web and content projects. Blend's been building great websites for over 18 years, old enough to gamble, old enough to... Actually not old enough to smoke anymore in South Dakota. And we're always looking for our next partnership. So visit us at blendinteractive.com.

(06:25)
All right, let's welcome our guest, Ethan Marcotte.

Thanks, Corey. Thanks, Deane. It's great to be here. Thanks for having me.

It's exciting to have you on here. I'm sorry that you have to be the third Autogram person. You're like the last in the full set. Your chapter came later.

Your priorities are where they should be.

Perfect.

Hold on, let me interrupt. I've got to ambush. I've got to ambush Ethan here. And so Corey tell-

So listen, I have a script.

No, no. Tell the world one thing, Ethan, very multi-talented guy, but tell the world one thing that Ethan is known for.

I am assuming you're talking about responsive web design.

Yes. Ethan is known for coining the term responsive web design. And Ethan, this is my ambush to you, I'm sorry, but I invented it. I invented it because 20 years ago when I was learning JavaScript, I can produce the IP for this, I think, I was sitting in my basement and I created a three column table layout, and I thought, "If I were to dynamically check the size of the window when they resized it, I might show or hide that third column." And of course, you do all this in JavaScript, right?

Yeah, sure.

Use JavaScript to do this. And I learned about viewport, viewable area, I think, was the JavaScript thing I look at. And so I spent an hour debugging this and I could drag the window and that third column of the table, because we were all doing tables back then-

Absolutely.

Would appear or disappear. And I fully remember thinking, "Ah, that's neat. Nobody will ever be interested in that." So Ethan, you wrote on my coattails and bravo for that.

I did, I did. And I'm glad we're able to connect like this, Deane, because the real reason I was coming on the show was to just figure out your address so I could send you some royalty checks.

Appreciate that very much.

Yeah.

Which begs the question, why are you getting royalty checks?

Well, that was a lie in the first place. Yeah, no, it's good to be here. I've always been deeply uncomfortable.... Folks would introduce me at conferences or on interviews as the person who invented responsive design, and I always talk about it as coining a term, because there'd been folks who'd been doing window aware or viewport aware experiments for a while. Cameron Adams was an early inspiration for me where he was swapping in different style sheets based on the width of the window. And it wasn't until media queries became a thing, and at the same time, the mobile browsers were becoming a thing that I was like, "Hey, wait a minute. Maybe there's a native way to do this."

So Ethan, for those who might not necessarily be deeply versed in the details of web development, explain the concept of responsive web design.

Yeah, thanks, Corey. We only have an hour, right? No, I'll try to do this at a high level but the web for me, at least, has always been really interesting because it's a completely flexible design medium. As soon as I create a webpage, I have no control over how or where somebody's going to be viewing that webpage. That could relate to the device that they're using. They could be using a laptop, computer, they could be on their phone, they could be on wifi, they could be on spotty 3G. And there's just a tremendous lack of control that I have as a designer over the experience that I've built.

(09:40)
So responsive design was basically something that I coined to basically argue that we should be creating flexible device-agnostic experiences, that we could create something that doesn't have an ideal width or height, but then we can use some technical pixie dust from the CSS specification to allow us to reshape our designs in intelligent ways so they can basically respond to the changing shape of a browser window or a device's display, kind of like what Deane was doing with JavaScript back in the day. So that's responsive design in a nutshell is kind of embracing the flexibility that's at the heart of the web.

I remember when I first started learning HTML, this would've been 1987, 27 years ago, 26.

Yeah, same team. Nice.

Notepad, Internet Explorer 2, I remember I went over to my friend's house and I'm like, "Oh, that thing's supposed to move. You clearly only have Internet Explorer 1," because they didn't get animated GIF support until Internet Explorer 2. So this is way back in the day, Notepad, Internet Explorer 1. And I remember being wildly frustrated, "Why can't I just put this thing in that spot?" Because I had no concept... Especially back then. I had a 15-inch CRT Gateway 2000 monitor. I had no concept of... The browser was always full window and-

Totally.

Everybody had 15-inch monitors. I mean, only super wealthy people had 17-inch monitors.

Totally, totally.

And we had absolutely no concept of the web needing to be flexible. And I couldn't understand, "Why can't I just do this like Microsoft publisher?" Right? I'm going to put this thing right there. It reminded me, of all the world, when in Microsoft Word where you move an image and everything completely changes and you just say, "Why can't I just put this thing right there?" Like Microsoft Paint. And it would be years until that actually became a necessity. I still remember checking out front end designs, like, "Does it work on Web TV?"

Yeah.

"Does it work on two other browsers?" But it would be years before responsive web design really became a necessity. And what we were kind of talking about earlier is it is interesting that in any new technology, there's kind of a gradual growth of a technology because innovations go into innovations go into innovations. And then at some point, somebody names it.

Right.

And the person who names it sort of gets to the claim to it. And you see this in the CMS space. Headless CMS has been around forever, but somebody gave it a name in 2013, and here we are.

Sure. Yeah. Yeah. No, that's great, Deane, because I'm really glad you mentioned that long tale because the thing that really kind of inspired me about thinking about the web more flexibly was something I read back in the year 2000, this article called a Dao of Web Design, where this guy, John Allsopp, was basically arguing that, "Yeah, we're so focused on these 15 inch displays that are rooted to desktop machines that we're sort of forgetting the fact that these things can be viewed on any size screen regardless of where they are." But mobile browsers didn't exist back then. The technologies we used to build websites were basically stones and wood that we're banging together. And it wasn't until people were literally untethered with mobile devices and technology matured that I could propose something like responsive design. Things had matured to a point where we could capitalize on something that John Allsopp was writing about, God, 11 or 12 years before I even coined the phrase. So yeah.

I've always found that there's kind of a psychological, emotional aspect that comes to this because you always want your design to come off like it is in your own head. And I always felt like there's sort of a humility of letting go and understanding that-

Absolutely.

Different people are going to have different opinions and it's not always going to be the way you dreamed it.

Yeah. I think that's a really beautiful way of putting it. And I think a lot of organizations just frame this, the topic of the podcast, sort of struggle at some level because things like front end performance, building a fast, nimble website, or that's usable by folks who may not browse the web like I do, who might have different technologies to the web, those are things that are outside of our expectations about how the website's supposed to look but those are still our users. The folks that are on a spotty 3G connection or who may not see the screen like I do, those are still people that we're trying to reach with this medium. But still, it's like those are expectations that we're not really talking about during the design and implementation.

I always felt like alternate representations were an inconvenient truth of web design. For a long time, we knew people were going to looking at a phone, but we really would rather they didn't.

Yeah, absolutely. In a lot of ways, I think that's a process problem more than an interest problem. We're sort of so focused on implementing a design that represents what we see in our mockups without thinking about some of those other modalities that we need to account for when we're actually building and shipping this interface.

Hey, let's talk about a bit about the role of the front end developer. I came from a day where HTML, the actual rendering, was something you did server side. You delivered rendered HTML to the browser. And so it was really done by the server side developer. In a CMS implementation, the person who implemented the CMS would also do the HTML. And the HTML was just the additional thing you had to do to get stuff out the door. That has been utterly turned on its head in certainly at least last five years, maybe last seven years. And now front end is fundamentally its own discipline and I maintain is rapidly becoming a more complex discipline than backend development. What do you think about the changing role of the front end developer? How has this changed the dynamics of the industry?

Yeah, that's a great question, Deane. I think front end development has gotten practically more complicated than when I started. And I've always thought of myself as a designer who sits between design and front end. I love writing in CSS and I love mucking around at Figma or Sketch. But folks like Chris Coyier have sort of talked about this long, gradient smear of front end, that there are folks that sit closer to the server side part of the equation where they're actually focusing on building templates and business logic and then there are folks who are on the "front of the front end," who are really thinking through front end performance, they're thinking through accessibility. They're actually building the interface with CSS or some other client side framework. And that's something that just didn't exist 10 years ago or when I started. And it's really been interesting to sort of see that mature.

Sometimes I wonder, this is going to be super cynical and I apologize in advance, but I wonder how much better off we actually are. I mean, if you go out to Wikipedia, Wikipedia arguably has the most content focused design you're ever going to find anywhere. I mean, they have obviously a very narrow charter in what they have to deliver. Somebody once said, "If you shut off the CSS and JavaScript on a website and it gets easier to read, that's a problem."

Yeah, yeah. I go back and forth with how optimistic I am about the progress of the medium. There's this nonprofit called WebAIM, they do advocacy work around digital accessibility, and they publish great guides and tooling and resources around just promoting best practices to making the web more accessible. Back in 2019, they started doing this thing called WebAIM 1 million, basically an automated accessibility scan of the 1 million most popular homepages across the internet. And things are bleak, man. They're reporting out from this massive dataset how the most popular parts of the web are actually broken for a lot of people in pretty fundamental ways, like images missing alt text, heading levels being skipped, which if you're using the screen readers, it's an incredibly important navigation aid. And they've been repeating this project year over year, and they've been seeing incremental improvements over some of these things, but there's just a lot of work to do. So yeah, sometimes I'm excited about the opportunities to make things better, but sometimes I'm in the same boat as you, I think.

So Ethan, what is a project manager? What does somebody who might not be in a development role need to know about all of this stuff? And maybe largely what do they need to know about the philosophy behind how to make decisions on these types of things?

Yeah, that's a great question, Corey. Front end development I think is where the design process starts to actually show what the user's going to be interacting with, what your audiences are going to be interacting with in their own devices and browsers. And I think that that's something that has some pretty significant ramifications on the health of what you're going to be shipping basically, how well it's going to perform for your business, how well it's going to perform for your product. And the technological choices that get made are going to shape that as well. That could impact the performance, it could impact the accessibility, and it can also be an opportunity to sort of smoke out some points where the design part of the process may not have accounted for things that actually are going to be shown to somebody when they're actually using a mobile browser or a desktop browser.

(19:18)
So I've always thought of about front-end development as an opportunity to continue the design process. I've worked on some large scale responsive redesigns where there were things in the mock-up that just didn't really sort of anticipate how something was going to perform on, I don't know, let's say a new weird tablet that shipped last month, because that's the thing that happens sometimes. And so we just had to kind of prototype some ideas in HTML and CSS to kind of figure out some opportunities for how this design might perform under certain circumstances. And then we could take it back to the larger group and have a conversation about, "Does this feel appropriate for the design?" And riff with the designers on that. So I think organizations that can see front end development as an opportunity to vet your design assumptions and continue the design discussion, if need be, they're always set up for success in my experience.

Does this kind of get us closer to the concept of, I guess, what's now called the design system where you're moving away from designing a mock that might be fit to a specific width and now you're just looking at developing a consistent set of design elements?

Yeah, I think so. I mean, I think every good visual designer that I've worked with, every good interface designer, product designer, they're always thinking in a systematic way. Front end development is where that system, I think, starts to get formalized in a lot of ways. And usually through, at some point, the creation of what's called a pattern library or some sort of array of interface components that, these are the little tiny bits of design, little bits of HTML and CSS that we can then stitch together to make pages for our products or for our users. So I think that's the first step in creating a design system. And that does tend to start in front end development.

One of the struggles that we would constantly run into a Blend when I was there, and Corey's obviously still there, is we would get wireframes, sometimes we would be delivered wireframes from a client, they would want us to implement these, or sometimes we would generate wireframes for a client. And what you need to differentiate on any wireframe, is this wireframe suggestive or literal? Is this wireframe exactly what this page is going to look like all the time or is this just an example of how it might look in one particular instance? And this goes back to a design system, because if it's literal, then you design. If it's suggestive, then... I mean, tell us the process you go through to kind of piece that thing apart.

Yeah, no, that's great. I love that. Hearing you talk about suggestive versus literal, kind of reminded me, I worked on the Boston Globe, launched a responsive site back in 2011. I think that was the first large scale responsive redesign. And for the client leads, basically we did design reviews where we brought a literal sack of devices. We were never projecting comps up on a screen, but we were basically handing out iPads, iPhones, Blackberry 4s. The people who got the Blackberry 4s were never very happy, but-

Those people you didn't like.

Yeah. Yeah, exactly. Exactly. Now we did try to distribute-

Were there any fridges?

Oh man, someday I'm going to actually see an internet connected fridge and all my conference going years are going to finally pay off. But yeah, I mean the thing about that that was helpful was it was like up until the point where we'd been implementing the design. Before that point, they'd been reviewing wireframes and comps, these pictures of a website, and getting a bunch of different devices into stakeholders hands was really helpful because it reinforced the fact that their readership was made of hundreds of thousands of different kinds of devices and there was no canonical view of the design. Even somebody who was going to be using an iPhone necessarily wouldn't be seeing the screen as I do. They might be using voiceover, for example. But it was helpful in just kind of reinforcing the fact that somebody's going to be looking at this on a small screen or a mid-screen or a wide screen. This is all still that one product that we're trying to build.

(23:33)
But, Deane, to your question, I mean the part of breaking down a design, I mean it really just starts with a visual catalog, looking at a page, looking at multiple pages side by side, and sort of seeing what the common elements are. Masthead, footer, content, well, those are pretty easy. Different headline styles that might get reused across the site, different form styles, different image crops and dimensions, those are things that need to be cataloged and standardized on. And it's really just a simple process of breaking something down visually and then cataloging it and how I approach it.

In general, how do you think that overlays on the underlying content model of the CMS? And the reason why I asked this is because I, at one time, naively thought and still do blissfully ignorantly think that design system overlays should have overlaid perfectly on a content model. I was about to write a blog post once that said, "Your content model is a design system." And right before I was going to start that somebody, and I can't remember who, wrote a blog post saying why your content model should not be your design system. So if I have an underlying content model independent of any presentation, does that inform the design system at all or are they totally independent?

Yeah, man, Deane, well, I hope you write that blog entry someday because I would've love to read it because I think by and large, most product teams that I've worked with over my career are kind of removed from a lot of the decisions around how the content is structured. Jeff Eaton, one of my partners at Autogram, likes to talk about a lot of interface components that end up in design systems are really just kind of treated as rectangles that we're going to put stuff into. And there's not necessarily an understanding of what that stuff is. There's some assumptions around, "Okay, well, we need to support internationalization, so we might want to start dropping in some German strings to really stress test how well this component handles sort of extreme levels of content." But some of the decisions making that get made higher up the stack, further down the stack, I'm not sure what we're talking about, tend to not be part of the conversation. So yeah, I think absolutely. I think the closer you can bring those two disciplines together, the more robust the design system's going to be.

I have to point out that you mentioned stress testing with German, and I know what you meant, but why don't you explain to our listeners why you stress test with German?

Sure. Yeah, glad you called that out. But basically a lot of German words tend to lean heavily on compound word construction, they tend to be much longer. And so if you're designing a really beautiful homepage, say all of your article teases just have three word article titles, you want to maybe account for article titles that are going to be significantly longer, or if they're going to appear in other more verbose languages than English, including some other languages that can smoke out areas where your design would break in unaccounted for ways. And I think by and large, front end development is about finding ways that your design is breaking or will break when it's dealing with live conditions in the browser, whether that's different kinds of languages or a slow network connection. It's about stress testing of the design.

Let's talk about that for a second. You mentioned slow network connection. Let's broaden our view of accessibility for a second, because we normally think about accessibility in terms of people who are physically disabled in some way, but there's been some arguments lately that I've heard about accessibility as a business imperative just to increase the target audience because there are many instances where people are temporarily disabled or impaired. For instance, I was just in Chicago and I took the blue line into the city. No chance in hell I was going to hear the audio of a video while I was on there. Subtitles, very, very helpful. And then you mentioned slower bandwidth. I've had conversations with Scott Hansel and his wife is Zimbabwean, and so he spent quite a bit of time in Southern Africa where bandwidth connections are very, very low. Now these people are not physically disabled in any way, but they are infrastructurally disabled. How do you think accessibility plays into kind of a broader scope in that?

There's this really fascinating read in disability theory that I'm glancingly familiar with, but that the term disability is about something that's being done to a person by the built environment, that somebody is being disabused of their ability because something didn't account for their needs. And that does have real severe implications for folks who do have physical or mental impairments. But I think that extends to the way that we build websites in a lot of different ways because... So just for example, I mean, I'm speaking to you folks on a fairly robust fiber connection. We've got a wide screen display. I've got a laptop... Oh man, it's like three years old probably, but it's fairly new. So the way in which I browse the web is pretty good. But the trick that I think anyone can fall into as a digital professional is thinking that my view of the web is representative of everybody's view of the web, that everybody's going to enjoy a fast internet connection or be able to download these 10 megabyte, high res images that I'm putting on my homepage.

(29:06)
And I think it's about asking yourself, "What happens if somebody doesn't browse the web like I do?" And I do think it's important to think about slow bandwidth as one of those potential failure points. And if anybody's ever tethered to a 3G connection on their laptop in a busy coffee shop, that doesn't always work out so well, or used airplane wifi. I'm putting air quotes around both of those words. So yeah, I think it's absolutely important to think about that unaccounted for edge case, which is more common than we tend to think of, and build up from there.

(29:44)
So to your point, one of the things that when I was an independent designer working with organizations to implement this idea of a performance budget where that might be, let's say, a webpage has to render in a certain amount of time over a certain kind of network connection. And that's something that we would define at the beginning of a project and then carry through through research, through prototyping, and through visual design, and finally to front end development is something that it's like, "Okay, this is how we measure success on this project because this is going to actually impact our users."

Ethan, if the entire sort of team is... I mean, obviously there's a need for the entire team to focus on accessibility, to focus on performance, but who do you believe is in the best position to lead those discussions and drive those initiatives?

Corey, I mean, as high up as possible, frankly. I mean, I do think that that's something that has to be led by the business. I think the reason accessibility and performance on the web in general is so dire is because it kind of relies on individual contributors, front-end developers or individual designers to kind of care about it. And that doesn't really scale all that well. And inevitably, I think businesses are going to... There's going to have to be some sort of evaluation about how we measure success on this project versus, "Okay, well, this thing isn't actually accessible," or, "It's taking too long to load." There's always going to be that inflection point of deciding when and how something needs to ship. And if the business doesn't actually put its thumb on the scale and lead with, "Yeah, it's important to us as a business to make sure that our products are as accessible as possible or as performant as possible..." That's where I think it really matters.

Clearly, we would hope that organizations would address accessibility just for the human aspect of it, but I'm wondering if-

Yeah.

Corey's laughing. I wonder if there's an approach to put more of a business-

I love that cackle, Corey.

Well, we've seen it.

I mean, organizations think with their pocketbook, and I wonder if we're to the point where maybe there needs to be a more mercenary capitalist spin on accessibility in terms of just the size of the addressable market that you can approach by making something more and more accessible.

Yeah, that's one of the challenges I think that the technology industry's kind of had since the beginning. When I first started on the web, the business case for making accessible product was search engine optimization. There was a line that was tried out frequently, that Google is your most popular blind user because they're coming to a website, they care purely about structured content on the page, and so making sure that it's as fast as possible and as marked up as semantically as possible was kind of how we tried to push that forward. That didn't necessarily land successfully given where we are today. But yeah, I think it's a great question. I do think that that's something that we've always struggled with as an industry. And there are some countries that have actually tried to encode making accessible products in legislation or regulation. There's some European countries that mandate businesses that provide a public good have to actually provide WCAG compliant interfaces, which we do not have in the United States of America where I'm speaking. But there's an opportunity there, I think, too.

I remember I read, I believe, it was Mark Pilgrim's book, Dive into Accessibility, probably 15 years ago. And it really changed how I looked at front end development. The one thing I took away from that book is that the web largely has all the features of accessibility built into it and always did, we just circumvent or ignore them. And I always felt that making something accessible is a process of just going back and using the features that already exist. And this leads me to a broader point. I'm wondering to what extent front end designers who aren't doing accessible websites resent the need to provide accessibility. I'm thinking about the auteur theory of filmmaking where you have some filmmaker who wants to do something incredibly avantgarde and cutting edge, but the producer says, "No, you have to dial this down so audiences in Peoria will like it." No offense to Peoria.

Yeah.

I wonder if we have front end developers that really want to do some amazing things and they see accessibility as an impediment to that and how do we cross that Rubicon?

I think there's some of that. I do think that there are some folks who are really interested in innovating or doing really flashy things and then being told that, "Hey, that beautiful, really compelling animation that you've designed is actually triggering motion sensitivities in a lot of our users, and we need to think about ways to rethink it." I think that there can be some of that, that there's a resistance to making things less beautiful. By and large, at least in my work, and I'm not an accessibility specialist, but I'm just a designer who cares deeply about it, the teams that I've worked with, they've generally been really fired up about learning something new about the medium they're building for, that they're interested in making things more broadly accessible and didn't realize that the way that they were building, let's say, a carousel component or a dropdown menu could be made just basically visually the same, but be made in a way that's more accessible to folks who use a keyboard to navigate the web or some other sort of assistive technology.

(35:35)
But there's always going to be a gap. I mean, we're all busy folks. We're all trying to ship things, we're all trying to meet deadlines, and there's always going to be that tension between doing things the way that I know how and getting things done on time. And that's why I think having some sort of higher level thumb on the scale from the organization can really help encourage that kind of thinking as well, making the space for folks to actually build things the right way. And to bring things back to the design system discussion, I mean, I do think that that's a big selling point for a lot of teams for creating some sort of repository of interface patterns because it can give teams the opportunity to build accessible patterns that theoretically the entire organization can use. So take some of the guesswork of building some of that stuff out the right way. In theory, at least, it'll make for more accessible products.

Ethan, this all rules. What are you working on these days? What do you want to pitch?

Oh, man.

Again, like we said earlier, other than the fact that Tears of the Kingdom comes out in about four days from the recording here.

Yeah, I will be unavailable this weekend for anybody who emails me. Yeah, that's on my radar. But otherwise, I am happily working alongside my good friends, Karen McGrane and Jeff Eaton, at our little consultancy called Autogram. So we're available online at autogram.is. This is where I would normally talk about my Twitter account, but I don't really use that anymore. So I guess the best place to find me online is my website, ethanmarcotte.com.

Awesome. Well, Ethan, thanks for joining us. It's been a pleasure to have you on.

And I will forgive you for stealing the responsive web design. I'm working on my forgiveness. We'll get there.

All right. Well, thank you for the forgiveness. Hopefully we can hug it out at some point. But yeah, this is a real pleasure. Thanks for having me on.

All right, we're back. Ethan is one of the nicest and kindest people I've ever met in my life.

He is, and he was very gracious about admitting to stealing my idea, which I appreciate. That's good for him.

I remember, this is what I know, and I think you alluded to it, but you didn't fully bring it up, there was a time when you would, and you probably still say this, but you were convinced that front end development ruined websites because it moved it away from white background, black Times New Roman texts, blue underlined links.

I have said this before, I have absolutely no design talent. If I were to open Photoshop, Adobe gets notified and they send someone to my house and they're like, "We talked about this. You're not supposed to do this." But yeah, I'm a very kind of simple... I'm big on content consumption. I love to read. I hate anything that gets in the way of reading. So I always maintain white background, 12 point Times New Roman and bright blue underlined hyperlinks. That's really all I need. The kind of reader style... When you go to a webpage and you press a button and it strips out all the styles and makes the site reader friendly, that for me is kind of like the default.

(38:42)
And if you go to my own website, deanebarker.net, you will see that my web design skills are on display. On that website, you can see that I have absolutely zero talent whatsoever. So yeah, I'm big on content consumption. I'm big on just raw... But I understand, designers exist for a reason. I get it. Designers have to exist, and we spent a lot of time with Ethan talking about accessibility. And obviously what Ethan is known for and what Autogram is known for is design system planning and execution, which I think is becoming more and more critical.

When you look at the lifespan of a designer or maybe the lifetime of a front end developer, I feel like you're learning the basics, then you go into a period where you over-design everything, and then you end up coming back and realizing, "Well, actually the simple design is something that isn't..." You're using your front end development skills, you're using that implementation of the design to accentuate certain things rather than to decorate certain things. And an example is Ethan mentioned his site, ethanmarcotte.com. I mean, you go to it, it's simple. It's simple, it's beautiful, but it's a simple site. It's easy to read. There isn't a bunch of stuff on it. It's just built in a way that's fast and accessible.

I am going to demonstrate my incredible level of culture by giving you a quote from a French guy, and I don't remember who he is, but he said, "Perfection is not when there's nothing left to add, but when there's nothing left to take away." And I think that vastly applies to front end development. If you can keep it absolutely as lean as possible and you can increase performance, you increase accessibility, you can increase content comprehension, there's so many aspects to that. And I think you're right, Corey, that in the development of a designer and kind of the maturity of a designer, they go through this period where they just try to add and add and add and add and add, and then once you kind of crest some level of career experience, you start to take away and take away and take away and take away. And your favorite thing is a red pen and a wireframe where you just start crossing things out because they're just not going to fly, and that's just a product experience. Ethan was great.

Deane, I'm going to go through the big spiel at the end. I'm going to give you time to find out who said that quote.

Okay. I'm going to go on mute because I have been told my keyboard is loud, so I'll be on mute and I'll find that out.

All right. Well, a big, huge thanks to our guest, Ethan Marcotte, who is absolutely, again, one of the most open and kindest people I've ever met. He's author of two books that are available through A Book Apart. One of them is Responsive Web Design, and the other one is Responsive Design, Patterns and Principles. You can also visit Autogram at autogram.is, and you can visit his personal site at Ethan, E-T-H-A-N, Marcotte, M-A-R-C-O-T-T-E.com. The web project guide is a product of Blend Interactive, a web strategy, design, and development shop that builds websites and guides teams through complicated web and content problems, including all of your front end development needs. We are dedicated to making great things for the web, and this is one of those things. This is episode 19 of the Web Project Guide. Only five more episodes to go, which also corresponds with chapter 19 of the book, which is called Implement the Design.

(42:06)
You can read the full text of this chapter at web project.guide/implement-design. I was at Confab last week. I started equating buying the books, like the book table in the back, the Magers & Quinn book table as the merch table. So if you want to buy some hot rock and roll merch, you can go to order.webproject.guide and get yourself a physical copy or a digital copy of the book. Otherwise, as always, it is available at webproject.guide. Also, if you like what you hear, leave us a review, give us five stars, give us a positive review on Amazon. We love all of that. It fuels us because, again, like I said last month, we have a need for validation. And with that, thanks for joining us this month. What'd you find, Deane? Did you find it?

The quote was made by a man called Antoine de Saint-Exupéry.

The guy who wrote The Little Prince.

Oh, did he?

Yeah. Oh, you did figure out who wrote-

Yes, the Little Prince. He was a French writer, poet, journalist, and pioneering aviator. He lived from 1900 to 1944 where I believe he disappeared in a plane crash of some kind. So he was the one that made the quote, "Perfection is not achieved when there's nothing left to add, but when there's nothing left to take away." There you go. That's your level of culture for the day, Corey.

Perfect. All right. Subscribe, share. We'll be back next month to talk backend development with Optimizely's David Knipe, and until then, go do amazing things.

Good luck.