Aaron Gustafson is a Principal Program Manager on the Microsoft Edge team, focused on their work on Progressive Web Apps and developer UX. He’s also a spec editor at the W3C and Editor-in-chief of A List Apart. Aaron joins Luke and Jonathan to talk about the Open Web and share his perspective (and some guidance) with the WordPress community.

Transcript#

Luke Carbis:
Jonathan, I think that our new podcast intro should be something like, “It’s been too long since we last spoke. How are you doing?” We always seem to have these big gaps this season—this is season four, can you believe it?—of Crosswords, where we’re always missing each other in between weeks. I’ve been on vacation, you’ve been busy, you’ve been doing a show.

Jonathan Wold:
Been doing all sorts of things.

Luke Carbis:
Yeah.

Jonathan Wold:
My first musical. It’s been hours of rehearsal each night. It’s been quite intense, but fantastic. Excellent learning experience.

Luke Carbis:
Well, this week, Jonathan, I want to welcome you and our audience to another episode of Crossword Perspectives. This is one of those ones where we have a bit of a longer chat and not just between the two of us. This week we have a very special guest, and I want to welcome Aaron Gustafson to the show. How are you doing, Aaron?

Aaron Gustafson:
I’m doing well, thanks. It’s nice to be here, Aaron.

Luke Carbis:
For those who don’t know, he works on the Edge team at Microsoft. Aside from that, he’s also an editor for W3C and A List Apart. And he’s got this new project—I think it’s fairly new—called the Web We Want. I’ve recently discovered it, anyway, so it’s new to me. Aaron, all of this work in and around the open web, you’ve obviously got a passion for it. Would you be able to introduce yourself to the Crossword audience and tell us a little bit about what sparked this passion?

Aaron Gustafson:
That’s a good question. Gosh, so I’ll go back a ways. I came to the web to start building things around about ’96, and I was a music journalist at the time, running a publication. My whole motivation was to bring that online from being just a zine, basically, to being a web presence fairly early on. I had a friend who built the first version of the site, and I was like, okay, I want to do other things. So I basically taught myself web to be able to do that. But then I became very interested in it and decided that was sort of the direction I wanted to head. I got kind of burned out on music journalism and going around and seeing concerts all the time and meeting famous people and, you know, a horrible life. Yeah, yeah, going to the Cannes Film Festival and all that sort of stuff—it was so rough. But, no, I got burned out and decided I wanted to focus on doing web stuff.

I feel like a lot of it’s happenstance, and a lot of it has been just colored by the experiences I had coming onto the web and starting out. My first attempt to go online that wasn’t like AOL, my first attempt at opening a browser and stuff like that in college—I had to go online using… was it Gopher? I think it was Gopher, basically. My university didn’t have the Point-to-Point Protocol (PPP) to connect my computer in my room to the servers, so I had to use the command line. My first experience of the web was literally seeing a black screen with white text and it just saying “image, image, image, image, image.” And I was like, this web thing is total BS.

Luke Carbis:
What year do you think this is?

Aaron Gustafson:
This was probably like ’95, maybe something like that. ’94 or ’95. I remember going to Sony.com because I was a big music fan and was trying to look into some of the music and stuff they were producing. I’m sure at the time it was all image maps, right? And none of that was working. That experience really colored my perception of how we should be building for the web and thinking about building experiences that are accessible to everybody, no matter what their technology is. So that’s kind of given me a broad perspective and led me into the realm of progressive enhancement and accessibility.

Jonathan Wold:
This interest starts young. When did you first get the idea that you might be able to build a career around it? When did that come into the picture?

Aaron Gustafson:
So I’d been kind of dabbling for a bit, doing some smaller side projects and freelancing and stuff like that—probably through, actually no, I guess ’99. I graduated from college in ’99 and actually went to work at the Bradenton Herald in Bradenton, Florida. I went to school in Sarasota, and when I started there, I was basically one of two people who were building the website. So I would go in at 11 o’clock at night and get articles out of Quark templates, drop them into Dreamweaver and fetch them up to the website.

Luke Carbis:
Those were the days.

Aaron Gustafson:
Yeah, don’t you miss that?

Luke Carbis:
I miss that.

Aaron Gustafson:
I don’t miss working from 11 until 5 in the morning. But, yeah, they were certainly heady days. There was very little oversight. I picked what went up on the website, in terms of which articles were up there and stuff. I mean, obviously, it was informed by the layout of the paper itself. But I remember walking by desks that had the new iMacs on them and all their pretty colors. I remember seeing magazines out that were like, “XML is the future,” and all that sort of stuff. It was interesting. I was getting paid to do that. Not well—it was like $12 an hour or something like that. But from there, I did some IT work, and then my fiancée got into Yale Divinity. So we were looking at moving to Connecticut, and I was looking to figure out what I could do up there. I ended up getting hooked up with Aquent, a company that would farm me out for freelance work.

They were offering me, I think at that point, like $23 an hour. And I’m like, oh, that’s pretty awesome, especially in the midst of the dot-com bust. I got to work with a lot of great companies and brands through Aquent, and that kind of kicked off my career. While working for Gartner on their website, I became more aware of web standards, the Web Standards Project, CSS, and started to get more involved. I wrote my first piece for A List Apart in 2003, I think, and then gave my first talk on XHTML in 2004. That’s where I met Molly Holschlag, and between Molly and Jeffrey Zeldman, when I eventually went to work for A List Apart the first time, more doors opened. I got to do work for Adaptive Path and some other really awesome companies, and it was really cool to see what the potential was.

Jonathan Wold:
What prompted the first contribution to A List Apart? Where did the idea come from? How did that come about?

Aaron Gustafson:
I was playing around with tabbed interfaces, if I’m remembering correctly. I think the article was titled “You Can Have Your Cake and Eat It Too.” I’d come up with this idea of how you could approach having something—an interface—that would work normally and then could turn into a tabbed interface without having extra ugly markup and useless links and stuff like that that wouldn’t work if the JavaScript wasn’t functional. That was my first foray into that space. I remember Jason Fried of 37signals—he and I ended up having a back and forth spat over the approach or something in the comments on A List Apart. I think he even did a piece on Signal vs. Noise that was a teardown of my article or something. But that was my first foray into that space, starting to write, and I was very much inspired by folks like Doug Bowman and Dan Cederholm and Ethan Marcotte and people like that.

Jonathan Wold:
Now, you had a writing background before that, right?

Aaron Gustafson:
I was a music journalist. Yeah, I was doing writing and editorial stuff, so that came naturally to me. I was super inspired by—I think the first A List Apart piece I found was Eric Meyer’s piece on using CSS for print. Later, to pay homage to that, I wrote a piece about improving link display for print where there was a JavaScript that worked behind the scenes to take all your links. If you remember, Eric Meyer’s piece used CSS to inject URLs for print versions. When I was drafting new articles and had my wife edit them, she’d print them for feedback and said these URLs really get in the way of reading. So I wrote a script that made those into footnotes for print, and I ended up doing a piece on A List Apart for that, I think around 2005.

Luke Carbis:
So you’re writing for A List Apart, and now you’re an editor. Maybe you could describe A List Apart for our listeners who aren’t familiar.

Aaron Gustafson:
I kind of think of A List Apart in the same way as the New York Times—as an institution in terms of publications. It’s been around forever. Started as a mailing list, really well respected. We’ve had a ton of fantastic writers and editors over the years. I started out as a lowly copy editor, then a technical editor, then got too busy and had to take a break, but eventually came back as editor-in-chief, which has been amazing. All the original CSS approaches we used—like Sliding Doors, expanding buttons—they were all pioneered in the pages of A List Apart. Now, we continue to push the boundaries, not just with tips and tricks, but with bigger thinking about how we approach the web and our work. We’ve branched out into content strategy, user research, just more interesting ways of thinking about things. We don’t publish as often now, but when we do, it tends to be something more thoughtful and hopefully lasting in the industry.

Luke Carbis:
So there you go. Listeners can add it to their RSS feeds.

Aaron Gustafson:
Indeed.

Luke Carbis:
From A List Apart, what was the path that took you to working with Microsoft on Edge?

Aaron Gustafson:
Let’s see. A List Apart is all volunteer staff, so I wouldn’t really call it a job, but it is, if that makes sense.

Luke Carbis:
Oh, you’re talking to WordPress people. We know exactly what you mean.

Aaron Gustafson:
So I was, at the time, working at an ad agency as lead developer. Through connections I had with Molly Holschlag, Jeffrey, and Adaptive Path, I eventually left for my own agency, Easy Designs. We ran that for over 10 years. Started just me, then grew with larger projects—bracket games for American Idol, other big projects. Needed to bring on more people, so my wife joined as project manager, then user research, and we eventually relocated to Chattanooga for 10 years.

Partway through, both my wife and I hit a point—do we want to continue client services? It’s fun, but I was really passionate about education: helping people become better developers, making the web more accessible, more egalitarian. I was doing a lot of speaking and writing, working on the second edition of Adaptive Web Design, and thinking about what to do next. Do I want to stay in client services, or focus on this passion?

We front-loaded the year with some big projects, which gave me half a year to figure it out. Looked at jobs my friends had—people like Bruce Lawson at Opera, Christian Heilmann at Mozilla—and thought about being a web evangelist. What drew me to Microsoft was that, at the time, we were still in the late Internet Explorer days—Edge hadn’t even started yet—and I looked at Microsoft as a sort of scrappy upstart, in a way. In terms of the web community, a lot of people had written it off. I had contacts at Microsoft from Web Standards Project work going back to IE7, and they’d also helped with Web Standards Sherpa, which I’d also worked on.

Reached out, asked about possibilities—because there wasn’t really an evangelism team for the browser at the time. We talked for about six months before it materialized. I reached out to Ray Bango, who had been at Microsoft and then left. Little did I know he was about to go back to Microsoft to form a dev evangelist team, and he was partly selling me on the idea. So I joined Microsoft in early 2015 and did a lot of your standard evangelist stuff—writing, speaking engagements. We bounced around a bit because our team was remote and most of Microsoft wasn’t remote-friendly yet.

Luke Carbis:
At this point, you’re going to conferences and trying to convince people that IE was worth their time?

Aaron Gustafson:
Yes and no. I was always doing that because I think folks should take into account all browsers people are using, not just the ones we use. When we focus only on the browsers we use, we make it harder for people who don’t use the same tools to access the web. That’s a problem for me. When I approached Microsoft about joining, I said upfront, I’m not going to be a shill for Microsoft products. I’m going to talk about standards, about how people should be building for the web, about accessibility, all that stuff.

Luke Carbis:
So it’s not, “You should use Internet Explorer;” it’s “You should build in a way that’s safe for all the people who are using Internet Explorer.”

Aaron Gustafson:
Exactly, exactly. And the other people using old versions of IE that they can’t upgrade, maybe because they can’t upgrade their Windows license. I remember hearing this story—can’t recall where from—about a Costco eye center where someone noticed a Windows update prompt and asked about upgrading. The person said, “I can’t upgrade because if I do, I have to buy a new license for the business software, and that’s $10,000, and I can’t afford that.” So they’re stuck on an old version of Windows. We talk about people not upgrading and badger them about it, but there are real reasons, and who are we to tell them they shouldn’t be able to access their bank account?

Luke Carbis:
Wow.

Aaron Gustafson:
Right.

Luke Carbis:
Yeah.

Aaron Gustafson:
That’s how I think about this stuff.

Luke Carbis:
These days we have build tools that will automatically, based on usage percentages, build out support for various browsers. What are the magic numbers, do you think? If a browser is used by less than 1% of people, should our project still support it? Or is it half a percent, or is it 5%? What are the numbers, do you think?

Aaron Gustafson:
I don’t like numbers and percentages and stats in that way, to be honest. I want to build basically the 1965 Chrysler Imperial of a website—and that car has actually been banned from demolition derbies because it’s basically indestructible. I want to build websites that are resilient enough to work no matter what. I don’t know how I obtained this gift or superpower, but I can break stuff very easily, so I tend to find all the edge cases. I don’t like relying on browser stats because I think they can be misleading in a lot of ways. If we look at global browser stats, that tells us nothing about our actual customers. If we look at our own browser stats, those can be colored too.

Luke Carbis:
Can I interject with a personal favorite theory of mine? I think the web has an incentive to become less private over time because people who care about privacy—myself included—will use things like content blockers, which block, for example, Google Analytics scripts. So the website’s stats about browser usage or whatever are missing all the privacy-conscious people. Is that a real thing?

Aaron Gustafson:
No, absolutely. The oversight thing is real. Same with people who don’t have JavaScript. Some people claim, “Oh, our analytics say nobody is browsing without JavaScript.” And I’m like, are you using the standard Google Analytics? What does that rely on? JavaScript. So if they don’t have it, they don’t get counted. If you’re not adding your server logs to that, you’ve got nothing. There’s something I call “artificial suppression,” where you provide a broken experience in certain browsers, so naturally nobody uses them, and it looks like you have no visitors from those browsers. A List Apart has a piece about this—when they stopped serving advanced CSS to Netscape 4, the percentage of readers using Netscape 4 went up because the site was usable again. There are lots of instances like that.

For example, I was consulting for a major drugstore retailer in the US. Their device lab only had iPads, iPhones, maybe one Android device. I asked if they had any of the devices that they actually sell—like the super low-end Android tablets and netbooks—and they hadn’t even considered it! People might want to use those to, say, renew a prescription. You see this all the time: when a new iPhone comes out, sales of the old models go up because people dump their old ones, so those on tight budgets pick up older devices.

Luke Carbis:
You’re going to join my side in my and Jonathan’s constant debate over which podcast recording service to use. These days they’re all web-based, and none of them support Safari, and I’m not having it, Jonathan.

Aaron Gustafson:
I was surprised the one we’re using today—I’d seen that it required Chrome, but when I opened it in Edge, which is Chromium, it still said “unsupported browser.” All the APIs are the same and yet…

Luke Carbis:
Save yourself.

Jonathan Wold:
Yeah, I’m going to let them know, because I felt the same. Chrome isn’t my primary browser, and it’s a pain to have to switch for something like this.

Luke Carbis:
I’m going to make a WordPress plugin that detects browser and, if it’s Chrome, it says “Sorry, this is not supported.”

Jonathan Wold:
That’s terrible. That’s terrible.

Aaron Gustafson:
Every other browser pretends to be Chrome in its user agent string anyway, so good luck figuring that one out.

Luke Carbis:
Okay, great. I want to circle back to something you were talking about earlier—building solid websites, not relying on percentages. I love the idea. I’ve often thought about ditching WordPress and just writing really basic HTML. But what about all this new JavaScript tech that’s mainstream now—ES6, JSX, all the compiling, the whole process of running webpack? When it comes to that, if that’s the standard, don’t you have to take into account percentages?

Aaron Gustafson:
I think it’s all a constant pendulum swing. We race out ahead—like with AJAX, for instance, back when Google Maps launched—everyone rushed to do that. You saw the skeleton site approach: the page is totally unusable until JavaScript kicks in. Then we realized, oh, that’s not great. A good example: years ago Gawker Media rewrote everything as a single big JavaScript app. When they flipped the switch, a single JS error broke all their sites—they just hung indefinitely. We race after these things (React, Ember, Backbone, etc.), but then run into problems: SEO, performance, RAM usage on the client. There’s a push-pull between developer convenience and user experience. Right now, there’s a lot of focus on developer convenience—how quickly we can write and deploy apps—but we’re shoving tons of JavaScript to clients who may be on low-end devices.

I spend a lot of time with PWAs (Progressive Web Apps), thinking how a PWA could offer, say, a widget—but what if every widget loads React? You’re going to crash people’s browsers. We need guardrails. That’s why there’s a swing back to server-side rendering—how do we get the best of both worlds? I think there are interesting explorations there, building robust sites that work all the time, with the zippy feel of a SPA (single-page app).

Jonathan Wold:
A couple years back, Luke and I started shifting our thinking to the open web more broadly. So, what does “open web” mean to you? For me, it has a few core characteristics: accessibility (anyone should be able to connect), creatability (your ability to create on the web; open source matters here), and the ability for people to connect without walled gardens. What are your thoughts? How do you see the open web?

Aaron Gustafson:
That resonates with me. I think, like Microsoft’s inclusive design guidelines say, when we design for people like us, we exclude everyone else. Accessibility is part of that. But also thinking about life situations, cognitive load, and the fact that we’re recording this in a pandemic—people are stressed. When we’re stressed, we don’t read as well, so writing and conveying info matters. The ability for people to contribute is also vital. And I see a third piece: extensibility and interconnectedness enabled by an open web.

There’s the capital-S Semantic Web, which Tim Berners-Lee and others worked on. It hasn’t fully flourished, but with things like microformats or schema.org, we can do so much if the information is there in the markup. For example, I built an email template that used microformats to let people add an event to their calendar right from the email, no ICS file manually needed—just use semantic markup. Or thinking about conversational UIs—I imagine a future where smart speakers can pull headlines from a website because it’s all marked up semantically. If you just use <div> for everything, it’s not possible.

If you think of markup as structured data, you can create amazing experiences, but you have to put in the thought. There used to be CSS Naked Day—do you remember that?

Luke Carbis:
I do, yeah.

Aaron Gustafson:
You’d turn off your CSS for a day and see what your page really looked like—a good way to keep your markup honest. Browser default styles aren’t the prettiest but they’re usable. If your CSS doesn’t load, your site should still work. Reader modes work better with semantic HTML, too.

A lot of times, by creating extra dependencies for what we’re building, we’re just creating failure points. For example: a form button can be an <input type="submit">, a <button>, or you can hack it as an anchor or a div. The first two just work and are accessible; anchors and divs require lots of extra work and often create something that’s not accessible or usable. I never want an interface that looks interactive but isn’t. We need to be mindful of the tradeoffs we’re making.

Luke Carbis:
Redirecting the conversation back to WordPress for a minute, Aaron. I know you’re not necessarily deep in the WordPress world or contributing the way that maybe our listeners are, but you do use WordPress, right?

Aaron Gustafson:
Yeah, yeah.

Luke Carbis:
So, you’re probably familiar with Gutenberg, the new editor. I wonder if you’re familiar with the crisis WordPress is currently facing.

Aaron Gustafson:
There have been numerous crises over the years.

Luke Carbis:
Jonathan doesn’t even know what I’m talking about.

Aaron Gustafson:
Sorry, I don’t know which one you mean. I do remember the huge kerfuffle over Gutenberg accessibility back in the early days.

Luke Carbis:
It’s gotten better.

Aaron Gustafson:
That’s what I’ve heard. I don’t know the current issues.

Luke Carbis:
These days, full-site editing is coming (eventually). Users can log in and change the global styles of their site, rearrange templates, and theme creators are cautious. Remember the rocky Gutenberg rollout? People are wondering, what’s the future of themes? How do themes work if users can change everything, even the header or font sizes? As the community reimagines WordPress themes, what advice would you give—what core principles should guide us?

Aaron Gustafson:
Honestly, this reminds me of the Dreamweaver era. We used to joke as agencies that once we handed a site off to a customer, within six months to a year it would be broken and they’d come back to us—not because they were careless, but because it was too easy to break. So we got specific about what we’d let customers access, and provided explanations and flexibility, but tried to make it hard to undermine usability and accessibility.

From a theme builder’s standpoint (not knowing all the ins and outs), I’d say: have a solid style guide, explain decisions, and offer sanctioned permutations of your design. Create a flexible theme that accounts for how it may need to adapt—like responsive design, but for content and structure. Support the adaptations you expect, but don’t try to stop people from making changes if they want to. It’s like the desktop publishing era—suddenly everyone had 37 fonts on a newsletter. You can’t be too precious about it, but if you care about the end product, think about how it can bend, not break, as people change it. Maybe there will be niche themes built for specific uses, like product pages with lots of flexible options. Build robust experiences that adapt gracefully, not brittle ones that break.

Jonathan Wold:
As we wrap up: WordPress powers a huge chunk of the web, coming up on 50% depending on who you ask. I see WordPress as an indicator of the open web’s health—when something changes in WordPress, it ripples out. You’ve seen standards evolve, you work within a browser team. For those of us who care about the open web and work on WordPress, what guidance would you offer? What questions should we ask? Where should we focus?

Luke Carbis:
And I’ll add: with your work on Edge, how much does WordPress’s influence affect your day-to-day or the decisions Edge makes?

Aaron Gustafson:
For the first piece, I’d say: expand your bubble. Increase your sphere of influence—diversify your social and RSS feeds, listen to other communities, especially people with different lived experiences. That awareness is invaluable for building a product that works for more people. You can’t solve problems you don’t know exist. I’d also say co-design is vital: work with communities. The disability community says “nothing about us without us”—get involved directly.

As for WordPress’s influence on Edge: not a lot directly, but we do pay attention to WordPress. For example, when PWAs started to take off, we reached out to the WordPress community—both Automattic and non-Automattic contributors—to help enable easy PWA support in WordPress because it’s such a huge part of the web.

Luke Carbis:
Awesome. Aaron, it’s been such a great conversation. I really feel like you’re my people. I want to tell you about the Ugly Web sometime when we have more time. Thank you so much for coming on Crossword—it’s been a great Perspectives episode.

Aaron Gustafson:
Yeah, this has been a lot of fun. I really appreciate you all having me on.

Jonathan Wold:
If people are interested in learning more about what you’re up to, where can they find you?

Aaron Gustafson:
Probably Twitter is best—@AaronGustafson. I blog occasionally at aarongustafson.com. And if people have ideas or want to write for us at A List Apart, they can reach out to [email protected].

Jonathan Wold:
Perfect. Thank you so much for joining us, Aaron.

Aaron Gustafson:
Thanks again for having me.