JOHN: Welcome to Greater Than Code Episode 175. I'm John Sawers and I'm here with Carina Zona. 

CARINA: Hi. Our guest is Eric Meyer and he's got quite a resume. He's been blogging for 20 years. He's been a developer for about 30 years on the web. He's been a member of a number of working groups for the W3C and written a number of books. He wants to be modest and tell you that it's only a few, so we're going to go with six. Welcome, Eric. It's great to see you. 

ERIC: Hey, thanks. Thanks for having me on. 

JOHN: Welcome to the show, Eric. We're going to kick off with the first question that we always ask our guests and that is, what is your superpower and how did you acquire it?

ERIC: I think of the extent that I have a superpower, it's the ability to explain things in a way that makes sense to at least most people. I'm not going to say everybody because I don't think anyone is that perfect. But being a communicator, being able to take time [inaudible] concepts and sort of translate them to the audience. So, if it's a group of middle schoolers, I could pitch HTML at their level, and if it's a group of people who have done development before but have never done web, then I could hopefully pitch it to their level.

How I acquired it? I think just by reading a ton my whole life, ever since I learned to read. Just read, read, read, read, read, because that exposed me to a whole bunch of different ways of communicating. And my mother was an elementary school teacher as well, so I probably picked up some of it from her too. 

JOHN: When you were reading, were you sort of looking and analyzing the different ways that people were presenting things or you just absorbed it by [crosstalk].

ERIC: Yeah. It was all absorption. I mean, I'm counting in here, reading when I was five and this was awhile ago, so some of you may not recognize this, but the Time-Life: How Things Work book series, that sort of thing. Here's a thing with a bunch of diagrams and then you go to the encyclopedia on the shelf because this was the era when families had encyclopedias on their bookshelves. And you take it out and there aren't diagrams. There's an article and maybe there's a picture, and then reading fiction. This author describes things this way and this author presents things this other way. And just all of that sort of absorbing it over time. 

CARINA: Eric, you blogged recently about what I think you sort of summarized as having discovered that your old posts go back 20 years and that historically, there's a lot on the web that still exist from even longer than that, that recognizing that kind of legacy capability of the web itself that we need to be thinking more about creating for stuff that can do that, can last for decades, can outlast perhaps even us ourselves. Can you elaborate a little on how you [inaudible] and what we can be doing?

ERIC: As you say, just this past December, I sort of passed my 20 years of my website, meyerweb.com, which basically went online early December of 1999. One of the things I noticed was that when I went back and looked at that post, I have this thing on all of my posts that says how long ago a post was published. The date is down at the bottom, like the actual raw date is down at the bottom but at the top, it will say something like 'published a week ago' or 'published three months ago'. And in this case, it said, "Published 20 years and 5 days ago," even though it was the actual anniversary of the post. It should have just said, "Twenty years ago," not 20 years 5 days ago. I couldn’t figure it out for a second and then I realized the relative time routine that I had written, like 10 or 15 years previously, I had not accounted for leap years. I had just said every years have this many seconds or milliseconds. I'm sure I didn’t write out the number, but I had just said, "A year is this many seconds." Well, some years are more seconds. But I hadn't accounted for that, and so there had been this drift over time which I hadn't really noticed. And at the time I wrote the routine, even if I thought about leap years, I'm not sure if I did. But even if I did, I might have thought, "Ahhh, a day or two, what's it going to matter?" Not thinking this website might still be here after 20 years or 30 years. It might have gone through a week's worth of leap years at some point. 

And that fed into a thing I've been thinking about recently which is that the web itself, the technologies on the web are very long term. We have HTTP1 and then HTTP1.1 and HTTP2 and so on and so forth. But HTTP is now 30 years old. HTML is 30 years old. I feel like [inaudible] of the web is a short term medium, and it's not. We think about our development in six-month or year time scales. We think about our code running in a few year time scales perhaps. Our designs, we figure, were going to get redesigned in a few years. And we don’t really have to think about what's this going to be like in 20 years. But the problem is that we do. And the web itself is actually designed to be that long term. Once you start to get into both what was possible 30 years ago and what happens if you take a current web page and feed it to a 30-year old web browser, there's a remarkable amount of robustness  both backwards and forwards in time. 

Most of the very first elements that Tim Berners-Lee came up with are still supported in browsers today, including a few that probably most of us on this call, let alone people listening to this podcast, won't have ever heard of. There are a few, very, very early [inaudible] that got dropped, but they got dropped within a year or two, and the user got replaced by something else. One of the ones that we actually lost was the H0 element, there was a heading level zero. Now, it's heading level 136 instead of 036. There was also even early on, there was a proposal to highlighted freeze. It was HP and then a number. And it can be an arbitrary number so you could like highlighted freeze 34 would he HP34 and then /HP34. That got dropped early, but there's the element plain text. Plain text is still supported in browsers today. 

JOHN: Remember that. 

ERIC: Yeah. And nobody ever uses it. It's not a surprise because plain text basically says everything after this plain text opening element is literally plain text. If there's mark up, it should just be presented as text. So, you can't close the plain text element like /plaintext is just rendered as raw text. Nobody, and then /body/html whatever else. Such that all gets put in the browser window. But that’s still supported in browsers today, and yet very few people have heard of it. 

Sarah Drasner last year posted something about base href, for those of us who have been doing base href for a long time, got, I don’t know, 2,000 retweets or something. And all the comments were, "Mind-blown, why did I never know about this? Why didn’t anyone tell me about the base element?" And those of us who’ve been around for a while were just like, "They are kids. They don’t learn anything. What do they teach in schools these days?" Actually, the fault is ours. We didn’t tell them. We didn’t pass that knowledge on. 

The technologies themselves have persisted on over a very long time scales. And for that matter, if I take an html page that has a details element in it, details is era 2016 or so, and I load it up in Lynx from 20 or 30 years ago, I can still see the content. I'm not necessarily getting all of the interactive capabilities of the details element, but the content is there because the web from its inception was designed to be robust, accessible in the most fundamental meaning of the term accessible. The information accessible to as many people as possible. And the elements were designed in such a way that if you don’t recognize this element, great, just show the content anyway. That’s a fundamental design principle of the web. And it's operated over what to those of us who think in our usual short term timeframes, it's an astonishing length of time. Thirty years is enough time for somebody to be born, grow up, finish schooling, start a family, maybe switch jobs a time or two. That’s a long time. And yet these technologies are still fairly robust over time. I'm not saying that you could take Mosaic and throw it at a React site and have it render everything correctly, but that’s more of a failing of React or Ember or whatever, or even if it's a bespoke framework, if you're rendering everything through JavaScript and you try to show that to Mosaic, you're not going to get anything. But that’s not really Mosaic's fault. That’s because everything is being rendered via JavaScript which is not a robust language. 

There's a place for it, don’t get me wrong. I'm not here to say JavaScript sucks and we should never use it. I've used JavaScript quite a bit. But those are the sorts of things that we don’t really think about. And I think with frameworks, I say React because it's the most popular one. I'm picking on React specifically here. But the sorts of dynamic generation of content that we do a lot doesn’t keep this long-term, it's not considered over long timeframes. If you’ve had written a site like this where all of the content is handled through JavaScript and you did it in Mootools, and it's still on that version of Mootools that came out ten years ago, maybe JavaScript has broken stuff that Mootools is using since then. The site, which might have had really interesting information stops working. That’s not really a good idea and we should be thinking of the longer terms. Okay, I'm bashing out this code now. What happens if this code is still running in a decade? Have I thought about that? Have I set this up so that somebody in a decade can come back to this code and actually deal with it and update it if necessary, maintain it if necessary. 

In the banking sector, people are used to this. People write Cobol and expect -- well, mine is Y2K. Y2K was definitely a thing. People didn’t think far enough ahead but I think that lesson got learned at that time by the people who are fixing all the Y2K bugs. We were thinking, "Well, is this still going to work in 2038 when the Unix timestamp problem kicks in?" Sorry, I went on for a long time, since we're talking about long times.

CARINA: When you were talking about frameworks essentially doing things that break the web, frameworks have become the dominant way that we, especially at a professional level, not necessarily personal level, are creating the web. And so, that means that essentially we are creating something very long term and arguably disposable. So, how do we within effectively absolutely are going to continue to use frameworks? How do we still create that long term that you're talking about?

ERIC: In the ideal world, you would develop in the framework but deploy with something more stable over long time scales. Because when you go way down to it whatever that JavaScript framework is, is generating an HTML dom and is generating CSS. The browser is not just -- in most cases, the browser is not just like drawing canvass. I'm sure there are sites that do that. But taking that thing that you rapidly develop using your framework and translating it into something that will be more robust over long time scales whether it's static HTML or it's HTML that’s enhanced by JavaScript, whatever that is, that’s what I would recommend because that takes the thing that you're trying to provide to people and moves it to the most stable and robust layer, rather than keeping it in a layer where if somebody has a Nokia candy phone, a feature phone it's called in that industry, which is to say not a smartphone, that they can still get the content if they need it. 

JOHN: Yeah, that’s one thing I like about a lot of the news that excite generation frameworks that are around today for simpler types of sites. They do give you that nice development system where you're not just in notepad, typing HTML tags, but you do render down into something very static and very long lasting. 

ERIC: Right. It's been an interesting movement to see. It seems to be happening, as you say, mostly in personal sites. Yeah, I mean, there are some agencies that are doing that for client sites. If a local bakery needs a site or they want a baking blog, so that it needs to be updated on a regular basis, they're still doing it through static site generators. I don’t imagine Facebook will be moving to [inaudible] anytime soon although that would be super interesting to see how that worked out. But yeah, I would like to see more of that ethic adopted throughout the industry because as you say, you can have this content management system but it all gets rendered down to something that’s more static. And static is often sort of a wrinkle-you-nose word amongst some of our peers. But it really shouldn’t be because static is stable. 

I don’t even know if this is still true, but for the longest time, CNN.com was all static pages. They had a content management system but literally for like 20 years ago, they had, I think it was called Vignette Story Server was their content  management system but they rendered everything out to static HTML which is one of the reasons why CNN became a really popular site for news because it was super fast, and it worked across lots of different browsers. I don’t know if they're still doing that or not. But [inaudible] makes sense. And it actually made sense for them too under peak load conditions such as when huge breaking global news stories are breaking. They could take the home page and manually shave off bytes to get it as small as possible so that they could keep the server up for as many people as possible. 

I get that most of us don’t have the kind of traffic that CNN.com might get, but it's still worth having that as a possibility to say, "You know what? For right now because we just got featured on Business Insider and the entire world is beating a path to our site, it's already as stable as it can be and we can just shave things down to serve as many people as possible." 

CARINA: You earlier mentioned a word that really caught my attention because we try to discuss the human side of coding and you used the word ethic. And I wonder, do you feel like there is an ethical dimension to all this?

ERIC: Yes. I think for some sites, there's more of an ethical dimension than others. I have nothing to do with this site, but let's say I'm managing the site for RAINN. I would definitely feel an ethical responsibility to have that content available to as many people as possible in as many situations as possible because you don’t know who needs that information by the side of a road or in an elevator or whatever situation they're in, where they maybe don’t have a lot of bandwidth, they don’t have a lot of time, they still need that information. There's an ethical motivation there. There's a priority to serve as many people as possible, even if it doesn’t look the same to everybody. It's getting back to that original idea of accessibility in the sense of the web pricing ubiquity over consistency so that many people with as many devices as possible can get to this information. 

If I'm running sort of a less [inaudible] site, there might be less of an ethical consideration. But I don’t think it's completely absent, because this is really what the web is meant to be. It's meant to be information accessible as widely as possible. That was the original design vision. And that’s how all of the technology and it basically has been constructed. HTML, CSS, they're all done with the -- is this backwards compatible? And sometimes, that closes doors and they have kept those doors closed. There have been discussions at times in CSS which I happen to know fairly well where people said, "You know what? Let's just change this thing about CSS. We know it will break old browsers, but people using older browsers need to get updated anyway." Working group has consistently resisted that. I said, "No, we can't break things in older browsers. We need to find another way to do these things so that it won't cause incompatibilities." HTML has that same design principle and I think that we both ethically and within idea towards long term accessibility need to take that same approach. 

JACOB: And there was no [inaudible] school when the web started. That's like the idea of the web. You install a browser and in most cases, one comes with your computer when you take it out of the box. And that’s it. You shouldn’t have to worry about updating anything, installing anything. You just type where you want to go, that’s where you get to go. And like how much of a revolutionary idea that was. 

ERIC: Absolutely. HTTP and the URL, those were kind of, in my opinion, and not just my opinion but I agree with this as sort of the two fundamental innovations of the web that make the web the web. 

JOHN: I feel like there's a sort of a mindset difference between different groups of developers. And I know I've experienced it myself, sort of as a developer in a sort of pseudo-startup type environment. I've certainly had the experience where I spent six months building a feature and the feature may or may not launch. And if it does launch, it may or may not be adopted and then it gets killed off and all the code is deleted within a couple of years. And so, I think that tends to warp my perception of the longevity of the things that I'm building because it could all be transformed, it could all be rewritten, it could be a new platform, it could be acquired and [inaudible] everything in Java.  And so, we don’t try and tend to think in those long term ways. 

I've also had the experience of working on a website for a government agency. And I went back recently and it was as I built it in 2004, that site is still running. It had zero changes, no design overhauls, no functionality improvements, and it's a very different kind of a world between those two. As you were highlighting that need for longevity, I was thinking back on how my thinking process has been sort of warped into a much shorter term way by being in the end of the technical world that I live where things are fairly short term. 

ERIC: It’s understandable. I have certainly written my share of short term code. I mean, the leap year problem that I did. Plenty of other code where I've just sort of slammed it out because [inaudible] right now. I need to do better too. And I think we all do because especially for those of us who started on the web early, it looked literally a new medium. There were things that you could say are sort of like it, but it was really nothing like it. And the way it took off, it always felt like new and shiny and anything goes. This might all be replaced in three years because that’s what we were used to. But we're out of that phase. And you might say the web could not possibly last another 30 years. It might. It lasted 30 years so far. And I don’t see anything on the horizon that looks particularly like a replacement. Maybe if the web does get replaced, it will be something that comes all at once and we'll never see it coming. But we have to make the best decisions we can based on the information we have. And right now, the information we have is the web is it. The web will continue to evolve as it has evolved. It will continue to gain in capabilities. But this is what we have. So, let's get used to it and let's get used to the idea of like you said, I might develop a site and 16 years later, I come back and it's literally unchanged. 

Now, when you went back to your site, was all the information still available?

JOHN: I don’t have a  log into that site, but everything looked like it hadn't changed. Like the backend was probably still doing the same ETL process that was built because this is pulling gate out of government agency databases that probably also have not changed. So, I imagine it's still exactly as it was. 

ERIC: The information was there. You did your job. You developed for the long term, even if you didn’t mean to. And yes, in government settings, that’s a higher priority. I would say in educational settings, academic settings, that’s a priority. But I'm thinking commercial settings too. Amazon doesn’t necessarily need to keep every version of a product listing that it's ever had. If the thing's not available for sale, maybe that should go offline. But Amazon itself should be fully accessible, and I'm sure they do a lot of work for that. And so, it's the same kind of idea for all of our work. Maybe I'm working on the About Page and I think six people will ever look at it, I need to do the best job I can for those six people. Because if I don’t do the best job I can, then I've let those people down. 

CARINA: [Inaudible] back to the issue of accessibility because we love to essentially treat anyone with disability as an edge case, and six people seems like a very edge case. So, it's always difficult to have conversations about how much resources should we put into edge cases, if at all, because it is really [inaudible]. 

ERIC: Yes, Evan Hensleigh I think put this best. Some people have attributed this quote to me, but it's really me just repeating him. He said and I'm paraphrasing a little bit here, but what he said was, "When you say edge case, you're defining the edges of what you care about. You're saying what you care about and what you don’t care about. And things beyond that edge are the things you're saying you don’t care about." 

When Sara Wachter-Boettcher and I wrote Design for Real Life, we reframed this as stress cases. Rather than something being an edge case, it's really a case that’s stressing your assumptions and stressing your work, whether that’s design or development. I think we got that term from [inaudible]. Edge case is an unfortunate framing and it's the one that Sara and I would really like to see people change because again, like Evan said, "These are the things on the edge, the things beyond what I don’t care about." But you said care about that, right? Again, we're getting back to that whole thing of accessibility meaning accessible to as many as possible, whether that means they can get to it from their device, wherever they are, under whatever bandwidth conditions, no matter how old their browser is, if they can at least get the content. It may not be as whizbangy as you developed it with the latest dev tools. They might not get the things that are flying in and out, or little twisty that the accordion collapsed  but they can still read the content. They can still consume that content and act upon it. That’s what's really important. And it's important over more than just the 12 to 24- month window that a lot of us develop in. 

Again, I want to make it clear. I'm not casting any stones here. I'm not saying that people are bad or misguided for that. We all do it. We're short-sighted, yes. But short-sightedness isn't a word we're looking in the short term. Look longer term. You're working in a medium that’s not three decades old and shows no signs of slowing down. So, start to bring that into more of your work. I understand that that doesn’t mean every little widget that your boss tasks you to develop is necessarily going to work 20 years from now. But do your best to make it so that it will work 20 years from now. If you get it wrong, you get it wrong. Nobody can predict what the future will hold. But at least try. The more you try, the more of a practice it becomes. And the more of a practice it becomes, the more people you will serve over greater spans of time. 

JACOB: You said the word whizbangy. What that made me think of immediately is, because we hear that wisdom a lot, like there's the essential stuff and then there's the things that might capture more clicks or keep them on the page longer. But it's not necessarily essential. I guess one thing I'm thinking about is are there ever times where there's a feature that feels like a whizbang but when you get right down to it, it is actually conveying semantic meaning to the user. I can't think of a specific example. I'm just sort of wondering, maybe that border is maybe a little bit fuzzy. 

ERIC: Yes, all these borders are fuzzy. There is no simple [inaudible] line to say, "Here you must develop for long term," and theirs is [inaudible]. It's always contextual. Basically, the answer to any question of should I use X is it depends. Our entire field is a huge series of it depends decisions. When I say whizbanging, somebody says we need a popup chat window. I realize I'm classifying myself as one of the olds here by thinking that as whizbanging. But we need a popup chat window and it should have this animation in it. Okay, great. You can do all that. But the important thing is to make sure that chat works for as many people as possible, even if it doesn't popup in a window, even if it doesn't animate the little 'you're online right now' thing because they're in IE11 instead of Chrome 1137, whatever version of Chrome is out right now. It still works. 

Jeremy Keith has talked about this not necessarily on the long time scales but in terms of move everything to the most stable and most sort of the lowest layer you can. He gave an example of Twitter could completely be done with HTML forms. And then all of the constant real time streaming of new tweets in your timeline, all that stuff that's run through what we call Ajax. You can do that, but that's progressive enhancements. It's enhancement on top of that base layer of text area submit, and order the list of tweets in a static page, let's say. Now, I know Twitter is completely not developed that way but there's arguments that it should be that very basic structure with the extra stuff layered on top, so that if the extra stuff doesn't come in, it still works. And I have occasionally, very occasionally, I actually have screen captures buried somewhere in my mass storage of where Twitter has loaded and failed to load all of its style sheets. Things are everywhere, at least at the time I took it, there was a text area and a submit, and at least once I managed to tweet under those conditions. That's good. That's good development. I don't know if that's still the case. I know they moved to some sort of JavaScript driven framework. You can see it in the fact that all of the CSS class names are basically random character of strings, so that may not still be the case. But it was at the time. 

I also have page doms of when I went to a new site like the BBC and their style sheet failed to load, but I could still see all of the headlines. They might not have looked like [inaudible] awesome fonts, big above a picture. It might have been raw each one with a big picture underneath it that wasn't properly sized and then a summary, but there was a hyperlink. I clicked through to the next thing. There was that basic level of access to content. It wasn't the greatest user experience but it was still there because they had progressively enhanced that. And that's the kind of thing we need to always have in mind, is like, "Okay, this thing. Sure, I can do all of this in JavaScript. I could do every single bit of my site through JavaScript." But what can I push down to the HTML layer? What can I push to the CSS layer? What can I push to what the browser has built in rather than all of the stuff that I'm re-implementing in JavaScript because it fits better with the framework or it fits better with my programming sensibilities, or it just feels cool to do something new. Like, I get that too. That's why I have side projects which are just, I'm going to do some code and it's going to be fun. 

CARINA: You mentioned earlier one of the issues is that we are pretty short-sighted about how we think about use cases, for instance. I've gotten really interested in what we're doing lately with biometrics. And I saw an example the other day that really (a) took me aback and (b) seemed so obvious in retrospect where there's something that's roughly a national identity card in India, and it assumes that you have two irises and ten fingers which is not the case for a bunch of people and may not be the case through their entire lifetime. But in conversation, I probably wouldn't come up with that either. And I do try to think about that stuff. There's so many examples of where we do assume that the real world is essentially like the people in the room. 

ERIC: Yes, which is why it's important to get as many different kinds of people into the room as you can. That's why diverse teams tend to be stronger and then not diverse teams sort of [inaudible]. I mean, have somebody on your team who's 65 or available to your team even if not on your team. Have somebody who's not the same gender or the same ethnicity or the same lived experience as other people on your team, they tend to do better work because they think more of these cases upfront. When you're designing a thing, somebody can say, "I don't have ten fingers." Or, "I know somebody who doesn't have ten fingers." It can be very difficult because we do, we tend to think about the people who are in front of us. That's just human nature. That's how it is. 

And so, developing practices that counteract that as much as possible is always a good idea. I mean, having access to it as diverse a set of effectively beta testers as you can find is always the best. But if you can challenge yourself early in the process of either developing or designing or both to say, "What am I assuming? And what if those assumptions are wrong?" If I'm designing this security access system for a gym, what am I assuming about the men's and women's locker room? Does the gym have that distinction? Other gyms might not have that distinction or do they have more than men's, women's, and non-binary locker rooms? I haven't looked into this personally because I've never had the design of security access system for a gym. But someone who's working on that needs to think about those things. What am I assuming? Am I assuming that there's never a use case for somebody who is not "approved" for this locker room to be able to get into it? Is there a case where have I thought about that. What if my assumption is that every gym even has this distinction? Maybe there are gyms that have unisex locker rooms and does my system account for that? Can it handle that situation? 

I come up with that because this is actually one of the case studies in Design for Real Life that Sara and I wrote about, but not quite what I'm talking about. But there was a gym in the UK, I believe, that installed a new swipe your card to access the locker room system. And the system had been designed -- the people at the gym didn't create it. They outsourced. But whoever had designed this system had assumed that anyone with a title of doctor had to be a man. So, there was a woman who was a doctor who couldn't get into the women's locker room because the system was like, "Your title is Doctor, you don't belong in the women's locker room." Which puts a whole raft of potential problems. One of which is that initial assumption of only men can be doctors but there's also the question of why was the gym asking for people's titles in the first place? And if the gym had never asked for the titles, maybe this never would have been a problem. I don't know because I don't know the details. But again, it gets back to that challenging your assumptions and yes, the membership application form for a gym is a design problem. It's a design exercise. It is designed in some way, whether any thought was put into that design or not. So, whoever made the format had been like, "Well, every form I've ever looked at asked for a professional title, so we should ask for it too." When does the gym ever going to need to know that? I have a PhD and the person on the treadmill next to me doesn't. Maybe that was used as a proxy for if we ever have a medical emergency, it would be good to know which of our members are doctors. Well, don't ask for their title. Ask if they have medical training, because nurses don't have that title and yet -- so, it can fold out into a whole origami nested thing of all these things we have to consider. But again, if you just say, "Well, titles are an edge case," you've now declared what you don't care about, which is what will happen with that information? Or how that particular situation could backfire. 

CARINA: I think when you talked about designing for the long term, that also becomes relevant because if doctors are relevant, people become doctors. It's not an inherent attribute of your life. Someone initially built that form, maybe they gained the title, maybe they're no longer licensed. Either way, you're making some pretty big assumptions about whatever you think is valuable about knowing that they're doctors. 

ERIC: Yeah, absolutely. 

JACOB: Something I'm thinking about now is because we bring this up a lot in this podcast about who gets invited to the table and who has that ability to sort of bring up, draw upon their own life experiences to inform the product better. But if you take the case of the gym, if you brought on someone that was able to make that point, but the gym was halfway built already, imagine what that would cost. What are we going to do? Are we going to tell them to tear down those walls so they can build new facilities for the locker rooms? I think it's also a question of like when people get invited to the table. And if you're going to listen to them because ultimately, a lot of those questions are going to come with a cost because you're breaking assumptions and you're probably going to have to change the system and that's going to come with a cost in some way. You have to be willing to accept the consequences of what's brought up. 

ERIC: Yes, you do. It's always cheaper to identify these things before you start building, of course. But yes, there will be a cost. But again, I guess I would say at least if you've identified as many of these things as you can and figured out what the costs are, you can make a decision about, "These are the costs I'm not going to pay." It becomes an explicit, "These are the situations I'm going to write off." At a certain point, maybe you do have to do that. I mean, I would hope that you never have to write anyone off, but we do not live in a post-[inaudible] world and so these are the decisions that have to get made. But I feel like too many of our decisions are made implicitly and without thought, and without due consideration. And so, we end up writing off people we never meant to write off. 

I guess what I'm coming down to is if you're going to write people off, don't be a coward about it. Do it explicitly. Be upfront about it. It's like, "These are the things that we're not catering to." Not as an ex-post facto like sort of a back-engineered rationalization, "Oh, we didn't think of that. All right, we're writing them off now." No, do it upfront. Own your limitations, own the limits that you are going to set and live with them. Hopefully, if you've done that and you know who you've written off, then over time, you can move more of the people that you've written off out of that category and into the 'now, we're covering that'. "Initially, we didn't support X, now we do. Now, we're working on supporting Y who we don't support yet but soon we plan to. And then after that's done, this is where we're going." Have a road map for those things. Or I guess if you're never going to get to that, at least if someone asks, you can say, "No, we're never doing that." Maybe you say why and maybe you don't, but at least you have an answer other than, "Oh, we're so sorry. We're looking at that," which sometimes feels worse than someone just saying, "Nope, not for you," which I hope we would never say about our sites for someone to say 'not for you' because I have never yet heard an argument that site X is not for person Y that didn't come down to 'I just don't want to have to think about or deal with this'. 

CARINA: I've seen plenty. I think a big one is how we write off people outside of the US, just like with address forms. We're just basically saying if you don't have an address or a credit card that conforms to a standard we're familiar with, walk away.

ERIC: Right. Like I say, I guess I'm okay with that. But again, I'm not okay with it. I think it's better than saying, "Oh, you're right and we'll look into maybe dealing with this." At least you get the straight answer. But again, that's a case of instead of saying, "We'll handle people outside the US," it's, "We don't want to do that." It comes down to, "That's not a thing we want to do."  Maybe legally you can't. Maybe the thing I'm doing is only legally available inside the US. But at least then you can say that. And it's not a case of we were too lazy to do it. It's the 'we are legally barred from doing this for you, we're sorry'. In those situations, it probably isn't a great answer to get, but at least it's a definitive 'this is the deal'. Rather than, "Oh, the form doesn't work because we didn't get around implementing it so that it can handle non-US addresses, and we're not going to because we don't care." 

CARINA: I think we talk about the legality whether it's GDPR compliant only applies obviously within I think it's [inaudible], right? Suddenly, for instance, it has to rethink what is their set of privacy laws when you [inaudible]. They're suddenly going to have to change the way they approach privacy and that can be potentially huge. And then as limitations mean that suddenly now, sites have to serve up something different or choose if they want to serve up something different or a restrictive privacy policy versus one that potentially as much looser. So, when I say you may not legally obligated in all locales to do that, is it really easier in the long term to find the lowest standard in every possible place rather than making [inaudible] standards that meet the highest standards since you're going to have to do that anyway.

ERIC: I agree with you completely. You're usually better off doing that. 

JACOB: This has something that came up at a previous job and it was related to -- there's also the California laws, the CPA which is similar. But the situation in a nutshell was basically we realize that when a user says, "No, you may not put any cookies on my browser," that was breaking all kinds of features, some of which had nothing to do with privacy. And we realize, "Oh, [inaudible] coupled that has some really unfortunate couplings." And we hadn't realized, "What do we do?" How are we going to create some kind of experience that will be minimally useful to the user rather than just like you said, basically like if you accept cookies, then basically just 'walk away, we have nothing for you'. Well, is it really what you want to do? Or do you want to give them something even if it's not the same thing?

ERIC: Right, I would always try to give them something. 

CARINA: Eric, you alluded a couple of times to your book that is probably different than most of the other books you've written. Most of your books are about CSS standards. But you also wrote a book called Design for Real Life and I think you've probably cited a couple of examples that already. Are there some other ones that you feel are really relevant here? 

ERIC: I think everything in the book is relevant here to one degree or another. There was a concept we came up with for a way to try to challenge the assumptions that a team is making which is to have somebody on a project be called the Designated Dissenter. Their role in that project is to look at all of the assumptions and ask themselves what if they're wrong and bring that up to the team. So, if the team is moving towards let's develop this whole thing in React, or other JavaScript framework for them to say, "Okay, what are we assuming there?" We're assuming that the user has a browser that can handle it. We're assuming that whatever other assumptions come from that. And then, what if we're wrong, then what happens? So, somebody comes to the site with a Nokia feature phone web browser, text only line mode type browser, what happens?  And the answer doesn't have to be, "We don't use React," or other framework. But the answer might be, "Here's how we're going to handle those failure states." It's not really failures, but those states that we hadn't necessarily thought about. So, if we're designing -- if someone's putting together a mailing to all of the customers, someone to look at the copy and say, "What do we assume in this copy?" 

Actually, a good example that's not in our book because it actually [inaudible] the book, but Sara Sarah Parmenter had this situation where I believe it's a company called Bloom & Wild in the UK which is not exactly a floral site, but think of like FTD here in the US. Every Mother's Day, people send flowers to their mothers. And so, FTD, if you've signed up, if you've ever sent flowers through FTD and made an account, then let's say FTD sends an email to everybody in their database that says, "Don't forget, Mother's Day is coming. " For many of us, like in Sarah's case, her mother is dead. She got this thing from Bloom & Wild, "Mother's Day is coming up, don't forget Mom," something like that, I don't remember the exact phrasing. And she actually emailed them. She emailed the CEO or did the contact form, whatever, and said, "Hey, you should really think about this. Some of us, this doesn't apply. Literally, there's no one to send flowers to. And for a lot of us, that hurts a lot. It would be so much better if you could just not send Mother's Day stuff to people like that." Or Father's Day, whose fathers have died or whatever. And the next year, they actually did it. Bloom & Wild actually did it. They sent a mail out. Before they sent that out basically to everybody saying, "Mother's Day is coming. But if you would like to opt out of that mail, click here," or whatever it was. They let their user base opt out. Literally, this became an international news story that this retailer -- because it blew up on Twitter. People were like, "Oh, my God. This is the best thing I've ever seen. I can't believe that a retailer, this company has actually thought about people like me." 

And so, a bunch of people opted out. And so, they didn't get that email. Somewhere in the database, the customer management, whatever, the CRM for Bloom & Wild, whatever it is, MailChimp, whatever it is they're using, I don't know. There's a field that's like, "Don't send these people mail on Mother's Day." And maybe they've done the same thing for Father's Day and other days, I don't know. But just that simple sort of human act, the sort of thing that we would do person to person that we never really think about, like business to consumer to say, "Hey, is this a thing that you want If not, let us know and then you won't have to do this anymore." Like I said, covered in the UK Press and the story went around the world, basically, that they had just done the same thing that any of us would have done with a friend who maybe we knew had trouble with Mother's Day because maybe your mother is not dead, maybe your mother is somebody you had to cut out of your life because they were incredibly toxic. There's a lot of reasons why someone might not want to be part of the whole Mother's Day thing or Father's Day thing or whatever it is. And so, if you had someone who you knew was maybe having trouble in their family or whatever it is they hate, "Do you want me to not mention Mother's Day?" That's all they did. And probably it wasn't even that hard to do. Anyone who's had the experience with these kinds of databases like creating a field to say, "This is what this person has opted out of," or, "This is what this person has opted in to," if that's the way you want to structure it. Not that hard to do. It's just a matter of doing it. It's thinking about it and doing it.

And so, to get back to this designated dissenter, when you're putting together this mailing, "Happy Mother's Day," someone will say, "Is there maybe a different way we could approach this because that might not come off well to everyone?" We're not really here in the business of hurting or insulting or alienating the people who have trusted us with their information, the people who we have a relationship with. That's not the same closeness as a human relationship, but we have a relationship here. And while we may be emailing 150,000 people, every single one of those people perceives that interaction as individual. You're communicating at scale but to everybody. Like when I go on Facebook, I'm not thinking to myself, "Here's a timeline that was designed for two billion people." I'm thinking, "This is my timeline. This is what Facebook is showing to me." It is an individual connection from my end. And the people on Facebook send me to think about that, the people on Bloom & Wild, the people at FTD. You and me, when we're designing, the thing we think about is each of this connections is personal to the people that we're connecting with. That's a really hard problem. And I don't know that anyone's particularly cracked it but it's worth tackling because that's a medium we work in. Especially those of us who work on eCommerce or some sort of large community, Amazon or Facebook or whatever. It doesn't have to be that big even if you're only emailing a thousand people. That's still a thousand people you're emailing out to that every single one of them sees that email as a personal experience. It's an individual personal experience. 

And so, someone who's a designated dissenter can hopefully identify some of these assumptions that we're going into. What are we assuming with this piece of copy? Are we assuming a heteronormative scenario or whatever? And if this is going to someone who's not in a heteronormative situation, does it still come off okay? Is there a different way we could do this that handles more people? That was one of the other concepts. 

There's several things in the book. Unfortunately , it's not a very long book, but we tried to pack it with as much as we could. 

CARINA: I find this idea of the designated dissenter really fascinating. I know that I, as a woman, and a lot of other people who are in some sort of marginalized category in tech have this experience when you're the only one on the team. You essentially [inaudible] difference in a roomful of group think become a problem. Speaking up becomes something that's brave and can really affect your longevity. It can become very tense without meaning to be conflict. It's just you're the person in the way of us very quickly moving. So, as much as I really love this idea of designated dissenter, it also makes me think about we need more than one. [Inaudible] designated, that person is going to be that problem person on the team who doesn't even do the work. They're just the person who's always shooting down the work. So there has to be greater diversity so that nobody is seen as that edge case on the community screwing everything up. 

ERIC: And actually one of recommendations we make is that for each project, that role should be given to a different person. It should not always be the same person because then, yes, you're right. If it's always the same person, then everyone else learns to just sort of tune them out. That's unfortunately what happens. That person is always the negative Nancy in the corner. They're going to bring up the thing and we'll have to come up with the rationale why we don't want to do whatever they're talking about and then we keep going. But if it moves around, if it moves from person to person, on this project, it's you and then on the next project, it's John. And then on the next project, it's Chad, whatever it is. That becomes hopefully, over time, if enough people have done that and maybe done it more than once, it starts to become part of the culture instead of somebody's job. Maybe over time, nobody has to be the designated dissenter because everybody is doing that in their heads because they've done it before, depends on your situation. And I know people come, people go. 

We do also recommend if you have someone join the team, do not give them this role on their first project. [Chuckles] Wait a project or two before, so that they can see how it works and also so that they're not -- because when you're new on the team, of course you don't want to speak up at all. It's like super hard to do. So yeah, there's more to it than that. 

But yes, I do and I think we do and the book acknowledged that. If you're the only one on your team of a certain kind, if you're the only woman on your team, you may already be in this role without it having been formally set. So, making it a thing that everybody does helps hopefully dilute that sense of, "Oh well, they're always complaining about whatever we do." Nope, this time it's your job to complain about whatever we do because we need someone to check our work and this time, it's you and the next time it's so and so over there, who's going to be checking our work and making sure we're doing the best work we can do. And they may also be doing design and development but their primarily role in that given project is stress test our assumptions so that we do the best work that we can. And ultimately, do the best that we can. And ultimately, do the best that we can for the people we're trying to serve for the users. Hopefully, it also is the best shot we can for whoever is paying our salary, but it's really doing the best shot we can for the people you're trying to reach. 

JOHN: I really like that because I think as you rotate around various members, each member doesn't have to come into that role having perfect understanding of disability issues and screen readers and gender differences and all the things that they need to care about. But it now becomes their job to find out more about those things. So their job actually becomes expanding their empathy zone into other people and researching and asking people how might this be impacting a group that I have no knowledge of . And so then, each member then slowly increases that zone of empathy so that the whole team then grows in that area and eventually you don't need someone in that role. 

CARINA: [Inaudible] someone in that role. I don't think that should be something that you're hoping to eventually phase out. 

ERIC: That's fair. I think for smaller teams, maybe you could phase it out eventually, although you may well be right. Unfortunately, I've never interacted with someone who's done this over a long enough time scale to find out what happens over long enough time scale. 

JACOB: It might be one of those things where let's do it with the pretending that we could achieve that goal, even though we know that we probably won't. So, it's like let's all try to acquire as much knowledge as we can as if this is something we had to do all the time. But remembering in the back of the head, "No, we'll probably have to assign somebody."

ERIC: Yeah, probably. The nice thing is that hopefully, as someone on a project learns and then they share, "Hey, here's why this is a problem," then everyone else hopefully internalizes at least a little bit of that too. It's like, "Oh, this copy doesn’t work because of these situations." And like, "Oh yeah, I never thought about that. I'll keep that in mind for the future." 

CARINA: A challenge of this designated dissenter is that we're still counting on whoever rolls into that role from project to project or week to week, whatever it is, that they do have a broader perspective. And there will be some people who simply aren't as capable as other people around the room at doing that well. So, that’s certainly a challenge to also be trying to figure out. I don’t have any answer today, but I think there are inherently challenges to still be figured out in that concept. I think the concept is a great starting point. I just think we need to finish working out how to do that in a really effective way. 

When you're talking about death earlier, I was thinking even when you do start to anticipate death, you anticipate in terms of usually user or someone near them and some sort of trauma related to that. But there's also just this sort of mundane number of people in the world [inaudible]. There was somebody who knows preparing a talk at a different subject contacted me and she was telling me that on a dating site, which is not where you're expecting to have this come up, but someone within her broader circle had passed away and it was front page news. She could not get the dating site to stop matching her this person. I mean, she was trying to convince them to take it out altogether, but she couldn’t even stop the matching. And luckily for her, it wasn’t something where it was deeply traumatic. She didn’t have a close relationship but she also knew that there were people there who did and that there was actually no policy or even willingness when they heard this to create a policy was a really big deal. 

Another friend, when his mom passed away, he became executor and that one is a lot more personal. [Inaudible] he simply could not get them to acknowledge that she wasn’t going to be able to fill out this form for them. The company that big, you think that they would be dealing with this more than once ever. I think for some reason, it just hadn't come up, regardless of whether that had been her son or someone who didn’t know her and was an attorney. In some way, this should have been thought about. 

ERIC: Yeah, this should have been. It seems like so many systems are just -- I have to assume it's sort of a human tendency to try to ignore the fact that we're mortal, so that we don’t have a policy for 'my mother's not going to be able to fill out this form because she's dead'. Actually, the day after my mother died, I was at my parents' home and the phone rang. And my dad answered. I remember him saying, "Yeah? She can't come to the phone right now. She died yesterday." And it was like a telemarketer, I don’t remember exactly, it wasn't a friend. And they said, "Oh, I'm sorry," and then hung up immediately. 

I didn’t think at that time, but looking back at it, I think now, is that the first time that’s ever happened to that company? I mean, why do they not have some sort of training or script or something to say, if you find out that someone died, you say, "We’re very sorry. We'll mark that immediately," whatever it is. 

CARINA: I feel like every single site, this is going to come up. Every single app, this is going to come up. And if you didn’t hear about it, it's because someone felt like there wasn’t a way or there wasn’t a form or they couldn’t figure out how to contact you. But unless you have a really tiny amount of users, it definitely has come up whether you heard it or not. 

ERIC: Yeah, a hundred percent. 

JOHN: We've come to the part of the show where we do our reflections which are just the sort of big takeaways that any of us have gotten out of this show. I think for me, there's certainly a whole ton of interesting new ideas. Certainly, the designated dissenter one is a really interesting one and it ties in with, I've been thinking recently about the idea of doing a pre-mortem on a project or you have a meeting about what would have gone wrong if we did XYZ, how all the different ways that it could have gone poorly. And it sort of ties in closely because it could socially wrong rather than technically wrong. And that’s because you didn’t think about one of these things. And they match up nicely. So, that’s really synergizing well for me and my thinking. 

ERIC: Actually, in Design for Real Life, page 98, The Pre-Mortem, which is not our idea. There have actually been studies about this. And Gary Klein wrote about it in Harvard Business Review in 2007, that’s one of the people that we refer to. But yeah, pre-mortems can be absolutely a fabulous way of anticipating problems. The way they usually work is you post a scenario. Things like we've launched a new sign in and six months later, new sign ups are down by 50%. Why? And everyone tries to envision why that might have happened. 

CARINA: First of all, there's so many [inaudible] that we're going to have a lot of big text on the transcript page. I was really struck by this whole conversation that we can have a whole other conversation just on all of this and the tension between that designing for timescale and the whole philosophy of agile and move fast and break things. I mean, that is a really pervasive philosophy throughout [inaudible] particularly and you can't reform systems without deciding that those philosophies are not how we're going to do things. So, I think that’s a whole tricky conversation to have on some other day. But I was just really fascinated by the inherent attention between those. 

JACOB: Something I've been thinking about with this issue of the dissenter. And again, I think we don’t any answer in this today necessarily. I'm projecting like if I was in that position and a question about gender came up, and I'm not any particular expert on gender, of course. I have questions and I want to learn more all the time. But I'm thinking about how that’s like a particularly challenging position to be in. And it's not that it shouldn’t be challenging, but it's a challenging position to be in because if a person were to bring up, "Hey, should we really have just a button for male or female?" And they might know enough to say that that’s an assumption we shouldn’t question, but they might not know enough to be an expert in that area, and have an answer for it. And so, I'll just be thinking about that as like, what do we do, how do we form a poll where people can bring up problems or question assumptions without necessarily having a proposed solution to the problem. I think that’s a cultural thing that I think has merit to it where it's like if you're going to criticize, have a solution to suggest. Don’t just criticize. Sometimes, there are assumptions that need to be questioned even if there's no apparent solution. We want to let that question linger so we can go find an answer for it later. So yeah, that’s a tricky one. I'm going to be thinking about that. 

ERIC: I think the way to approach it is to view the dissenter as not someone who's criticizing, but someone who is stress testing. The same way that a bridge designer stress tests their bridge design to see if it will in fact hold up the weight of the cars or if it will collapse into the river. It has to be stress tested. And the goal is not to drag everyone down, it's to drive everyone to do the best work they can. 

JACOB: Yeah, great. 

JOHN: Great way to frame it when you bring up those issues. 

CARINA: Well, thank you, Eric, for coming on. I think that we all got a whole lot to think about. I certainly, a couple of times, said, "Mind blown!" So yeah, I will also be thinking about this for a long time. Thank you for coming on.

ERIC: Thank you so much for having me. It was an honor.