Transcript

Jen

This is The Web Ahead, a weekly talk show about the changing web technologies and what they mean for the future. It's hosted by me, Jen Simmons. This is episode 3.

Bandwidth today is provided by Midas Green Technologies, virtual private services submerged in oil.

I want to say thanks to everybody who has been listening and tweeting and telling your friends about this show. It's new, so it's great to have people really excited and getting the word out. I especially want to thank people who have been rating and reviewing it in iTunes. It makes a really big difference having those stars clicked in iTunes and having the reviews. There's just 32 ratings and 12 reviews. If you want, you can jump in and help shape the show. Get the word out. Help get it seen in the iTunes store. It really does make a big difference.

Today I've got Jeremy Keith as a guest. Hello Jeremy.

Jeremy

Hello Jen.

Jen

I'm very excited to have Jeremy. He is the author of DOM Scripting, Bulletproof Ajax, and most recently, HTML5 for Web Designers on The Book Apart label. Jeremy speaks at a gazillion, bazillion events. A lot of people have seen him speak at conferences. It feels like you are one of our big teachers, getting us all figuring out what's going on and setting us straight. Helping us understand what's going on.

Jeremy

It's more like, it's hard to shut me up. I like to geek out about stuff. If I can get a captive audience, that's always good.

Jen

Well, I love it. [Laughs] I'm sure other people do, too.

I feel like there's a bazillion things we could talk about. You're always talking about mobile, the web and HTML5. I feel like you can help us get an idea of what it means for the web as a whole, for business and for us nerds who like to pick elements out of a list of elements. [Laughs]

Jeremy

[00:02:07] I don't know. I'm not very good on the business side of things. I'm much, much better on the nerdy, element-picking side of things.

Jen

Yeah. [Laughs] I think the first question is... Mobilewood. What is this? We're seeing pictures of people in this space helmet all over Twitter. It sounds like Mobilewood was awesome.

Jeremy

[00:02:26] It was awesome. It was a gathering, a meeting of minds. There was a conference in Nashville — more like on the outskirts of Nashville — called Breaking Development. It was a really good conference. It was the second one. They did it earlier this year in Dallas. The third one will be next year in Orlando. Highly recommend getting along to it. Really good conference that's put on by people who really want to know about mobile. They're doing it for the passion of it, rather than just trying to make a buck.

There were a whole bunch of people at the conference speaking and attending. It seemed like a good opportunity to get together. I think it was Luke Wroblewski and Josh Clark, the movers and shakers behind it. They decided to extend invitations to a bunch of people to try and stay on for a few days. They rented a cabin in the woods of Tennessee. A whole of bunch of us went out there. It ended up being 10 of us. Some people couldn't make it to the conference, unfortunately.

It could have gone either way. It could have gone really awesome or like The Shining meets Deliverance. [Jen laughs] We all could have ended up killing each other with axes. But as it turned out, it was great. We had a lovely time.

Luke did a really good job of structuring the time and making it productive. There was a lot of brainstorming. There was a lot of hacking. A lot of discussion. And there was a lot of hanging out in the hot tub and sitting around the fire playing music and drinking, as well. We worked hard and we played hard. The end result was the Future-Friendly Web — which is the first step of what has come out of Mobilewood.

Jen

I'll put future friendly in the show notes for this episode. People who don't know what the show notes are — if you go to 5by5.tv/webahead, there's a page for each episode of the show. There's a bunch of links we talk about and point to.

I'm sure there are a lot of people who would have loved to have been a fly on the way at Mobile Wood just to be able to hear a collection of people ask each other questions. It feels like there's so many things changing right now. A lot of people are working hard just to keep up.

Jeremy

[00:05:06] That was definitely the consensus from just about everyone there. Things are changing really fast and constantly. Nobody thought they had a handle on what the hell to do.

Jen

Yeah. What kinds of things do you feel like are the edges? Are there edges where people are not sure about what's happening yet and trying to understand, trying to figure it out?

Jeremy

[00:05:35] The obvious one is the shear diversity of devices. The diversity of screen sizes would be one edge. But even that's only one metric. You've got the diversity of inputs, right? Whether it's keyboard, touch or gestural. Moving beyond screens, all sorts of devices that might not be outputting on a screen at all.

These feel like the obvious places to see that things are changing, and changing very rapidly. What they point to is general diversity in everything. Input and output. Network speeds. In addition to the devices you'd be accessing the web on, the infrastructure that you'll be using to get to it.

Jen

It's clear that there's so many different... I think a lot of people have been joking around. I've been joking around that once web developers and designers get their heads wrapped around the Android market, they're going to wish that IE6 was their worst nightmare. [Laughs]

Jeremy

[00:06:46] Oh yeah. If you thought desktop web development was hard, it's nothing compared to mobile.

A couple of years ago, Douglas Crawford described front-end development. He said, "It's the most hostile software development environment there is." Then later on he said, "Yeah, that was before I discovered mobile." Having to think about Firefox and Chrome and Safari and IE... that's a walk in the park compared to thinking about all of the different mobile devices and browsers out there.

Jen

Especially since we can't afford to buy them all.

Jeremy

[00:07:19] Yeah. That's one of the obvious problems. How the hell so we test on this stuff without bankrupting ourselves? There's an interesting initiative going on in Portland as part of the Mobile Portland series of events. Some people from Cloud Four, Jason Grigsby and some others are setting up a nonprofit to eventually get a testing lab going. You could walk in there and try out devices and browsers and walk out again. I really like that idea. Instead of every single company having to get every single phone, if we could get it so every company got a couple of phone and we all agreed to share our phones, then we could come up with a pretty good test environment.

Jen

I've been seeing coworking spaces starting to think about this.

Jeremy

[00:08:06] I've been thinking about it. Here in Brighton we have a good coworking space called Skiff. That would make a good base of operations for something like that. If everyone agreed to bring in their devices for testing. It could work well.

Jen

I have seen of the presentations you've been doing. I know you have a lot of ideas about how to deal with this problem of, "I need a website. I'm building a website. There's 12 different desktop browsers to support. Now there's an infinite number of mobile phones and browsers to support."

Jeremy

[00:08:43] Although, I think a lot of the problems come because people want to have their cake and eat it, too. The truth is, you want something to be accessible on any device — desktop or mobile. No matter what the capabilities of the browser.

You can do that. You can do that pretty easily by writing an HTML document. Straightforward HTML. Use links to hyperlink to stuff. Use forms for input. That will work on any device. A crappy feature phone, a good smartphone, a good desktop browser. That will work.

The thing is, when people say they want something to work, what they mean is, "I want it to work in the way that I envision it. I want it to work really nicely and be a really good experience on all of these devices." That's where people run into trouble. They think about the optimal experience, usually thinking about one particular device, like desktop or the high-end smartphones like the iPhone. Thinking of that as the baseline.

That's why they get frustrated. Why can't they make it work on these other devices? Why can't they make it work on this browser or that browser?

Well, you can make it work in all those browsers pretty easily. The problem is that you want it to be all bells and whistles in every browser, on every device. That's a much tougher proposition. The secret is learning to let go of that expectation. That feeling that, "I have to be able to control everything." Say, "Nope. Let it go."

Jen

That idea that everything has to be pixel-perfect and identical on every browser, and everything will look like a Photoshop comp.

Jeremy

[00:10:17] Exactly. We've been battling against that mentality on the desktop for a few years now, anyway. Hammering home the point that websites do not need to look the same in every browser. Generally, the battlefield there has been rounded corners and gradients. Fairly cosmetic differences.

Whereas this is something deeper. This is about analyzing what it is that this page is for. What the site is for. What's the content? What's the task the user is trying to accomplish?

Getting beyond the form of it. How it's going to look, how the input or output is going to be. Just think, "How can I make it so that every single person, no matter what device, no matter what browser, can accomplish their task?"

The answer inevitably involves letting go. It doesn't mean you can't make it look and work beautifully in the most capable devices. I think that's absolutely possible. But only if you approach it in that kind of progressive enhancement way. Where you enhance for the best devices and best browsers. When you start thinking of that enhanced version as the default, that's when you run into frustrations.

Jen

It seems like a lot of people are coming to the same conclusion. Somewhere in there you said the most important thing, that the person can do the thing that they want to do. You're getting back to the content and getting back to the reason that it exists in the first place. Why does this thing exist? Why does this webpage exist?

It seems like all of the web designers, the leaders right now, are saying content-first, mobile-first, progressive enhancement. It feels like clients — and all of the different flavors that they come in — are having a really hard time understanding that. I don't know if it's that they haven't heard yet. Or if there's something more complicated going on.

Jeremy

[00:12:20] I'm not so sure. I think, quite often, we tend to blame the clients for a lot of stuff. Or we assume the client won't get it. But if you talk to them, they can be pretty savvy about this stuff.

You have to remember that their world is changing, as well. They would have gotten a new phone in the last six to 12 months. They will be using a different device than they were a few years ago. They understand that the world is changing. I do agree it can be tough to convince them of the benefits, if it's all theoretical.

It reminds me: when we were all moving to web standards and separation of presentation and structure, that was about getting back to the content, too. We were approaching it more from the presentation side back then. What made it easier to sell was being able to point to sites that had done it. As soon as wired.com or espn.com had made the switch over to separating the presentation and structure, it was easier to sell people on it.

You get that to a certain extent now, with something like The Boston Globe. Where you can point and say, "See what they've done here? Try it on any device. See how it just works." Show that these aren't just possibilities, these are things that are being done today.

Jen

Responsive design and the content-first, mobile-first approach seems so exciting and fun. I've talked to some clients where they came asking for a mobile website. Like an m.something. Talking to them, talking about the pros and cons, they ended up saying, "No, that's not what we want. We want responsive."

Jeremy

[00:13:58] Right. I've even heard clients saying, "We need an iPhone app." But if you talk to them and talk through what they need, it's not necessarily an app as in a native app through the app store. They want their stuff to work on an iPhone. But the language is to say, "a native app" or "an app." But they don't necessarily mean it has to be through an app store.

Jen

Even if they came saying, "I want what The Boston Globe has." They might even think that's a separate mobile site or app.

Jeremy

[00:14:28] Right. Really, they shouldn't have to care about the technology at all. It's not their job. It's our job to figure out the best solution for them.

Jen

How do you think all of this — changing the design process, the process of imagining a website and getting to the place where there are documents to go build it out.

Jeremy

[00:14:48] I think all of this is increasing diversity, increasing browser and device landscape. It's actually highlighting how broken our processes already were. I don't think it's the case that, "We've been designing websites like this for 10-15 years and now we have to scrap everything. It was working great and now we have to change the way it was working."

It's more like, we've been designing websites for 10-15 years and it was never working that great. Now it's being thrown into sharp relief how unreasonable our processes were. The truth is, it never worked that well to have this split between design and development. Where you have someone who works in Photoshop and hands over a comp to somebody who turns it into HTML and CSS. It's never going to work that way. Things are never going to translate perfectly. Something in the browser is different than something in Photoshop. It's like comparing a photograph to the real thing.

It worked well enough, as long as we pretended we were designing for a certain class of browser with a certain fixed width. But with the diversity of sizes and devices, it's becoming clear that process doesn't work. I don't think it ever really worked that well.

Maybe it will be painful to change those processes. But it's a good thing. Those processes needed to change. This is the kick in the pants that they needed.

Jen

How are you imagining a process that works well? What does that look like?

Jeremy

[00:16:23] What has worked well in the past — and will continue to work well in the future — is paper. Paper is a great way to start anything. What's tricky is to try and break free of the mental model of thinking in terms of fixed dimensions. Even on paper, that can be tricky. You're thinking, "The search goes in the top right. The logo goes in the top left." These are spatial things, depending on a fixed canvas. Paper is generally good.

Photoshop and Fireworks can be good, too. But we often tend to stay in them too long, beyond the point of usefulness. I think there's diminishing returns for how useful they are. Getting into the browser as quickly as possible is key. Just prototyping as quickly as possible.

Jen

Designing in HTML and CSS.

Jeremy

[00:17:11] Yeah. Getting it into a browser so you can feel it. Feel whether you're on the right track in a browser rather than going through all of that effort in Photoshop.

A technique I think works quite well is style tiles. Samantha Warren has been talking about them. That's where you do use Photoshop or Fireworks or whatever to put together, not comps, but a collection of things to evoke a mood. You've got things like mood boards, rights? But they're kind of wishy-washy. They're not that connected to the final website itself. Then you've got full-on comps that you do in Photoshop or Fireworks. Those are too close. They're too detailed. You've wasted a lot of time on all of that detail when you should have been getting into the browser.

Style tiles are kind of halfway between the two. Style tiles themselves aren't that valuable as a deliverable or resource. They're more valuable as a tool for engaging the client in conversation. Trying to figure out, "Is this the font you're thinking of? Is this the mood you're going for? Is this evoking the right look and feel?" Without getting into the specifics — it's three columns, the logo is in the corner. Without getting into the specifics, but talking about mood and tone of voice and fonts and colors.

Style tiles have been really valuable. That's something you can use Photoshop and Fireworks for. I've heard of people looking at making a tool for style tiles in the browser. If that's what you're faster with, that could work well, too.

Jen

I love the idea of designing pieces of content without thinking about the whole canvas. Or thinking about how that content fits with anything else. You know you're going to have a little list of news items. There's going to be a thumbnail to go with those news items. Just do some sketches. Do some Photoshop comps, or HTML and CSS. Almost like a style guide. In the old school process, it's like, three weeks of Photoshop documents and after that's done and locked, then someone makes a PDF that's your style guide that annotates some of that. It's almost like starting with the style guide.

It reminds me of the work that Mark Boulton has talked about, too. Just think about that one piece of content. Figure out what you want that to looks like. The visual hierarchy. The visual treatment. The feeling. The colors. The ratios. How big it should be. Then look at how that's going to grow or shrink from screen size to screen size. Then think about the other pieces. Then start to figure out how those pieces go together.

Jeremy

[00:20:15] That's pretty much exactly that way I've been working now. Start with the bits. Start with the atomic pieces of your content. Not think about the container those bits will find themselves in. Who knows? That container could change. Even if I'm working on a project where it is a very traditional, "Here's a Photoshop mockup that's 960px wide," or whatever, I'll still take the pieces out. Break them free of the column they were in. Turn them into HTML and CSS and make sure they survive outside of that context.

First of all, if you use CSS, it's making it really robust. It's that idea of object-oriented CSS that Nicole Sullivan talks about. Making sure these individual bits will work anywhere regardless of context.

I end up making a page full of these bits. It's exactly like you said, it's like a style guide. It's got headlines, bullets, breadcrumbs and pagination. But not inside any particular comp. You could later slop them into a wide column or narrow column anywhere on the page and know it's going to work.

One of the nice side effects of working that way is this page of all of these bits, it almost acts like a unit test case for your CSS. As you get further into the process, your CSS gets more complicated and you're adding layout, just hit refresh on the page. Quickly glance and see if anything broke. It's got some benefits from the testing point of view as well.

Jen

It's just so backwards from print. What do you do in print? The first thing you do is decide how big your piece of paper is going to be. You think about how it's going to run through the press, what size of paper you're going to order from the printer and how you're going to get it chopped down in a way that's going to be affordable. Then you've got your piece of paper. Does it fit the mailing regulations, because it's going to go through the post office? Then you start fitting stuff onto that and figuring out how big stuff can be based on the edges of the piece of paper and where that knife is going to cut them.

Jeremy

Right. That makes total sense for print. You do know those dimensions.

Jen

We inherited that from the print world. In Photoshop, the first question is, "How big is your canvas?"

Jeremy

Exactly. The first thing you do is type in a width and height. You've made a fundamental design decision right at the start.

Jen

What you're describing reminds me of working in something like Illustrator. Getting away from the pasteboard. There's this pasteboard floating in the middle of the Illustrator canvas. But you can shrink and make it really small and take out your objects and draw them all over the place, floating in space. Then put them back into the canvas when you need to export them.

Jeremy

[00:23:09] For this page of patterns that I do at the start of a project, I'll have that page loaded and I'll change the browser size. Make it really narrow, make it tall, make it long. Ensure the content works no matter what size the browser window is. It is kind of like that process in Illustrator.

Jen

Have you created a library for yourself that you're able to reuse?

Jeremy

[00:23:33] I have one little PHP script I've written. I'll have a folder that I'll drop these patterns into. Literally, a little piece of HTML with an HTML extension. The PHP script goes through that folder and pulls them all out, displays them on the page, and displays a text area next to it with the HTML. It makes a nice deliverable for the clients. I should put that out there. I should put it on GitHub. It's really bad PHP I'm sure. I'm not much of a programmer. But it makes a nice overview of all of the patterns in an easy, cut-and-paste deliverable for the client.

Jen

It sounds cool. It sounds like people will want to check it out.

Jeremy

[00:24:17] What we communicate a lot at Clearleft is that we're not building pages for the client. We're building a system for the client. The whole thing, "Give a man a fish or teach a man to fish." Instead of us churning out individual pages for you, we're going to construct a system so you can make as many pages as you need. I think that first step on that system is all of these atomic bits and making sure that they can work inside any part of that system.

Jen

It seems like a remarkable revolutionary time to me. I think because these different conversations are suddenly coming together. This idea of designing a system instead of a page is something we've been fighting with, thinking about CMS', for awhile now. We're not building you a pile of pages that are linked together. We're building you a design that's going to sit on top of a content management system. You can do all kinds of crazy things with the content you enter into the system. It's going to build hundreds of thousands of pages for you. We don't need to draw hundreds of thousands of pages.

Samantha Warren and her style tiles ideas. Mark Boulton and his design the content grid first, not the page grid. Nicole Sullivan with object-oriented CSS. These different conversations are actually saying the same thing.

Jeremy

[00:26:01] It's been remarkable to see these different communities merging together. You've got the people on the mobile side, people who have been doing mobile for many years. Living in that world of pain. You've got people on the content strategy side. They're meeting each other because they realize what they're talking about is much the same thing. This idea of content-first. Structured content being really powerful.

Like you say, because of the diversity of devices and screen sizes, we're realizing there's problems with the tools, in terms of our processes as designers. There's big problems with Photoshop and Fireworks as tools for trying to design something that's going to live in the browser.

At the other end, the other tools are the CMS' that the customers are going to use to put the content onto the site. The way we've been thinking about CMS' for years. That CMS' were really great and now we have to rethink them. It's more like, the CMS' were never that good and now we're realizing that they were never that good. Again, it's being thrown into sharp relief.

The way that most CMS' treat content as a textarea. Dump your content into this textarea. That's not going to work. In the same way that WYSIWYG tools on the design side weren't true to the web. would even lump Photoshop into that category. I think a lot of CMS' haven't been true to the web either, in attempting to impose that WYSIWYG mentality. WYSIWYG editing tools on the CMS side were kind of lying to the person who's trying to input the content.

Jen

Yeah. And they break the designs.

Jeremy

[00:27:54] Again, because people are trying to exert that control. I think the secret is to let go of the control. Think about, "What is the content? What is the nature of the content?" The structure of the content being more important than the appearance. The function being more importance than the form.

With CMS', it's definitely a pain point. I got into quite a few discussions about that at Triple Con in March.

Jen

What do you think the web is? I know that's a really weird question. What is this thing called the web?

Jeremy

[00:28:36] On a fundamental level, it's resources — most of which are HTML, but not necessarily — that are delivered over HTTP. That's the protocol. The really important thing is those resources are addressable. They have URLs. It's the combination of those three things. HTTP + URLs + mostly HTML. That's the web.

Everything has a name. Once you know the name, you can link to it. That's the other crucial thing about the web. You can link to it and you don't need to ask permission to link to it. The web doesn't have two-way linking. Which means things break all the time. We get link rot and all that. But it means anybody can create a page that links two different resources that were never linked to before, ever. You've created something new just by linking to things.

Jen

It seems like we've been using the web in a couple of different ways. We've been using it as a very fancy, complicated brochure. A chance to read a lot of information or look at photos or watch videos. We've also been using it for communication and sending messages back and forth, a two-way communication. We've been using it as a store. You can buy stuff. You can put your own things up. Where is this technology going to take us? We have HTML5, CSS3, mobile practices, all of this new stuff. Where might we be going with what these HTML files and URLs and HTTP protocols?

Jeremy

[00:30:22] I think what you're saying points to the fundamental truth of the web right now. Which is that there are two kinds of time on the web. There's the real-time web; those messages being sent back and forth instantaneously. Two-way communication connecting people. Which is fantastic. There's the long-term web; resources sitting at URLs, waiting to be called up. That's the store.

Robin Sloan, who works at Twitter, he has a nice way of putting it. He talks about this as the flow and the stock. The flow is the instant stuff. The status update. It's what you're doing. It's the actions right now. The stock is the stuff that endures over time. The stuff that you find through search. The stuff that you published and is still available. We tend to concentrate on the flow a lot and less on the stock. Which is a bit of a shame, because I think the stock could be really important.

The other thing — this is something Matt Ogle talked about and recently I saw Frank Chimero talk about this at dConstruct. The flow is in itself a good source of stock. All of your check-ins and tweets and instantaneous updates, over time, end up forming a narrative. They're all timestamped, and sometimes with location. Taken as a whole, they form this kind of store of your life. They form this narrative. I think there's a lot of emphasis on the flow right now. When people talk about the exciting technologies in HTML5 or standards, they're emphasizing the flow. Things like Web Socket. I think the stock is really important too.

If the web were just about real-time communication, the URLs wouldn't matter as much. But I think URLs do matter.

Jen

We see services like Twitter putting a pound sign in the URL. The URLs don't really exist anymore.

Jeremy

[00:32:39] The whole hang bang thing is such a mess. I firmly believe that Twitter will switch over to using proper URLs and using HTML5 history state, which will allow you to do exactly what they want to do and maintain proper URLs. I think they're just waiting for whatever browser support they deem acceptable.

The problem is, they're still going to have to maintain a client-side redirect service for eternity. People have been copying and pasting those links into blog posts and other documents. If they switch over to one system and disregard the system they've been using up until now, they've broken a bunch of links.

It's kind of depressing, the whole hash bang thing.

Jen

You've done presentations on archives. The need to have a better archival system for the web. Concern about people taking down really important sites.

Jeremy

[00:33:46] I think the biggest issue isn't that we need this kind of organization or this kind of technology. I think the biggest issue is acknowledging the problem even exists. Because most people have completely the wrong mental model of the web.

There's all of these truisms: "Google never forgets," "Once you put something on the web, it's there forever." You'll hear this stuff repeated over and over. It's unquestioned. It's like, "Eskimos have 50 words for snow," or, "In Columbus' time, everyone thought the world was flat." These things that sound perfectly reasonable but are completely false.

Some people will go around saying, "Once you put something on the web, it's on there forever. Google never forgets. Facebook never forgets." Whereas the evidence is overwhelmingly the opposite. The chances of something surviving on the web diminish greatly over time. Especially if its a single URL. It's going to get lost. That URL will go offline.

I think the biggest issue is simply acknowledging it's a problem. Acknowledging that just because you put something on the web now doesn't mean it's going to be on the web forever. There's a lot of really important information being put onto the web. From educational institutions, news companies, various bodies. They seem to think, "We're putting it online. There. We've stored it." Actually, it takes a lot of work to keep something online. Putting something online is pretty straightforward. Keeping it online takes work.

Jen

Do you see archivists talking about these issues? Librarians and such?

Jeremy

p [00:35:28] Yes. In fact, there's an event happening in the UK next Friday that I hope to get to. It's about digital preservation. They do talk about this stuff, although it tends to be kind of insular; they're talking to other librarians. They're talking to other institutions.

The other issue is they're used to a more institutional way of doing things, which is a centralized way of doing things. We have great institutions like archive.org. That's fantastic and they're doing amazing work. But it is centralized. It's a single point of failure. If you look at all that's great about the web, it's the decentralized nature. There aren't single points of failure.

The approach that seems to make the most sense is something that comes from a Stanford digital preservation study. Which is this idea of LOCKSS: Lots of Copies Keeps Stuff Safe. The internet is a copying machine. Making copies is really easy on the internet. I think we need to make use of that. Make multiple copies of stuff. Keep things in multiple places.

We tend to run into other issues that aren't technical. The whole idea of intellectual property. Something that people bring up all the time. This idea of ownership of something when it's digital. Ownership of a canonical thing even if that thing can be copied without having any affect on the original thing. You could have a million copies of something and it doesn't affect the original thing, as long as it's digital. Yet we still have this idea of protecting that original copy, that it's somehow stealing to reproduce that second, third or fourth copy and put it at another URL.

I don't see the biggest problem as being technical. We have a great potential technical solution to archive and store stuff. Which is, we have the web, which is built on the internet. We have URLs. Anything can have a name and everything is addressable. The technical solutions are there. It is more the mental and cultural challenges of 1) seeing there's a problem and 2) approaching that problem in an internet-centric way, as opposed to an atoms-centric kind of way.

I think the technical problems aren't actually that hard. There is one point of failure on the web, in terms of centralization. I think everything good about the web is decentralized. But if you think about domain names, that is still centralized to ICANN. I'm not saying there's a better way to do it. I don't know if I could propose a better way. I'm simply pointing out that is a centralized point of control on the web. The other thing with domain names is, ideally, you put something at the URL and it would stay there. But we don't own domain names. We rent domain names. We rent them in terms of 1 year, 2 years, maybe 5 years. That's a long-term as we get on the web. It's not that long.

Jen

It's hard. I think many of us nerds have put up a lot of websites and it's like, "Well, do I really want to keep paying $10-15 a year for this website that was for this project or event that's over?" I've let more than one domain expire just because I don't want to spend $15 a year to keep old stuff up.

Jeremy

[00:39:06] That's the thing. We are tenants to domains. Which is a bit of a shame. On one hand, the web is this amazing resource, but then practical issues like finances mean that some resources don't survive.

Jen

It's complicated. I think it becomes so easy to put everything up that there's no sense of hierarchy. There are so many words.

Jeremy

[00:39:37] I'm actually ok with that. I think that's fine. We invent tools to solve that problem. That's how Google was invented, right? To make sense of the explosion of content that happened on the web. I'm ok with putting everything up. We'll figure it out later.

Otherwise, someone has to make that judgement call. What deserves saving? What might deserve saving for you, I might not think is worth saving.

You see this at institutions — again, back in the world of atoms rather than bits. At the British Library, they pretty much keep every book that's published every year. But a certain amount of years later — I don't know if it's 10, 20, 25 years — they have to decide what percent — 1%, 10%, or whatever percent — they can physically keep in the archives. The rest has to go. You could miss something that could be really important. Maybe not to everyone. But to one person. One person might have that connection. I'm more in favor of saving it all and we'll figure out the tools for finding the important stuff.

Jen

I think when books were first invented, they were so precious. It was such an incredible amount of work to make a book. You just kept them all. Then they became easier and easier to make. But still, 100 years ago, there were these gatekeepers that prevented... not just anybody could make a book. A lot of people weren't literate. Now it's become much easier for anybody to make a book. The Library of Congress in the U.S. used to have the mission of "every book."

With Twitter, for example, I've seen a lot of people be upset about tweets disappearing into the ether.

Jeremy

[00:41:35] That's the clash of mental models right there, between the flow and the stock. If you think of tweets as being phone calls, you're not upset at the idea that they disappear after three weeks. It was a moment in time that's gone. But if you think of them as being resources that are contributing to an ongoing narrative, then you're rightfully upset that three weeks later you can't find that tweet.

Jen

It's a really interesting divide, I think, between the way people think about Twitter. I'm not worried that every sentence I utter when I'm having dinner with somebody isn't kept for all of humanity's history. [Laughs] I've been thinking of Twitter like that. But other people I know use Twitter as their mini-blog where they're putting a lot of things they think are important or want to keep.

Jeremy

[00:42:32] The other thing is, you don't necessarily know at the time what would have been a significant utterance. It's only 10 years later, you realize, "That was the day I first said this." You don't appreciate it at the time.

Jen

Interesting questions. It's interesting to think about. Is the web this store of stock, as you said, that needs to be easy to navigate and find information. How can we better do that?

Jeremy

[00:43:03] I don't think it needs to be an either/or. I think we can have a real-time web and the long web. A lot of the long web will be composed of things that were, at one time, transmitted as real-time communications contributing to the ongoing narrative. I think it can be a false dichotomy to say that web is either stock or flow. It can be both.

Jen

Especially since it is bits and not atoms. You don't have to pay for storage.

Jeremy

Exactly. That's the difference between the British Library and the Library of Congress having to decide what to keep or what to store. On the web, there is no shelf space. Storing this stuff shouldn't be an issue. I think the technical side of things is not that much of a problem. It's a far more cultural problem.

Jen

I was deleting content last night out of my website because I want to repurpose the site. You've got to recycle those URLs. Your /about/ page. It was something else 10 years ago than what it is now.

Jeremy

You could archive it. I've still got one of the original versions of my website from 11 years ago. I still keep it.

Jen

I wiped the first site I had, where I had a blog. I wiped the whole blog. Now it's like, I kind of wish I had that.

Jeremy

It's only in hindsight you realize. As a young person, you want to reinvent yourself all the time. Online you can do that. But later on, you come to appreciate that it's a continuum. Those things said by the younger you were leading towards the later you. You regret losing that.

Jen

What other kinds of technological changes are you seeing that are exciting to you? Things in HTML5 or some of the other new technologies that are coming out.

Jeremy

[00:45:11] I'm a big fan of HTML5 obviously. I've been geeking out about it for quite awhile. A lot of the form stuff in HTML5 is great. It's going to make it so much easier for everybody to have rich, interactive forms without having to learn JavaScript or script a complicated solution. Things like date pickers and sliders and all of this kind of stuff. What I love is they've thought about the backwards compatibility too. They're not just thinking about, "What's this new shiny stuff going to be like in the newest browsers?" At each step of the way, they're also thinking about, "How can we make sure this is going to work in existing, older browsers?" I very much like the design principles that inform HTML5.

CSS has always had that kind of built-in backwards compatibility. In the sense that, if there's a selector or property or declaration that a browser doesn't understand, it just ignores it. It's not going to break. It's just going to ignore it. And that's ok. It's just presentational information. It's not going to make or break the content.

As much as I like to get excited about the new shiny stuff in HTML5 and CSS3, what I really like is that the people making these standards, and implementing these things in browsers, are also thinking about backwards compatibility. Making sure this doesn't break existing user agents.

I'm excited about HTML5. Very much excited about responsive design. There's all sorts of clever, smart techniques coming out every day to deal with some of the challenges there. How do we make our images responsive? If we're going to do mobile-first, how do we make sure the desktop gets the best possible experience? It's an exciting time for a lot of that kind of stuff.

Jen

You were great at educating a lot of people, myself included, about how HTML5 is backwards compatible. I think because of the quirks mode, non-quirks mode world that we evolved though, there was this idea that starting to use HTML5 could make the browser explode for people who don't have a new browser. That's not how it works at all. I still run into people who are afraid of HTML5 and don't want to use it because they haven't taken the time to read your book or understand these design principles or the history behind why it got created. To understand it doesn't make anybody's browser explode.

Jeremy

[00:47:59] It highlights the danger of marketing something as "the new shiny." If you look at it in this new browser, you can do this amazing stuff. When we do that, we miss that you could be scaring people, and they think, "It's only for new browsers. I'd better not use it because my client base is stuck in these older browsers." We should spend more time pointing out, "Hey, you can use this stuff and it's ok. It won't break in the older browsers." I think the term HTML5 itself has become synonymous with cutting-edge, new, flashy, shiny stuff, only for the latest browsers. Which is a real shame.

Frankly, I'd rather just talk about HTML. Forget about the version numbers or the buzzword HTML5. Talk about using HTML. Then it becomes a lot more sensible. Nobody's going to ask, "When is it safe for me to use HTML?" You still have people asking, "When is it safe for me to use HTML5?" Most of HTML5 is HTML4 and HTML3 and HTML2. It's everything that's come before. When you say "use HTML5," well, which bits? Which bits are you concerned about?

Talking about HTML5 as this monolithic thing isn't that useful. As soon as we start talking about it as HTML, it starts to be a lot less scary. "Of course I'm using HTML, why wouldn't I use HTML? Great."

Jen

I find it fascinating how there's so much in the HTML5 specs that's not about HTML5 elements or semantics. Both of those confusions. That people could get worried about the new shiny. Then people who I'd like to see — backend developers, especially — get excited about the APIs, are standing on the side going, "I don't care about the semantic stuff. We're going to use <div>s for everything. I don't need to care about HTML5." It's like, there's a bunch of stuff in HTML5 that you could get really excited about, backend guy or whoever.

Jeremy

[00:50:07] The term HTML5 isn't that accurate for what it encompasses. There's so much stuff. We've been here before with terminology becoming essentially useless. For awhile, ajax had a specific meaning. Asynchronously communicating with the server from the browser. After awhile, it became anything done with JavaScript. You do an animation, "Nice ajax." The word lost all meaning. It's kind of happened with HTML5. Do anything cool looking in the browser, "Nice HTML5 effect." Actually, that was all CSS. But the term has become fairly meaningless. It's a bit of a shame.

It makes a lot more sense to talk about the specific bits. Talk about the forms or the APIs. Which API are you talking about? The web socket? The local storage? What's the bit that you want to talk about? Talk about that, rather than saying HTML5. I see a lot of people who use HTML5 to mean "not Flash." We're going to build this website using HTML5. When you push them on what they mean by that, it comes down to "not Flash."

Jen

What do you think about the elements? HTML5 added these new elements so you can make more semantic markup. I tend to run into a lot of developers who say, "I don't really care. There's nothing wrong with using <div>s. My client is perfectly happy with <div>s. They're not inspecting the code. You might be making Jeffrey Zeldman and company happy, but that's irrelevant to getting the work done for the clients we have."

Jeremy

[00:51:47] It's true enough that the benefits aren't as visible. At least yet. It happens at a deeper level. It's about structuring your content.

I would usually push back on those people. You've got a bunch of links that are navigation for your site. What elements would you use? They'd say, "I'd use a <ul> with list items." You want it to go horizontal. Would you still use the <ul>? "Yeah, I'd just style it to they go horizontal." So what was the reason for using <ul>? Why didn't you just use a <div> or a bunch of <span>s? It can't be because of the default browser styling, because they're overriding that. "Because that's what it is. It is a list. It's an unordered list of items. That's the right element to use."

It's the same with <section>s and <article>s and <aside>s. It's the right element to use.

As to pointing to a concrete benefit, that is hard. I'm not sure there are concrete benefits just yet. These will be benefits for edge case uses like screen readers and search bots. But it's not as visible immediately in the same way as CSS or JavaScript.

It's about the structure. But it turns out that people do care about the structure. The same people who are like, "I'll just use <div>s and <span>s." Look at their content and they're using paragraphs and lists and H1s and H2s. If you push them on why they're using those elements, they won't be ableto give you a good answer apart from, "It's the right element to use."

But I agree it's hard to sell people on the benefits of that. Other than, "It's the right element to use."

Jen

It's about craftsmanship for me. I like quality work.

Jeremy

[00:53:39] There's a danger going the other way, when people start to treat <div>s as something evil that can't be used. They swap out all their <div>s for <section>s and <article>s. Not realizing the effect that can have on the document outline that's seen by an HTML5 compliant browser or screen reader sitting on top of that browser. It would have been safer, in some ways, to stick to <div>s, which have no effect on the outline, than to suddenly start using these powerful pieces of content, like <sections>s. Which can make your outline look much different than you'd expect.

Jen

Talk about the outline a bit. What that is. I feel like a lot of people don't know.

Jeremy

[00:54:20] It's tricky. It's really tricky to explain. I'm not sure I can do it in an audio way. [Both laugh] I probably need a white board and marker.

It's about treating your content atomically, or thinking about documents within documents. There's a new type of content in HTML5 called sectioning content. A <section> element is the simplest example of that. <section>s, <article>s, <nav>s and <aside>s. They're all specialized forms of the <section> element. Anything within one of those elements is a mini-document itself.

One of the repercussions of that is when you open a new piece of sectioning content — like <section> or <article> — you could begin with an <h1> if you wanted. Or an <h2> or <h3>. It doesn't matter. You don't have to think about the hierarchy outside the section. You can structure these things like miniature documents. They can have their own <header>s and <footer>s. Headers and footers aren't something you just use at the page level. They're something you use at the section level as well.

That means when you slop them into a bigger document, the browser takes care of figuring out the outline of the document, based on this stuff. There are powerful repercussions for content management systems. You can think about a piece of content as a stand-alone article. As a stand-alone section. It could appear in multiple places. It might appear on the homepage, it might appear on its own URL, as the main content of that page. With HTML5, you can use the same structure to describe it in both places.

How the outline is generated, the algorithm for that, is kind of complex. It's useful to know because you understand how a browser will see your page. But I don't think I could explain it over audio.

Jen

It's fascinating to me. It has huge implications for accessibility. Content ending up in other places away from the webpage itself.

Jeremy

[00:56:34] Exactly. Exactly. Thinking about the content as a stand-alone thing that could be part of a large document or could stand by itself. It's very, very powerful.

Jen

These tools like Instapaper, Readability or Read Later. I know we keep saying this, we keep saying, "There's this new tool that's going to be able to magically scrape this content and semantically know exactly what it is and make it magically appear in other places in fabulous ways." It feels like it's never quite some to fruition in the way we've been imagining.

Jeremy

[00:57:10] It's always been hard. Especially with things like widgets. You want to give somebody a piece of code they can put in their site on their sidebar. You run into all sorts of problems with the styles leaking in and out of that widget.

HTML5 has some ideas for solving that problem, too. There's a scoped attribute you can put on a style block. It's all about seeing your content in this atomic way.

In a way, it goes back to ajax. This idea of pulling in content from another place, into the existing document. We talk about it in terms of semantics and document structure. It's a very application-centric way of looking at things. How can my app location pull in this stand-alone article?

Jen

For me, it's about thinking about the web in the long-term. We're building out stuff now that's going to be read by browsers and devices and whatever — refrigerators — five years from now. We might not know why marking this up properly is a benefit. Three years from now, it might make a huge difference when people are trying to do X, Y or Z.

Jeremy

[00:58:30] That's the thing. The benefits aren't immediately visible in the same way some of the JavaScript APIs or CSS properties are. Like you said, it's about the craftsmanship. It's about going deeper. Really understanding the structured content you're putting out in the web.

Jen

Sometimes I see developers resisting it simply because they haven't learned about it. I find it interesting. This is complicated and cool, and you guys love complicated and cool. Sometimes HTML is like the stepchild.

Jeremy

[00:59:05] A lot of people treat HTML like, "That's easy. There's nothing complicated there. It's not worthy of my attention because I'm a real programmer." Actually, I think you have to understand HTML well in order to do CSS or JavaScript well. You have to have a well-structured document in order to get your hooks into it. I really believe that CSS and JavaScript needs to be subservient to HTML. I firmly believe it's the most important skill you can have.

Jen

Today, Firefox 7 came out and I'm starting to hear a lot of stuff about IE 10.

Jeremy

In the time that we've been talking, Firefox 8 probably came out too. [Jen laughs] In the time that I've been saying that sentence, I think Firefox 9 came out.

Jen

So what do you think of all of this? Is Firefox stepping up its speed of pushing new releases?

Jeremy

How big is a ball of string? What's a new release? If we had some measurement for what it meant. It's a different number. Chrome does it all the time and it's fine because it's invisible. In Firefox, it breaks a bunch of my plugins and that's a bit more annoying. I don't know. It seems to be the latest pissing match for browser makers. Who can get to the highest number

Jen

Firefox is going to be dropping their number, at least publicly, as soon as they can. They're transitioning expectations from how it used to be to how they want it to be. I think they want to get to where Chrome is. To be able to iterate something, do three weeks worth of work and push it. Instead of doing three weeks worth of work and sitting on it for six months while they wait.

Jeremy

[01:00:46] I think the Chrome model is the best. As long as there's good code quality maintained. It seems crazy that we haven't been doing this. That we've had to encourage people to upgrade their browsers. Why doesn't it just automatically happen? Of all the applications that's going to have an internet connection, the browser is going to be the one. [Jen laughs]

Jen

Of all the ones we need to be updated with support for new things. We don't need a new version of Photoshop. Photoshop hasn't fundamentally changed in seven years.

Jeremy

Exactly. Of all the things that should be automatically updating in the background, the browser is definitely it. It's good to see the browser makers are generally heading that way. It's more of a mess with Internet Explorer thanks to their compatibility view thing. Which means that Internet Explorer 8 is also 8 and 7. Which means that 9 is also 9, 8 and 7. Which means that 10 is also 10, 9, 8 and 7. Each of them subtly different and not like the one before. Because they don't work quite the same way. It's quite a mess.

Paul Irish just did a blog post on this. Pointing out that in a few years time we'll be supporting 72 possible version of Internet Explorer. [Jen laughs]

Jen

I find it fascinating, though. Something tipped so browser makers are competing with each other to be more standards-compatible and get us the new browser faster.

Jeremy

The old browser war in the 90s was not fun. When it was Netscape vs Microsoft. The way they were competing was who can throw the most proprietary crap into their browser. Completely different proprietary crap as well. If you were making websites back then, you remember trying to get the webpage to flush up at the top left corner of the browser viewport. You had to put like four attributes, and two were for Netscape and two were for Internet Explorer. None of them were in HTML at all. That was the kind of browser war we had.

Whereas today, they're competing on who can implement the standards faster. Which is really great. Yeah, it's a pissing contest. Who's got the fastest JavaScript? Who's got the best support for this, that and the other? But I'm happy they're doing that.

Some days I wake up and I think, "This is great. The speed that things are changing in the browsers is going so fast. We're really lucky." Other days I think, "No, things are going way too slow." It depends what you're comparing it to. This is something that Joe Hewitt has been blogging about. You compare it to how things work natively. You compare what you can do in mobile Safari to what you can do in a native iPhone app, for example. The browser seems like a second class citizen because there's all this stuff you can't do it. It's not as smooth. It's just not there. That's a depressing thought. Why is the browser such a second class citizen compared to the native applications?

Other days I think, the fact that we're even comparing the browser to the capabilities of nature apps is kind of amazing. A few years ago we wouldn't have been comparing the browser to your mail client or any other purpose-built native application on the desktop. Now it seems perfectly reasonable. Your mail client will be in the browser. Anything you can do in an application could be in the browser.

I completely vacillate from day to day to being very excited about the speed of change in the browsers and being utterly depressed and thinking things are going way too slow. I hear both sides of the argument on this. I can see both sides. Alex Russell is one of those people always talking about how slow things are going. The W3C and browsers are holding us back. I can see his point. John Allsopp writes about how amazing it is that we've got this interoperability between browsers and they're able to compete on a certain level with native technologies. I think, "That is wonderful, isn't it? Things are good."

Depending on your perspective and what you're comparing it to, things are either better or worse than they've ever been.

Jen

I think there's probably a lot of designers and developers who are overwhelmed with the rate of change. I find it exhilarating.

Jeremy

[01:05:02] This was one of the things Mobilewood was coming to terms with. All of us agree, we're all freaked out by the rate of change. What can we do? We came to the conclusion that what you can do is embrace the change. Learn to let go. Accept things are going to be very different and build for that. Instead of building for the here and now — patching things to work in the latest browsers or this specific browser on that particular operating system — step back and make sure your stuff will work everywhere. Hence the term "future-friendly."

Jen

I see a lot of developers taking old habits and applying them to these new ideas. They're all reaching for device detection. They're all excited about doing responsive design with device detection. [As if ] that's the right way to do it. It scares me. It disturbs me when instead of seeing how to do it with the simplest way possible...

Jeremy

[01:05:56] I tend to favor progressive enhancement where possible and feature detection. Which is more scalable than device detection. With device detection, as soon as you enter into that contract, now you're in an arms race. You're committed to keeping your device detection up to date. New devices come out all the time. You need to keep your device library up to date. It just doesn't seem very scalable.

That said, I don't think there's anything inherently wrong with detecting devices. It's what you chose to do with that knowledge that can be dangerous.

Jen

I think there are times when that's absolutely the right choice. But when that's your first choice and you're using it to deliver and style the content out of the gate...

Jeremy

[01:06:44] I agree. I don't think it's a good default. I think it's a tool you can reach for when you've got no other option. Sometimes that is the case.

For example, Paul Irish maintains a wiki page associated with the Modernizr project of the undetectables. The things that you can't feature detect. In some cases, maybe device detection would be the only way to go there.

I agree. There's nothing inherently wrong with it. But I don't think it's a good default position.

Jen

What do you think people are doing about Android? I've realized there are a bunch of hardware manufacturers that are desperately trying to differentiate themselves from each other by changing Android. Changing the hardware and software. Sometimes even white labeling it and completely changing the software. You think there's only one kind of Webkit and if your website works in Safari on your Mac, then you're all set. The reality is, I think Peter Paul Koch's research shows there are 24 versions of Webkit.

On a lot of these devices, you can't upgrade the software. You buy a phone that's Android 1.6 and that's it. It's always going to be Android 1.6. Even though Android 3.2 is the latest version, those phones are going to stay. I have what I call a "crap tablet" — an Android tablet — on my desk, made by some random company. It doesn't have access to the Google store. There's no way to update the software. It's running Android 1.6. I use it for testing. But every website I ever build is going to have to support Android 1.6 and 2.2, 2.3, 2.3.1, 3.2.

Jeremy

I think as long as you're using progressive enhancement, that shouldn't be an issue.

Jen

Yeah. It's kind of not a big deal. You just check and make sure your font sizes work for when Typekit fails.

Jeremy

As long as you're using feature detection in JavaScript, and if you detect the browser doesn't support something, then don't try and do that. Feature detection is kind of built in with CSS and HTML. Like I said, if you use a CSS property or declaration or HTML element the browser doesn't understand, it just skips over it. As long as your core content is still accessible to any old device and doesn't rely on the latest JavaScript or CSS, then it's going to be ok. It might not look great. In fact, it might look pretty awful. But I think anybody running a really old browser comes to expect things might not look and work great. They should expect to be able to access content.

Jen

Opera Mini. Opera Mini makes everything look horrible.

Jeremy

But you can still get at the content.

Jen

Yes. And that's what people care about.

I think we're out of time. It's been really great to talk to you about all of these different things.

Jeremy

Yeah, that was fun.

Jen

Everybody, you can follow Jeremy Keith. You have a website — you pronounce it Adactio?

Jeremy

Adactio, yes.

Jen

adactio.com where you have a blog and you write fabulous blog posts about all of these things. Your also @adactio on Twitter.

Jeremy

I am.

Jen

People can follow me @jensimmons on Twitter. Someday, perhaps, in a week or two, look at my new website. [Laughs] Go rate us in iTunes. Go rate The Web Ahead in iTunes. Talk to everybody next week. Bye.