Transcript

Jen

This is The Web Ahead. A weekly conversation about changing technologies and the future of the web. I'm your host Jen Simmons and this is episode 105.

I first want to say thank you so much to today's sponsor, Media Temple. I'll talk more about them later in the show. And I want to say thank you to Pantheon for powering The Web Ahead website — pantheon.io. Also to CacheFly for delivering the audio files to you. Bandwidth for the CDN has been provided by CacheFly. The fastest, most reliable CDN in the business — cachefly.com.

This week, I'm coming to you from the hotel for An Event Apart. My guest today is Aaron Gustavesen. Hello Aaron.

Aaron

Hey, how's it going, Jen?

Jen

Good. It's weird. It's always weird to me when I can see the person who is on the show.

Aaron

I'll make funny faces at you while you're talking.

Jen

Yes. I will stop looking at you then. [Both laugh]

There's a theme of the show that comes up over and over and over again. We're always talking about this. It's so obvious; of course everybody always knows about it. We don't even need to do a show about it. Like, duh. We're going to talk about it today, though. Because I shouldn't assume that everybody understands. I've realized that we need to stop and just talk about progressive enhancement. What is it? Why does it matter? What are people talking about when they refer to progressive enhancement? "This new CSS thing is awesome, you can totally use it because of course you're going to use progressive enhancement." They move on to tell you about the CSS thing, without filling in the basics or the gap or the, "Wait! What was that? Progressive what?"

I thought Aaron would be the perfect person to come talk about it.

Aaron

[00:02:05] Awesome. I'm always excited to talk about progressive enhancement.

Jen

You wrote a book, Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement.

Aaron

Indeed. That one came out in 2011 and the second edition will be out this December.

Jen

Nice. This is a good book. I think if people listen to this show and think, "Yes, I want to learn more about that," this is a good resource to really wrap your head around, "What are people talking about?"

Aaron

I hope so.

Jen

Honestly, when I first saw the title, I thought it had to do with responsive design. People were debating responsive vs adaptive: "You should be fixed and changing. Responsive is fluid and changing." I thought this book was going to be about that, which is why I bought it. But it totally wasn't about that. It's about progressive enhancement.

Aaron

[00:02:51] Right. The whole title came about because I was looking for a way to differentiate a book about progressive enhancement from designing with progressive enhancement, which the Filament Group had done a couple of years earlier. I didn't want to cause any confusion, because I think that's another fantastic book.

I was trying to figure out, "What's another way to say 'progressive enhancement'?" Because progressive enhancement is not very sexy of a word or term or phrase. Not that I was looking for something sexy, but it sounds very clinical and not all that interesting. If I wasn't aware of what progressive enhancement was, I'm not sure I would pick up a book that was called, Progressive Enhancement: The Definitive Guide or something of that nature.

We were throwing around a bunch of potential titles for the book — this was after it had already been written. I stumbled on this idea of thinking of it in terms of a web that adapts to where it needs to go. The term "responsive design" had come out while I was writing the book. I didn't talk much about responsive design in it because I hadn't come to terms with what that meant in terms of the progressive enhancement continuum. So I didn't really address responsive design in it. I talked about creating adaptive layouts. A lot of people say "adaptive web design" when they're talking about having layouts that adapt. But when I used the term "adaptive web design" it was more about an entire continuum of experience, ranging from pure text all the way up to some sort of high-fidelity experience involving JavaScript and other stuff. It didn't just have to do with layout.

Jen

Right. Let's talk about progressive enhancement. What is it? How do you define it when someone says, "Explain to me progressive enhancement."

Aaron

[00:04:56] It's about creating experiences that don't have technological restrictions. There's no specific technology that is required beyond the ability to connect to a website and potentially display text. Displaying text is becoming more and more of an ancillary experience. Being able to connect to a webpage and be able to expose the content of that webpage in some way to a consumer. At the very baseline of our experience of the web, back in the day, that was pure text. White text on a black background.

In the future, that may be a headless experience along the lines of Amazon's Echo or Siri. Interacting with a website purely via your voice and literally having a conversation with a company or with an individual and their blog or something like that. That kind of future of voice-based stuff is pretty exciting to me. It's very cyclical in terms of going back to the roots of experience, to the roots of language and conversation and thinking about UX in a different way that doesn't involve design.

Jen

[You mean] visual design.

Aaron

Visual design, yeah.

Jen

When I think about progressive enhancement, I always think about, "We're making a website..." — well, you could have a parallel world version in the app world, but I don't think about apps very often — we're thinking about the web. Thinking about progressive enhancement… we have a website. When the webpage renders, the HTML totally makes sense. The order of the content is in a really good order.

If for some reason all a person ever got was HTML, that's going to be really solid. Then we're going to add CSS to it. When we add the CSS, some browsers are going to read all of the CSS. Some browsers are only going to be able to read most of it or some of it. Usually it's most. [Although] something crazy might happen, like the connection drops. There were four CSS files and only two of them loaded and the other two didn't load. You never really know what's going to happen.

The one thing we think about a lot is, "These people have Chrome, these people have Firefox, these people have Safari on iOS, these people have whatever. Oh, we didn't think about those people, because they have a whole bunch of browser that we've never heard of, like the UC browser or Opera Mini."

What we do obsess about it is IE — IE6, IE7, IE8… So, Internet Explorer 6. Maybe you have several thousand people using that browser. What kind of experience are they going to have? If you write the CSS in such a way that it's going to work even if [the user] has an older browser — it's going to render the CSS that it understands. It's going to ignore the CSS that it doesn't understand — because that's how the web works. That's ok. That's fine. The browsers that understand more of the CSS, those render that part. The ones that understand all of it, they render that part.

The way the code is written, the way the website was planned, the way the design functions, the way the HTML source order works — [if you do it right], you're going to get a really great experience. It may not be the same. The website may not look the same in every browser.com [both laugh] but it's going to be fine for everybody.

Now I'm rambling. But JavaScript is a whole other layer on top of that. Maybe the JavaScript loads, maybe it doesn't. What's going to happen? Blah blah blah.

It's something that is so inherent for some of us. The moment you say, "I'm making a website," I assume that means it's being made in this way with these assumptions. HTML is super important. It needs to work even if it was by itself with nothing else. The CSS should be written in this particular way so when browsers don't understand certain rules, it's still ok. But for a lot of people, that's a new idea. They don't think of the web as a layered cake where the icing is separate from each of the layers. They think of it more like a brochure that they pick up at a hotel or a book that came in the mail. Where everything is one thing and everybody has the same experience.

Aaron

[00:09:30] Right. Where there's only one dependency: did the catalog show up or did the catalog not show up? [Both laugh] It's really about coming to understand the medium and the various pros and cons of the medium and things that can go wrong. Being aware that every dependency is inherently fragile and there can be things that aren't delivered.

By understanding how fault tolerance works and the fact that, as you said, browsers ignore what they don't understand, that takes many forms. In CSS, as you talked about, a particular declaration within a ruleset that's not understood will be skipped over. If you use an RGBA color value, but before that you have an RGB color value, that gets interpreted by IE6. The RGBA value gets ignored by IE6.

The same thing holds true when you look at rulesets and the selectors that you use. If any part of the selector — this is especially important to pay attention to if you're using compound selectors — if any part of the selector isn't understood, the entire ruleset is ignored. You can use these mechanisms in CSS to selectively deliver experiences to users based on their capabilities.

Beyond that, when we talk about responsive design, if a browser doesn't understand media queries, it's going to ignore anything inside the @media block. Or it's going to ignore any stylesheet that's linked to with a media query in the media attribute. You can use that to deliver, let's say, a baseline CSS file to every browser. That includes older mobile browsers, IE6, IE7, IE8. Then deliver the high-fi experience with a second stylesheet that's linked to with a media query. It could even be only screen. You don't have to have the parentheses in there. The "only" keyword is going to kick it out. Those browser just won't get that. You'll have the actual media queries inside that second stylesheet. You create a better performance experience for people in those non-media query aware browsers because they don't have to download that CSS file that they're not going to use.

Jen

It seems like there's a gazillion ways to structure things. "Wow! You do it that way? Oh my gosh, we do it this way." There are all sorts of good reasons to do it any which way.

What I feel is key and very important and — if I were hiring a front-end developer — what I would require for them to already know before I hire them, is an awareness that this is how the web works. Think about HTML. What is it? Is it good? Ok, cool. That's great.

You know who's going to get HTML with no CSS? Everyone who uses Flipboard, Pocket, Readability, Read It Later, whatever. Or when next year suddenly people are using things like Siri or Cortana in their car. They're driving to work. They're interacting with their phone or some car dashboard computer using their voice. "Hey Siri, read me Twitter." Siri reads Twitter. If it gets to a place where this is going to work. "I want to click on that link. Now I'm reading you the website out loud." The way to make a project so as these things appear and the world changes in this way and there are more and more devices and more and more situations. The way to make sure the thing you build today is going to work in two years or five years, is to use progressive enhancement.

Aaron

[00:13:37] It's to make intentional decisions about the different technologies you're using and how you're using them. If you're using a <video> element, using the opening and closing tags so you can put stuff inside of it to be displayed to browsers that don't understand video. Having an unordered list of links to download the video or audio files or whatever you're using in that particular HTML5 construct.

It gets a little bit more interesting in the JavaScript world. That's where you need to start doing feature detection, object detection, looking for objects you want to interact with. Build your different JavaScript programs around that. That allows you to deliver an a la carte experience that may be different for each user but may be appropriate for each user.

What's really cool is that we will be getting some of that feature detection stuff in CSS with the @supports block. With @supports, you can test for support of a particular property. Earlier today, in your talk, you were talking about some of the new layout things that we'll be able to use in CSS. Being able to test for Grid Layout support and then have an entire collection of rules that you want to apply only if that browser actually supports that new spec. This won't work for older stuff, because older browsers don't support @supports. It's somewhat limited to stuff going forward. But as we start to have these newer features, we can have your baseline layout and our layout in our browser that understands Grid. Eventually, we may be able to move that content out of those @support blocks as support rolls out further.

It allows you to do a bit of feature detection before you apply rules en mass. As opposed to the RGBA color version. That's one rule. There's not too many dependencies there. If they just get the RGB color. If they get the RGBA color, awesome, that's even better. We'll give them a slightly different experience. When you start to talk about layout stuff, there are all sorts of properties that need to go along with Flexbox or Grid or Multi-columns.

Jen

I think it was when CSS3 started showing up. Maybe people were doing it before this. But this is when I started to seeing a lot of tutorials. RGBA is a great example. Some browser could understand this new way of writing color using red, green, blue and alpha channel. Other browsers couldn't. Like you said, you could use RGB. But even if you wanted to be even more conservative, you could use a hexadecimal number.

Hexadecimal numbers are the oldest thing. They've been around forever. Every web browser understands hexadecimal numbers. It's a funny thing to be like, "Ok, I want the background of this page to be black. I'm going to write that in a hexadecimal number. Then I'm going to immediately contradict myself." Well, the background of the page is a bad example… [try again] this box is on top of a bunch of stuff, including the background of the page. I want this box to be black. We're going to say #000. Then I'm going to immediately contradict myself in the next line of code. I'm going to say, "Wait, I want this block to be rgba(0, 0, 0, 0.5)." The 0 0 0 also means black. That last digit means 50% translucent. Every browser will go, "We're making this black." Then 97% of the browsers will say, "Why did you say something twice? You just changed your mind? We'll do the second one."

Aaron

[00:17:48] I don't think there's that value judgement, but yeah. [Both laugh]

Jen

I'm turning the browser into a human or something. "You didn't mean black, you meant black that's translucent so now we can see the things that are underneath it because it's translucent." The browsers that do not understand the second line of code will say, "I have no idea what that meant. So I'm going to ignore it. I'm not going to freak out. I'm not going to stop rendering this code. I'm not going to make it green. I'm just going to ignore the thing that I did not understand and I'm going to keep going."

Aaron

[00:18:27] "Surely you didn't mean to say that?" [Both laugh] "We'll just forget you said that."

Jen

A) That's not how you spell hexadecimal. [Both laugh] It's a really beautiful and — in computer science — an unusual thing. This is how the language behaves. We can use that to our advantage and be a little savvy and write the first line with a hexadecimal number, then write the second line with RGBA. And know with this incredible amount of confidence that this code is going to work. You could pull out Netscape 3 and it's going to work.

Aaron

[00:19:06] It's going to deliver the right experience to the right browser.

Jen

Yeah. And it's going to be slightly different. We could talk about that. But you don't have to wait until 99.9999% of your users' browsers support the feature, or 100%. Or whatever your company — maybe your company decides is the number. As if 92% is some sort of fault tolerance… "We'll ignore up to 8% of users". Or "if 98% of our users have support for this feature, then finally we can use it". You don't have to wait to use RGBA until the day that 98% of your users can support it. You can start using it the day is comes out. When it's in only one browser, and when only 5% of your users have it. Because the other 95% of people are going to get the black box [the fallback]. This is how it's possible to use new stuff.

Aaron

Absolutely

Jen

This is how you can create something and experiment with something and try something out and know that it's going to be ok for everybody.

Aaron

[00:20:02] That's what was very intentional about the design of HTML and CSS. This is baked in to the core principles of these languages. It does pose some interesting challenges with the introduction of new elements that are not meant to be displayed, like <template>. <template>, which is part of the Web Components spec, is for putting bits of markup that you want to use as a template for your JavaScript program. If you have elements in there that are empty, it's not a big deal. Because even if the CSS that you apply — say, display: none on the template to make it disappear from the screen. Even if that CSS wasn't available, you wouldn't see anything, because there wouldn't be content in that. When the <template> element isn't understood, the contents are exposed.

Jen

Yeah. That's the big difference between CSS and HTML. We just said video and this also happens with the <picture> element in HTML. The way the <picture> was written, there was a big debate. It took a year or two to debate how <picture> should work. We've got this new HTML that we know a lot of browsers are not going to understand. If a browser does understand it, you get these cool things with responsive images. Baked into the middle of that is a plain old regular <img> tag, as if it's 1994.

Aaron

That's actually mandatory, according to the spec. You must have an <img> element inside there.

Jen

The folks who figured this out and made the specification did it this way on purpose. HTML will ignore the elements it doesn't understand. But it does read the things between them.

Aaron

Yeah, it will expose whatever is inside of them.

Jen

You start with a <picture> and it says <picture> and then it closes the <picture>. The <img> counts. With CSS, like with a media query, if you open a media query and say a whole bunch of stuff and close the media query, if the browser doesn't understand the media query, it will jump and ignore the entire block of everything that's in between. That's a very big difference between how HTML fails and how CSS fails. Fails is probably the wrong word. Degrades.

Aaron

[00:22:22] How they handle parsing errors. How they handle something they don't understand.

The same thing happens with attributes. They ignore attributes on an element they don't understand. Which is why we couldn't jump in and start using HTML5 form elements, which I'll talk about tomorrow at An Event Apart. Being able to use a range type element and have that fall back to text. Or an email type element. Every person listening could go to their contact form and change the type of the input for somebody's email address to a type of email and it will just work. For browsers that don't understand it, it will fall back to being a text input.

Jen

It would will be like type=ema... that's not how you spell text. [Laughs] Text is t-e-x-t-

Aaron

It always used to freak me out. If I would mistype the word radio or checkbox, "Why did this just become a text box? This makes no sense!" The text type is actually the default input type. You could leave type=text off and it will still be a text input. That's the beauty of HTML.

The unfortunate thing with <> is, if you have any text inside the <template> element, and your CSS says display: none, but your CSS doesn't get downloaded.

Jen

Right, the content will display when you didn't want that. Getting really good at this is about understanding the nature of each of these — HTML, CSS and JavaScript. How each of them falls back.

Aaron

Understanding your medium.

Jen

Understanding the medium. Understanding places where it's like, this is really easy. It's no big deal to use border-radius and have it ignored. This is really easy, it's no big deal to use CSS shapes and have it ignored. This one over here, you just wrote all that code for Grid Layout. You have to spend some time coming up with something else for the browsers that are not going to understand that. Actually, we're probably going to have to think about that for a couple of months. Right now, we haven't been doing it because Grid isn't ready for anybody. But once we start shipping Grid to sites once it's ready, if the browsers aren't ready to come out, bam-bam-bam, all at once, very quickly, then we need to come up with a strategy.

There will be some blog posts, debates, hacks and ideas. It will be cool. But anybody who wants to stay aware will have to keep up on the savvy techniques and figure out what to do for a fallback. Like you said, Grid Layout is so much more significant. Missing a rounded corner, no big deal. Having your layout completely broken? Kind of a big deal. [Laughs]

Aaron

[00:25:06] The nice thing about the approach of delivering that linear, mobile experience to older browsers like IE6-8 is, you don't have the testing headache of having to deal with them. Because you're giving them that single column experience. Maybe you want to set a max-width on the body in that case.

Jen

Max-width 400 pixels. [Laughs]

Aaron

[00:25:31] Or even 600 or 500 or set it in ems, so it's based on the text size. Figure that stuff out and give that to the older browsers and maybe that's eventually what we end up doing for browsers that don't support Grid. If that's something that is integral to the experience on a larger screen — Grid makes sense on a larger screen — then maybe we just have the linear layout for older browsers that don't understand that. We use @supports to determine if they can support Grid, then all of the Grid-related stuff goes inside of that.

That's good enough. We don't have to spend a whole lot of time trying to figure out how to cobble together something that's going to be slightly similar to what we want to do with Grid and try to figure it out with floats.

Jen

Right. [Maybe] don't do a duplicate layout in floats and figure out a way to deliver it. The worst thing would be to use JavaScript to parse which layout to send, wait until the JavaScript has loaded, then load either the float or Grid Layout. That would be a performance nightmare.

Aaron

More dependencies, more to maintain. It's more trouble than it's worth.

Jen

How many times are you going to paint the page before you stop re-painting it? Just sending some simple, mobile-esque narrow screen type layout as the default, no-layout layout.

Aaron

Yeah.

Jen

Some of that is about knowing your audience and clients and bosses and knowing how conservative your organizations needs to be, versus how cutting edge you want to be.

Aaron

[00:27:14] One thing that was really interesting — I didn't have it in the first edition of the book, but I bring it up in the second edition. Back in the day, when I worked at A List Apart, they switched over to CSS-based layouts and decided to stop supporting Netscape 4. This tells you what generation this is, right?

Decided to stop supporting Netscape 4 with the fancy layouts. They weren't going to deliver any CSS. The percentage of users in that browser actually went up. All of a sudden, they were having a better experience browsing the A List Apart site than they were having previously when we were trying to shoehorn them in to having a similar experience to other then modern browsers.

Jen

Is that because the "no-layout layout" was actually a better experience than the "well-designed" layout? Or is that because the hacked "well-designed" layout, jammed into Netscape 4, was so fragile that it was frustrating for people?

Aaron

[00:28:20] I can't speak to the specifics. Jeffrey had just shared the stats and how that had changed. I don't know if there was any research into figuring it out.

Jen

It's just so funny. "We're giving the lesser experience to these folks. Oh, it turned out they like it better!" Like, user testing. I don't know if that happened there. I think that tends to happen sometimes now. We think we're being so fancy and we realize we overdid it.

Aaron

[00:28:44] There is definitely that instance with over design.

I'll have conversations with folks and I'll mention a particular browser. A couple of years back, it was Blackberry 4. They'd be like, "We don't have any Blackberry 4 users." I was like, "How's the Blackberry 4 experience?" "It's horrible." Maybe that's why?

I talk to folks and they're like, "We don't have to worry about no JavaScript because we don't have any users that show up without JavaScript."

Jen

"We have zero non-JavaScript users!"

Aaron

How are you tracking your analytics? "We're using Google Analytics." Are you using the default JavaScript that tracks users in Google Analytics? Because if they don't have JavaScript, you're not going to get any users that don't have JavaScript. [Jen laughs]

Jen

You could have 100,000 users with no JavaScript but your JavaScript-based counting application doesn't count them. [Laughs]

Aaron

[00:29:39] Exactly. That's what was really interesting. The GDS at gov.uk looked at how many users were not getting JavaScript-based enhancement. The experiment they decided to run was loading images three ways: an <img> element in the page, another <img> element inside a <noscript> and a third <img> that was loaded in via script.

Their anticipation for this was that everyone would get the first image, because it's an <img> element. People would either get the <noscript> or the JavaScript <img>. They found that 1.1% of users did not get the JavaScript image. But the really interesting bit was that only .2% of that got the <noscript>. There was .9% of all users that did not get the JavaScript enhancement but also didn't get the < noscript> version.

Jen

Their browsers didn't have JavaScript available but also weren't able to report that they didn't have JavaScript.

Aaron

[00:31:00] Or they didn't know they didn't have JavaScript. There could have been a number of things that prohibited that JavaScript.

Jen

A loading error of the JavaScript.

Aaron

It could have been a loading error or a network error.

Jen

The browser doesn't know about JavaScript.

Aaron

It could have been an add-on. Browsers have add-ons that can manipulate the document. There are so many things that can go wrong. The vast majority of the people that didn't get the JavaScript enhancement should have gotten the JavaScript enhancement, as far as the browser was concerned.

Jen

They were using a browser that could understand JavaScript, it just wasn't getting it. I want to get into JavaScript. We've been focusing on HTML and CSS. In a way, if you, listener, are a person working on the business or design side, I hope everyone just understands the major principles. But then we got into some of the tech of the HTML and CSS. The tech side is fairly simple.

There's a bigger debate and bigger... people get into flame wars over progressive enhancement and JavaScript. Before we do that, I should get into our sponsor for this week. Which is Media Temple.

Progressive enhancement and JavaScript. Why do people have flame wars where they talk about how that's so stupid and web apps are too special for progressive enhancement?

Aaron

[00:35:46] I can't speak for specific individuals. I get the general sense that a lot of the people who have that opinion are either relatively new to the web, and don't have an understanding of fundamentally how it works, or they have a skewed perspective as to how people consume the web, and how they're able to consume the web, based on their own experiences. Which may not map to other people's experiences.

As the web has grown in popularity, it's gone from being something that we all dabbled in, as hobbyists, to more and more businesses coming online. As more businesses migrated to the web, the web became capable of creating richer and richer experiences, more software started to move to the web. People who developed traditional software started to see the web, as Scott Hanselman put it, "the new VM." A new virtual machine that was in a browser.

But that's not really how it works. When you build a virtual machine, you're choosing what the operating system is that the virtual machine is running. You're installing whatever packages you might need in the virtual machine. You control the environment or you know enough about the environment when you create the virtual machine. You have control. You have a solid understanding of what's available and not available to you.

When you're developing software for the web, there's very little that you control. You control what it is that you create, but you do not control what ultimately gets delivered to your users. You don't control the execution environment. You don't control unless your only building software for internal use within your organization and your organization has one browser they support and they don't allow add-ons. You don't control the execution environment. You don't control the process for speed. You don't control the screen size. You don't control the pixel density. You don't control the network it's delivered over. You don't control the router that's used to deliver that.

They can basically wage man-in-the-middle attacks. We've seen Comcast's XFINITY routers inject advertising and other content. If you've ever surfed the web in a hotel or airport, they often inject stuff into the pages as well. Unless you're running everything over HTTPS, you have the potential for stuff to be injected into your page and manipulated and caused things to break. You don't have control over whether all of your content has been delivered. Somebody is on a train or on a car or something like that. Or they're on an airplane and the airplane Wi-Fi cuts off or has a hiccup and they don't get the entire JavaScript payload.

There are so many factors that I think you need to take into account. So many things you need to understand are beyond your control. If you assume JavaScript is always going to be available and every machine that accesses your site is going to be able to run all of that, I think you're deluding yourself. It's a cyclical thing.

I remember back in... gosh, it must have been the late 90s. I want to say it was lycos.com. If you ever use the web developer toolbar's "outline table cells" — one of my favorite debugging tools, and was back in the day as well. Lycos was a very popular search engine back in the day. Their site was insanely nested tables. Sometimes 20 or 30 tables deep. The really crazy thing is, if you went and viewed source, the entire thing was generated via JavaScript. I do not even want to know how painful that was to program. This was in the height of the browser wars. You had very different implementations between Netscape and Internet Explorer. There must have been a lot of suicides in that group of developers. [Laughs] Or they were just gluttons for punishment.

We used to do stuff like that back in the day. Build everything out. That doesn't mean that was a good decision. We pulled back from that. When AJAX came along, people were JavaScripting all the things again. That got tempered with progressive enhancement and the idea of hijax; taking existing markup that worked with HTTP connections and forms that submitted to somewhere. Enhanced them if you had AJAX available to you. The pendulum swung back again with the advent of your Angulars and Embers and Knockouts and Backbones. Everybody was, again, moving to JavaScript to do everything. Including, effectively, acting as the server as well as the browser. They were reimplementing the standard technologies of the web in JavaScript. Which required a lot more code to download. Not only to download, but then to load it into memory and execute those commends. The performance just sucked.

That was when we started to see companies that had gone heavily JavaScript, like Twitter and AirBnB, start to pull back and look for alternatives, and look to go back to that idea of hijax. But taking it a step further and having the baseline experience delivered by the server. Then have the single page app take over and dictate the experience from there. AirBnB took it a step further and they did what was called "isomorphic JavaScript", where some of the same code that's being used to render the site using the single page app on the client-side is actually being executed on the server-side as well. Several other companies have picked on that, too. That's actually a really good approach.

It's interesting to me. Tom Dale, who created Ember, wrote this big long diatribe that progressive enhancement is dead. It caused a flame war and a bunch of us responded to that and said that progressive enhancement was still important. Then three or four years later, he announced that Ember has a server-side component to do rendering to ensure that actual HTML, CSS and JavaScript get delivered to the client, so everybody gets an experience, as opposed to only people who can load and execute all of that JavaScript. He didn't say, "I was wrong," but he effectively said that progressive enhancement is where it should be.

Jen

Frequently, I'll be at a conference and I'll hear people say things — in all earnest — to each other, basically saying, "Gosh, isn't it great, the web is finally a proper programming language?"

Aaron

Platform. [Laughs]

Jen

"We did it! We got rid of that crappy, stupid thing that's been around!" I think it's this desire to beat native apps. That's a whole other episode of the show that I should have. This idea that we've gotten rid of the complexity and unknown variables. We don't have to worry about bad network connections and slow devices.

Aaron

In their bubble. [Laughs]

Jen

Yeah. I think people are like, "We'll make an iOS app. Now we have to make an Android app. Let's make a Windows app that's going to run on all of the devices that run Windows. Maybe we should have a Mac app. Let's have a web app!" Yes! That's the awesome thing about the web. The web is going to run across all of these different devices.

Aaron

Web has reach.

Jen

But it's not that the web can get rid of the messiness of all of those different devices. If you chose the correct JavaScript framework, you're going to write one codebase and it's going to run everywhere in exactly the same way. It's more like, the web lets you embrace that complete messiness. This person has a Blackberry, this person has an iPhone 3 and this person has a brand new Macbook Pro and this person has a fiber connection and this person is holding up a satellite dish.

Aaron

And this person's on an Obigo device with Opera Mini.

Jen

Yeah! You've got this wide range of money and access around the globe, with millions of different kinds of computers. The web is the one thing that will run on all of them, no matter what the situation is.

Aaron

... for free.

Jen

When Tim Berners-Lee and Robert Cailliau built the system, they understood the complexity of the internet. Come on, right now, everybody is running some version of Linux under the hood. But back then, it was not that uniform. There were all these different crazy kinds of computers that could barely get on the internet at all. The internet at all wasn't a singular thing, there was more than one internet.

Aaron

The first web browser was on a NeXT machine.

Jen

Yeah. So the web works across all of that complexity. It does feel like being willing to embrace the chaos instead of trying to eliminate the chaos is the beginning of understanding progressive enhancement. To me, that is what progressive enhancement is about. Saying, we're going to make a competitor to Twitter. It's going to be a lot like Twitter. You're going to have all these users and they sign in and they can post short blurbs. We're going to deliver those. We want to deliver those to all of these different places. What is that? It's a list of paragraphs with images. There's an image and a paragraph, an image and a paragraph. That's just content. Let's deliver that as HTML. Then we'll apply CSS and then, sure, we'll write all sorts of fancy JavaScript. When you submit a form, instead of being an old-school HTML-based form that looks like 1998, you have this fancy form. The user experience of that form is that much more beautiful and elegant.

Aaron

But you still have the fallback of the baseline one that submits to somewhere.

Jen

Right. So if that JavaScript doesn't load or a person is using a screenreader or a person is... you don't even know what they're doing. That's totally fine.

Aaron

[00:47:24] We experienced one of these things in my agency. We were working on a project. This goes hand-in-hand with the app discussion. We were working on a project and the problem the client came to us with was that they had an app for an iPhone, an app for iPad, an app for Android. They were considering an app for Windows phone. They're an investment company. Security is really important to them. They were having problems because if they wanted to upgrade the login code to add a security feature or something, they would have to update the web service that each of the apps used, then update each of the individual apps — updating the UI, update the underlying code — submit them to the app stores, get them through the app store approval process, cross their fingers and hope their users upgraded their applications. This all took a lot of time. When you've got a security thing you want to roll out, you probably want to roll that out a little bit quicker.

They came to us to reimagine this as a web-based flow. But only taking into account iPhone, iPad, Android. Generic Android, it wasn't a specific Android phone or tablet. They just had one app that worked for both. And potentially Windows.

We went through the process of building them a pattern library. We built them 35 representative screens that would carry across and show the different patterns in use for them, so their developers could see how to use them. The whole thing was done with progressive enhancement, even though they didn't ask for that. That was a great win. They were very happy with it. They were able to build out all of the other screens they needed, roll it out, get it into their apps, and the developers were happy because the pattern library was really easy to use. It was really declarative markup. They didn't have to think about the CSS, they didn't have to touch any of the JavaScript. It was all very loosely coupled.

Fast forward about nine months later. They came to us and were like, "This is great. We want to roll this out for our m dot site." They handed us an Excel spreadsheet that had 1,400 different user agent strings that accessed login in two days.

So I wrote a script that parsed all of that to get back specs on each of those devices, so I could start trying to figure out how many devices we were talking about needing to test on and look at. Aggregating things based on screen size, operating system, browser version, processor speed, that sort of stuff. I was able to winnow that down to about 23 devices that represented about 97% of the spectrum. We chose devices that were Wi-Fi capable. Some devices weren't, that were of the same era as some of the devices that were Wi-Fi capable. We decided to leave those off, so we didn't have to buy a data plan just to test on those devices. We found emulators for some of them, in hope that would be good enough. We made the promise to the client that if something came up with one of these devices, just let us know and we'll take care of it.

We gave them a budget for that. For adding support for 1,400 new user agent strings. We gave them a budget that was a 1/3 of the budget for the four platforms that we gave them initially. Then we tucked into doing it and we came back at half time and half budget. Because progressive enhancement just worked. We had heinous things like Openwave. We had Blackerry 4 and Blackberry 5. We had older Windows phones, or when it was Windows mobile before that. We had all of these things that make people cringe. The new IE6s of the era are old mobile operating systems and mobile browsers. But progressive enhancement just works and allowed us to deliver a good experience to users on all of those crazy devices. That was a huge win. Like most large corporations, they're not used to paying less than they're supposed pay for a particular project. They didn't even have any mechanisms for taking money back that they had paid us. [Both laugh] It was an interesting conundrum. We ended up putting that aside for them for the next project. They were veery happy. They had never had that happen before.

Jen

I think people think progressive enhancement means, "We have to spend a lot of time writing specialized code for old devices and browsers."

Aaron

Not at all.

Jen

Then they're like, "I don't want to do that. That also means we can't write this new fangled stuff that's coming out. We can't used the new fangled stuff because we can't support it. Meanwhile, we don't want to do progressive enhancement because that means we'll spend a lot of time thinking about the old stuff."

I don't know where people get these ideas. Because both of those are exactly the opposite of the truth. I like progressive enhancement because I want to use the new fangled stuff. This is going to mean I can use it when there's only 5% market share, and everybody else is going to get a great experience. As the market share shifts from 5% supported to 95% supported, I don't have to rewrite one line of code. I launched that client two years ago. They're fine.

Also, I don't want to spend a lot of time thinking about old phones and devices. I just want to send them a basic experience and never talk about them again.

Aaron

[00:53:15] We started doing something where we actually use conditional comments — which they stopped supporting in IE as of IE9 or IE10. We started using conditional comments to selectively not deliver JavaScript to IE8 and below. All other browsers — IE9 and browsers that don't support conditional comments get JavaScript. Those older IE versions? We don't bother giving them JavaScript. We give them the linear layout and no JavaScript experience and they can still do everything they need to do. But I don't think we have to test. I know it's going to work because I'm using the technologies that would work in Netscape 4 or Netscape 2.

Jen

It is sort of saying, "I thought about these people and I really don't want to test any of that. I want to get in and out as quick as I can. I'm going to give them a really solid experience in HTML. It might look like it's 1994, and that's totally fine."

Aaron

Yeah. At least they're getting an experience, not no experience.

Jen

They can submit the form. They can click the links. They can download the information they need.

Aaron

It's probably a faster experience because you're not asking them to download a bunch of other stuff. They're probably ending up with a better experience overall. Especially than they're having on the rest of the web, because everyone else is telling them, "I'm sorry, you need to be this high to ride. You're not using the right browser." There are people out there who can't change their browser. There are people out there who don't even know what a browser is.

Jen

Most people.

Aaron

For a lot of people, especially in the Windows world, they know they hit the "e" and that takes them to the internet.

Jen

I have to say, I got an iTunes review where someone said, "She doesn't know what she's talking about, she said that people don't even know what a browser is and of course they do. You should have data to back that up." Well, ok, here's my data. Google did a study. They have a video that a lot of people know about, probably a lot of listeners have seen. Where they walked around Times Square and interviewed people and asked, "Which browser do you use?" Most everyone answered with the search engine they use. They don't understand the difference between a search engine and a browser. And why should they? They click on the "e", they type in the thing and they get to the Google. They were saying, "Which browser do you use?" "We use the Google." They did not mean Chrome. [Laughs] They meant Google search results.

I think we forget. You were alluding to this before. If you live in the United States and work at a big startup and you are surrounded by mostly white people who make a lot of money. You just live in your little bubble. You don't understand what it means to not have cable internet at home. To only have your phone. That's your only computer. Every time you want to renew your driver's license, you're using your phone on a 3G connection. Living in another country.

Aaron

Or Edge.

Jen

Or Edge, living in another country. Not having the best of the best experience all the time.

Aaron

[00:56:23] I was consulting with another organization. They're a retail store. They sell low-end tablets, like $50 Android tablets. Not very good screens, not very fast. I was talking to them about their device lab and what they were testing on. They were like, "We test on iPhone and iPad." I was like, "Do you test on any of the tablets that you sell?" There were literally crickets on the call. Then there was a question, "We sell tablets?" [Both laugh] I was like, "... yeah, you do."

As a consumer, if I walked into your store and purchased a tablet, I would expect to be able to use your store's website on said device. If I just spent $50, which is a lot of money to me, on this tablet, I should be able to do whatever it is I need to do on your website. Because you sold it to me. I think that's basic customer service.

That's really what progressive enhancement is. At it's core, to me, it's about customer service. It's about creating a good experience for your users.

Jen

For every user.

Aaron

Every user.

Jen

Not just drawing a line and saying, "Everybody above this line gets our experience and everybody else can go someplace else."

Aaron

[00:57:47] Right. It's about accessibility in the broadest possible sense. In terms of actual access. It's not about screenreaders. Although obviously low-vision users are a part of the equation. It's about enabling people to do what they came to your site to do. Whatever that is. Whether it's to read an article, read a blog post, submit a comment, spam you with hate mail or troll you, [Both laugh] purchase from you. Create as many opportunities for that person to do what it is they're trying to do with as little frustration as possible.

The job of a designer is to solve our user's problems. That's what we should be doing. I think a lot of times we spend our time creating new tools that are going to make us famous within our own circles. We spend time solving our own problems and we don't spend time solving the problems of our users. We almost end up passing the buck to them. With a lot of the front-end JavaScript frameworks I feel pass the buck onto the users.

I talked to Nicholas Zakas. He was talking about a site that was running very slow. It was the site of a very large retailer. They brought him in to optimize their site. He found they were loading multiple versions of jQuery plus Prototype plus Scriptaculous, plus three or four other JavaScript libraries. We're not even talking MVC frameworks. Each developer had their own one they liked and they said, "Let's just load them all!" [Laughs] They were literally loading 2.5MB of JavaScript. They were a very photography heavy site, too. You add of this together and it's crazy. That creates a slow, poor experience for people.

Brad Frost has that great example comparing the sites of Obama and Mitt Romney in terms of their mobile approaches. I want to say it was his brother-in-law's Blackberry that ran out of RAM trying to load the Obama for America site. It was just too big. The phone didn't have enough memory to parse the page.

We need to be cogniscent of that. We need to be aware. Being aware of that is good customer service. That's what it comes down to. It's good UX. Depending on which way you want to look at it.

Jen

I love the way Jeremy Keith walks about this and progressive enhancement. There are quite a few people who feel like, "I totally agree, I believe you. But we're making an app. Because we're making an app, everything you've just said about progressive enhancement doesn't apply to us."

I like what Jeremy will say back to folks. He's written several great blog posts on this where he says, you need to think about, "What is your app?" What's the purpose of it? What is it actually doing? If you're creating something with WebRTC and it's some real-time communication, as soon as one person types a comment the other person sees it immediately. Or there's a video back and forth.

But what is it really, at the core? It's two people sending messages to each other. Maybe what you want to do is create a website using the technology that comments use, where it's a form. One person sends a comment and the other person sends a comment. Maybe it would be very rudimentary where it would require the user to refresh the page and there was no real-time aspect to it.

Aaron

[01:01:37] Meta refresh was what we used to use back in the day. If you did customer service chat back in 1998-1999, we used meta refresh in order to get back what the person was saying.

Jen

You want it to be super simple, right? "The purpose of this? Wait, what's the purpose of this?" The purpose of this is that two people can have a conversation. So we're going to build a very simple, HTML-based version. That's going to be our foundation. It's not a separate website or a separate version. That's the foundation of this website. Somehow we're going to build the code so the base of the code — the place where we dug a big trench in the dirt and poured concrete into the ground to build walls to make a building — that is basic code that's going to work everywhere.

We're going to layer things on top of that. Maybe when you get to the layer where things are run by real-time communications and WebRTC and Web Socket and all of these awesome things, it's layered on in such a way that even if people don't get the thing that is the reason they're going to be excited about your product and give you money and the shiny and the best of the business and you're really competing with other people... maybe they won't get any of that. But at least they'll get the broken-down, rudimentary version. When you're on Amtrak and trying to chat with your co-workers, the experience doesn't break completely.

Aaron

[01:03:07] There's been a small movement of people who are annoyed by their smartphones and all of the notifications. They're moving away from smartphones and getting older feature phones that can connect to the web but connect to it in a more basic fashion. You'd still be able to support them with that older technology.

I was on Stack Overflow and decided I was going to go through and see if there were questions I could answer. There was this guy who asked the question, "How you use progressive enhancement when JavaScript seems like a requirement?" He posted two examples. One was the chat program, one was something else. I wrote this huge, long response. Then he deleted the question before I submitted it. [Both laugh] It didn't go anywhere. So I decided to turn that into a blog post. The answer is up on my blog, including his original question.

Looking back to the older technologies, none of the stuff we're doing on the web, apart from the WebGL stuff, that's new. That's wholly new. We did some stuff like that in Java applets back in the day. In terms of web tech, most of the stuff we're doing now, we were doing back in the late 90s or earls 00s. Looking back to how we solved the problems back then can help create the solid baseline that you want now. That gives you the ability to have more reach. It gives you the ability to have more people be able to use your service.

There are certain instances where you can draw a line in the sand and say, "This absolutely would not run within JavaScript." If you were building a photo editing app, along the lines of what Aviary was putting together a couple of years back. An online version of Photoshop. You probably need JavaScript to do all of that stuff and do real-time processing in the browser, otherwise you're going to have to make round trips to the server each time to do the manipulation, and that doesn't really make sense. Ignoring the fact that I don't think building a photo editor in a browser is a smart idea. Just because the amount of processing power required to manipulate an image. You're inside a browser, so you're automatically operating at least one level more distant from the hardware. You're not getting as much benefit. The more abstraction you have, the more expensive things get and slower they get. Ignoring that, I think you could make a case that is just something you can't progressively enhance. That's fine.

Jen

I think there are apps where people say that too quickly.

Aaron

Absolutely.

Jen

Maybe an app where it takes photos and you can apply a bunch of filters and upload that photo. Ok, you don't have the ability to use the camera on an older device, but you could still upload an image. Maybe somebody has an image on their computer. You're still providing a way for them to upload the image. Maybe the filters and Photoshop-esque part doesn't run, but this other part does run.

Aaron

[01:06:42] You create an alternate UX. Maybe you upload the photo and it presents you with the different filters, like the band at the bottom of Instagram.

Jen

Just now we're talking about JavaScript yes/no. There is more of, how about 2014 APIs and 2016 APIs? There's even a progressive enhancement within JavaScript.

Aaron

Right. That's where you do the feature detection stuff.

Jen

I do agree. I think there's probably use cases where if you get together in a meeting and everybody understands progressive enhancement, they understand these principles, and really want to go that way, and talk it through, they realize, "That principle... yeah, we got nothing." [Laughs] I think that probably does come up. But I think people talk about that as if it comes up 80% of the time, when actually is comes up .8% of the time.

Aaron

[01:07:42] I would make the argument in using the photo editor as an example. I'm talking about one with photo retouching.

Jen

Like really competing with Photoshop.

Aaron

Yeah, really competing with Photoshop. I would make the argument that not everyone's building that on the web, and not everybody should.

Jen

Like, who's building that on the web? Adobe?

Aaron

We maybe need three or four of those in total.

Jen

Not all of you working at those startups are building that. A lot of you are building travel booking websites. That's a list of flights. You should deliver that with HTML.

Aaron

[01:08:13] You could also make an argument in the case of a Basecamp or Gmail. A service that somebody has to sign up for that is a little more complicated. It doesn't mean Basecamp couldn't be built with progressive enhancement. It absolutely could. But I think you can draw a starker line in the sand in that situation because you're building it as something that somebody has to sign up for. They have to agree to a terms of service in order to use it. They're creating an account. I would counter argue in that instance that you're limiting your potential reach by requiring JavaScript or browser X, Y or Z. If you want to do that, that's your business decision. On the other hand, if you're creating content for the open web — the promotional site for that particular tool — that should work anywhere.

I think a lot of people just make excuses to simplify their lives. I think we spend time scratching our own itches and focusing on making our lives easier and our users end up paying the price for that.

Jen

If you're building Microsoft Word in a web browser, there probably is a way in which it's not going to work in the oldest context.

Aaron

But maybe you don't need all of that rich formatting stuff. Maybe you can do plain text or Markdown or textlie.

Jen

Right. Someone can open it on a crappy device on a slow connection, or awesome device on slow connection — and type and save.

Aaron

[01:09:48] Exactly. I think the really interesting thing that I noticed when I started doing textile, the one I learned before Markdown. I was like, "Gosh, looking at all of this Textile stuff, it works really well as lain text email, too." It actually makes sense.

Jen

It falls back.

Aaron

It falls back! [Both laugh]

Jen

It falls back to plain text email. It's true. You're designing an HTML email and you want to fall back and have a decent experience when the HTML doesn't get rendered. I do feel like if everyone believed in this, we could have some great conversations about where the edge is between doable and not doable. But that's not what I'm seeing. What I'm seeing is a lot of people who don't understand this at all, arguing against it. I think they want to pretend the web is this singular runtime environment they can control. If they just pick the "correct" JavaScript framework, all of the messiness of the web will go away. If it didn't go away, they must have picked the wrong JavaScript framework. Let's switch to another JavaScript framework. They're like, "We don't have money for accessibility. We don't care about users who have slow connections. We don't care about international traffic." How many people are you going to not care about before...

Aaron

Before your business fails. Yeah. I think the thing is, people make excuses. It's human nature.

Jen

We'e afraid of what we don't understand. It becomes easy to be really defensive about it.

Aaron

[01:11:22] I think the beauty of progressive enhancement is, you're embracing the inherent way the web works. You're reaching more devices than you're even testing on because you're building it in a smarter way.

But in a lot of cases, a lot of the heavy duty accessibility stuff comes for free. If you've got a site that works plain text and works with normal submissions, it's going to work for somebody with a screenreader and keyboard. Whereas, you're going to have to work extra hard in order to take something as simple as a button to submit a form. If you use a button of type submit or an input of type submit, it will submit the form. If you use an anchor element, at least it's focusable via the keyboard. But you have to make it look like a button. You have to add the keyboard handler, I think for "spacer". "Enter" will trigger it but "space" doesn't, whereas "space" will trigger an <input> or <button> that has type of submit. You have to add the other JavaScript stuff that makes it submit the form when you click on it. If you wanted to do something like a <div>, it's even worse. You have to find a way to add it to the tab order. You have to add all of that additional JavaScript and CSS dependencies. This is all just for a button. [Laughs]

Jen

I see that all the time. Looking at somebody's code. All of the buttons are <span>s. It's just like, "Why?" [Laughs] I don't understand it. It feels like somewhere along the way in the career paths of many, many, many people, so it's not about those people, it's about something about the industry itself that has gone wrong. Knowing how to use a <span>, we don't care about HTML, we're just going to use <div>s and <span>s and maybe some <a>s. It's all anybody is willing to do. It is confusing. It's just so completely far away from the web that other people care about.

You use a button. The button looks ugly but you can style it. You can't style every single idea you possibly have about it, perhaps. But it's fine. A little bit of graphic design and branding in order to make sure it functionally works in all of these different places.

Aaron

[01:13:45] And make it less of a maintenance headache for yourself over time. There are so many pros to doing that. A lot of it comes down to control. Wanting to control every aspect. The most vanilla box that you can get is a <span> if you need something inline or a <div> if you want something that starts on its own live but has no inherent padding or margins. I think that's why people have gravitated towards that. It ultimately comes down to a fundamental disrespect of the HTML language and not understanding that markup is actually meaningful and has purpose. It should be used with intent. Again, it comes back to not understanding the medium.

Jen

I do think you end up in a place where it's a lot more work. There's a lot that you don't even realize you've left behind, because you didn't use the HTML the way it was intended or designed. It's fragile. It could break. A new browser could come out next year and you'd be in big trouble. A new device. A new category of devices could come out.

Aaron

[01:14:55] Or in the not-too-distant future, voice-based user experiences. As things like Echo and Siri and Cortana and Google Now get smarter and get connected to screenreaders, all of a sudden we're going to be having conversations with our computers. If everything is a <div>... [Both laugh]

Jen

You're in trouble.

Aaron

That particular browser will not see anything. It will only pay attention to the markup. So your markup had better be meaningful.

Jen

I think it could be easy for people to say, "That could happen eventually, but that's not going to happen next year." Here's the thing. Maybe it won't happen next year. But is there a chance it could happen in the next 10 years? Remember where we were in 2005? Most people didn't have a mobile phone. The people who had mobile phones had clamshells and candy bars and never got online. We could not have imagined what's going on right now. But many, many, many websites — especially big content websites, big newspapers or television stations, these multi-million dollar web projects, where the code that's written today will be integral to what's going on 10 years from now. There are plenty of projects that we touch — that everyone that we know touches every day — where you're dealing with and working around legacy from 2005 or even before that.

Aaron

Stuff sticks around.

Jen

Stuff sticks around. If you're working with 10 people on a multi-million dollar project, I feel like there's a bit of a responsibility to make sure the choices you make today are going to way outlast you. You're going to be long-gone from the project.

Aaron

Or it's going to help future you. [Both laugh]

Jen

That's true too. Give yourself a break! Make yourself not have to re-tool everything and curse your past self.

Maybe not every spark of any idea that we see right now is going to come true. Maybe a half or a third of them will. And they probably will in the next 10 years. It feels like what you're doing is setting ourself up. It's not just about supporting the bad hardware now. It's about 5-10 years from now, being able to support it. Both into the future and into the past.

Aaron

[01:17:13] I think there's a lot the past has to teach us. If you look to the things that we had to do to make our sites render well on a 14.4 or 28.8 modem, those same lessons that we learned then are coming back to help us now in the mobile sphere. The design considerations we made for a 640x480 screen are coming back to help us with smaller phones and smartwatches. In the same way, the stuff that we used to do when we had games like Zork that were purely text-based, that sort of conversational UX is what's going to help us down the road when we start having purely voice-based interactions in our car or at home when we're sitting on the couch.

Jen

I think it's part of why there are many of us, you and I are two of these people who are pretty passionate about this and kind of self-righteous about it. [Laughs] I remember what it was like to try to get a website to work in IE3 and Netscape 3, IE4 and Netscape 4, IE5. It was so painful. We tried all kinds of different ways to make it work. Progressive enhancement was not the first idea. Having a splash page that said "best used in such-and-such browser" came along before. It's been 20 years of lessons learned the hard way that makes us, today, go, "We have to use progressive enhancement!"

Aaron

[01:18:45] It took a decade to get to progressive enhancement. It wasn't coined as a term until 2003. It hasn't been with us for all that long, in the grand scheme of things.

Remember back in Netscape 4.7, if you didn't close a <table> element, it just threw off the whole layout? [Jen sighs] [Aaron laughs]

Jen

Yeah. We've used up all of the time we had today. Please tell people where they can find you and follow you on the web.

Aaron

@aarongustovson is my handle on Twitter. aaron-gustafson.com is my web address. Those are the two best places to find me.

Jen

And you're blogging and speaking at conferences. Where is all that?

Aaron

All of the information about that is up on my site. I also keep lanyard up to date with everywhere that I'll be. I'll be the Future of Web Design in New York in November.

Jen

Me too!

Aaron

Yay! And I'll fly immediately from that to Malmo, Sweden for OrDev. That will be a long week.

Jen

Future of Web Design New York is the end of my long week, where I'm doing Future of Web Design San Francisco.

Aaron

They tried to get me to do that one, too.

Jen

And An Event Apart San Francisco. But it will be good.

People can follow this show at @thewebahead on Twitter. Or, of course, go to thewebahead.net, the website for this show. You can find the show notes for this show at thewebahead.net/105. Please rate this show, write a review, put it in the iTunes store. That would be a huge help to making sure that this shows up in the store and other people are able to find it.

And tell your friends and colleagues and co-workers at work about this. I hope this show is a resource. If you want to convince your boss or tech lead at work to think about progressive enhancement. Or whatever your role is. You want to talk to other people and convince them, send them a link to this episode. Send them a link to other episodes of this show.

Aaron

And I'm fairly responsive on Twitter. If people have questions, I'm happy to answer them.

Jen

Yeah. I do think there's a place in where we can continue to have a debate about when progressive enhancement is appropriate. As long as that first 80% is not the way. Anyway. That's enough of that. We'll get off our high horse now and go to dinner.

Aaron

Thanks so much for having me, Jen.

Jen

Thank you for coming. Thank you all for listening. Until next time.