Tags: oneweb

Ethical Web Principles

I’ve just added these to my ongoing collection of design principles.

W3C TAG Ethical Web Principles (slides)

The slides from Tess’s presentation on the W3C’s ethical web principles—there’s a transcript too.

Progressively less progressive | Andrew Betts

I agree with everything Andrew says here. Progressive web apps are great, but as long as Google heap praise on mobile-only solutions (like the Washington Post doorslam) and also encourage separate AMP sites, they’re doing a great disservice to the web.

More features arrive regularly to make this “one web” even better and easier to maintain. Service worker, streams, app manifests, payment request, to name a few. But adding these features one at a time to large, mature applications like WaPo or FT or Nikkei is a slow and painstaking process. That’s why it’s taking us a long time for us to tick off all these new features, and why it seems like madness to try and build the entire app several times over.

However, by creating the concept of PWAs and marketing them as they do, Google is encouraging publishers to ‘start again’. And they’re doing exactly the same thing with AMP.

Realizing One Web

A nice look at responsive design, progressive enhancement, and the principle of One Web.

Content Parity | Brad Frost Web

Yet another great post from Brad:

Whenever I think of the concept of “One Web” and providing universal access to information on the web, I tend to break it down into something much simpler: give people what they ask for.

Aral recently released the videos from last September’s Update conference. You can watch the video of my talk if you like or, if video isn’t your bag, I’ve published a transcription of the talk.

It’s called One Web, Many Devices and I’m pretty happy with how it turned out. It’s a short talk—just under 17 minutes—but I think I made my point well, without any um-ing and ah-ing. At the time I described the talk like this:

I went in to the lion’s den to encourage the assembled creative minds to forego the walled garden of Apple’s app store in favour of the open web.

It certainly got people talking. Addy Osmani wrote an op-ed piece in .net magazine after seeing the talk.

The somewhat contentious talk was followed by an even more contentious panel, which Amber described as Jeremy Keith vs. Everyone Else. The video of that panel has been published too. My favourite bit is around the five-minute mark where I nailed my colours to the mast.

Me: I’m not going to create something specifically for Windows Phone 7. I’m not going to create a specific Windows Phone 7 app. I’m not going to create a specific iPhone app or a specific Android app because I have as much interest in doing that as I do in creating a CD-ROM or a Laserdisc…

Aral: I don’t think that’s a valid analogy.

Me: Give it time.

But I am creating stuff that can be accessed on all those devices because an iPhone and Windows Phone 7 and Android—they all come with web browsers.

I was of course taking a deliberately extreme stance and, as I said at the time, the truthful answer to most of the questions raised during the panel discussion is “it depends” …but that would’ve made for a very dull panel.

Unfortunately the audio of the talks and panels from Update hasn’t been published—just videos. I’ve managed to extract an mp3 file of my talk which involved going to some dodgy warez sitez.

I wish conference organisers would export the audio of any talks that they’re publishing as video. Creating the sound file at that point is a simple one-click step. But once the videos are up online—be it on YouTube or Vimeo—it’s a lot, lot harder to get just the audio.

Not everyone wants to watch video. In fact, I bet there are plenty of people who listen to conference talks by opening the video in a separate tab so they can listen to it while they do something else. That’s one of the advantages of publishing conference audio: it allows people to catch up on talks without having to devote all their senses. I’ve written about this before:

Not that I have anything against the moving image; it’s just that television, film and video demand more from your senses. Lend me your ears! and your eyes. With your ears and eyes engaged, it’s pretty hard to do much else. So the default position for enjoying television is sitting down.

A purely audio channel demands only aural attention. That means that radio—and be extension, podcasts—can be enjoyed at the same time as other actions; walking around, working out at the gym. Perhaps it’s this symbiotic, rather than parasitic, arrangement that I find engaging.

When I was chatting with Jesse from SFF Audio he told me how he often puts video podcasts (vodcasts?) on to his iPod/iPhone but then listens to them with the device in his pocket. That’s quite a waste of bandwidth but if no separate audio is made available, the would-be listener is left with no choice.

So conference organisers: please, please take a second or two to export an audio file if you’re publishing a video. Thanks.

• Listen to the audio.
• Watch the video.

Hello everybody.

Does anybody know where this is? Shout it out if you know where this is?

Ghent! Yes, correct! Well done. Are you from Belgium, sir? Welcome. Welcome to Brighton. You’re from Ghent? Fantastic! You have a beautiful, beautiful town in Ghent.

I was there earlier this year and had a lovely time. I was speaking at an event there about the web, about digital preservation, and I really, really liked the place. And I met some lovely people.

This is Benny and Joke from Ghent. They were looking after me, making sure I had a good time. They drove me back to Brussels as well when it was time for me to get my Eurostar back here.

On the drive back, I was chatting with Joke about various things and we got to chatting about music. I play in a band and it turns out that Joke plays in a band as well. She played in a hardcore punk band.

We started talking about the whole hardcore scene and stuff, and all these different bands like the Subhumanz and Citizen Fish—going to see them play at all these different venues—and how inspiring that whole scene is, how egalitarian it is.

Joke said something to me that really resonated. Why she felt inspired to start making music herself—this kind of music—why she felt inspired to create a band, she said the great thing was that with this kind of music, you don’t need to ask for permission. You could just do it. You could form a band.

And as we talked about it some more we realised that’s exactly the same reason why we like doing stuff on the web. Because on the web you don’t need to ask for permission either, thanks to this guy: Sir Tim Berners-Lee. He could’ve made a lot of money from the web. But no, he decided it would be completely open and that you didn’t need to ask for permission.

Here we are, twenty years later. The web is twenty years old this year, which is pretty fantastic, going stronger than ever.

Coming up to the twentieth anniversary of the web, Sir Tim wrote an essay reiterating the design principles underlying the web. He said that the primary design principle underlying the web’s usefulness and growth is universality. That means that the web should be accessible to people with disabilities. It also means it should work with any kind of information, whether it’s a document or a point of data; whether it’s a silly tweet or a scholarly document. And he also reiterated the fact that it should be accessible from any kind of device: small screen or large, stationary or mobile.

The result is this huge tangled mess of a web. It’s chaotic, it’s unplanned, and it’s gorgeous …because none of these nodes on this web needed to ask for permission. That’s what makes it so beautiful.

Every single resource out there has a name, and that’s its URL. And once you know the name, once you know the URL, you can link to it. And you don’t need to ask for permission to link to that resource.

Every other kind of hypertext system that was proposed before then pretty much had some kind of idea of two-way linking. Sir Tim said “No, one-way linking: let’s see how it works out.” Sure, we’ve got problems, we’ve got linkrot, we’ve got all sorts of issues, but look at the result. Look at this amazing web we have.

So the web, I consider to be: resources (mostly HTML) delivered over HTTP, addressable at URLs. HTML, HTTP, URLs. That’s the web.

That means you could take two disparate, completely unconnected resources from over here and over here, and you could write a third resource that links the two of them together, creating something completely new, and you can publish that—and you didn’t need to ask for permission from either of those resources to create that. It’s pretty wonderful: you don’t need to ask for permission.

In the early days of the web, it had some competition from other types of media; CD-ROMS, for example. Does anyone remember Microsoft Encarta? It was pretty cool, it was pretty amazing: you had an encyclopedia on this small disk where previously you had all these books. It was great …but it didn’t scale. Eventually you’re going to need another CD-ROM, and another CD-ROM, and yet another CD-ROM, and you can’t link between them. I can’t link from one point in one CD-ROM to another point in another CD-ROM. These things aren’t addressable. I can’t just link them up (and I need permission).

Well it was CD-ROMs back then. Today it’s iPad apps, iPhone apps, other kinds of native apps: great little things, but they sit in isolation. I can’t link from one to another. I can’t join them up. Thousands—millions—of islands that are unconnected, unlike the web, this messy, tangle of interconnected nodes. It might not be as perfect as those native apps but in aggregate it’s absolutely gorgeous.

People often compare a great native app and say “Oh yeah, try and do that with a web app.” But I think a more fair comparison is to take any native app and compare it with the whole web.

The web is the killer app.

Ask yourself: what would you rather be contributing to—Encarta or Wikipedia?

Something that the internet is good at—not just the web, but the whole internet—is real-time communication. Before we had the web there was email. The web came along and there was a lot of talk about the real-time web. Now we have apps that are connected to the internet making it possible for people to communicate. And that’s great. I’m very excited about real-time communication. Because what the internet has done is collapsed geography so that we can instantaneously communicate from one side of the globe to the other. And that’s fantastic.

But there’s another kind of time, not just the real time, there’s the long time. How long does something stick around? How long will a resource remain?

Well, when something has a name—like a URL—if you take care of it, you can ensure that you are contributing to the long time as well as the real time; that something that’s valuable today should remain valuable next week, and next month, next year, five years from now, ten years from now.

I think that’s possible on the web. I think it’s a lot harder to do if what you’re creating is tied to a specific technology …requires a specific device. When that device goes, your creation goes with it.

Robin Sloan talks about these two kinds of time. He calls them flow and stock. He says:

Flow is the feed. It’s the stream of daily and sub-daily updates that remind people that you exits. Stock is the durable stuff. It’s what people discover via search. It’s what spreads slowly but surely. Flow is in the ascendent today but we neglect stock at our peril.

Steve Jobs once said:

You don’t need permission to be awesome.

And that’s absolutely true …on the web. In the app store? …you need permission to be awesome.

Has anyone here contributed an app to the app store? I’m sure you guys could tell me some stories about what it’s like to have to ask permission to be awesome.

I don’t just mean the app store. I mean any kind of walled-garden ecosystem—it was Facebook apps, it was Adobe Air for a while there—something that’s tied to a specific technology or a specific kind of device. You are now in debt to the company maintaining that.

I see a lot of Flash developers (or ex-Flash developers) moving to making iPhone apps and iPad apps, and I think I understand why it appeals. Because the whole time they were making these Flash creations, these Flash movies, pieces of art, products, services …they were putting them out there on the web but they were never really of the web. They required that plug-in. They were always enslaved to Macromedia (and then Adobe) and they simply saw the web as a distribution mechanism—and that’s fine. They were never contributing to the web so much as using the web to get their creations out there.

So when the iPhone and the iPad came along with its app store, it was simply another ecosystem that they could use as a distribution channel. All they were really doing was swapping one form of lock-in for another form of lock-in. So I understand the appeal there.

Here’s the thing… you might hear me talking about y’know, “Ah, the web the way it was twenty years ago was best and all these new fangled app stores and ecosystems and things …grrr! Get off my lawn, kids!” Right? That I’m being a curmudgeon, that I’m standing in the way of progress, that I’m standing in the way of the evolution of the internet.

I don’t think that’s true. Quite the opposite, actually…

So, the world before the web was a world of atoms rather than a world of bits. The thing with a world of atoms is there’s only so many atoms to go around. There’s limited shelf space in the real world. That means we need systems, we need companies, we need entities do decide what goes on those shelves.

Entire industries have sprung up built around deciding what books are going to get published, what films are going to get made, what music is going to get recorded. Effectively you’ve got companies—corporations—deciding what films you’re allowed see, what books you’re allowed read, what music you’re allowed listen to.

The web came along and smashed all that. Now everything—no matter how big or how small—everything is one link away. I can link to anything; something hugely world-famous or something incredibly obscure. That’s powerful and that threatens the existing ecosystem of control.

So we had publishers and consumers in the old world. We had the controllers and the controlled. Then the web came along and threatened all that.

There are obvious entities that are threatened by this new system. A totalitarian regime—to them, the web is definitely a threat. But it’s not just totalitarian governments that are threatened by the web. Other industries too.

There’s the music publishing industry. The film industry. We hear a lot about newspapers and magazines. All of these entities threatened by the web …these are all the same companies that are really, really excited about app stores.

Why are the excited? Because they see there is a way to turn back the clock, to turn back progress, to bring back scarcity and control, to return to a world of limited shelf space.

Magazine publishers are creaming their pants about the iPad. It’s going to “save” publishing. They think they can put the genie back in the bottle.

So when I rail against these closed ecosystems, I’m not railing against progress. Quite the opposite. I want more progress. I want more disruption. More chaos. More disorder. I want to see things fall apart a little bit more.

That’s why I publish on the web. I put something out there at a URL (it has a name) and it can be accessed from any device, large screen or small, stationary or mobile, colour or monochrome. And it will remain accessible.

I’ve been publishing on my site for ten years now. I fully expect to be publishing in another ten. I’m contributing to the stock, not just the flow. For ten years I’ve been linking to things without asking for permission and for ten years, if you wanted to link to me you didn’t need to ask me for permission, you could just do that. And the different devices, they’ve come and they’ve gone over those years and new devices will come and go but the formats I’m publishing in are open, are standards. Publishing HTML over HTTP at a URL.

So when you’re creating something, when you’re putting something out there, putting your creativity and your talent to work …ask yourself “Why?” What’s your motive? What’s your purpose? See if the medium and the format that you’re publishing in fits that purpose.

The first purpose—I guess there’s kind of hierarchy of purpose—the first purpose is simply to do it for the fun of it. And that’s fantastic. I think we need to do that, to just create stuff for the heck of it, for the joy of creating, of making, of figuring something out. Seb is someone who’s great at doing this. He just makes all sorts of stuff. Brendan Dawes does something new every week just for the fun of it. We need to keep doing that. That’s great.

Then I guess the next level is when you’re doing that as a profession. You’re getting paid for it. Now you’re not doing it for yourself, you’re doing it for your boss or your client. And, y’know, that doesn’t always work out so well. Because if the only reason you’re building something is to please your boss or please your client because they’re paying the bills …well you’re no better than a prostitute really.

The next step up is to do it for the end user. That’s what you’ve been hearing about today, to empathise with the people who will be using your creation, to think about their needs. I think our industry in general has got to that stage where we are thinking about the user, thinking about the people, thinking about their needs. We’re making these things to make their experiences better. User experience is definitely in the ascendent. That’s great. We’ve got a great point.

But there is another level …where you’re not just thinking about the user right now today and their flow, but where you start to think about all people. Start to think about our species and ask yourself if your creation is going to contribute to the betterment of our species.

I think publishing on the web, there’s a net gain for our species, there’s a net gain for our planet because we’re contributing to the stock as well as the flow. It’s not just for today. It’s for future generations as well.

That’s why I don’t want to tie my creations to specific technologies, specific devices. I don’t want to be locked in. I want this stuff to survive over time and contribute to our collective good.

I began by talking about music—specifically hardcore punk music—and I’m going to finish with another musician: John Lennon. Because when I see really talented makers, really talented creative people, pouring their talent and their creativity into these silos, into these walled gardens, where they’re just contributing to what one company wants—they think they’re being creative when actually they’re creating something that’s going to bloom and die—it saddens me. It saddens me and it makes me kind of angry as well. That creativity could be contributed to the greater good.

And I think John Lennon summed it up pretty well in his song Working Class Hero. He said:

You think you’re so clever and classless and free

…but you’re still fucking peasants as far as I can see.

Licence

This presentation is licenced under a Creative Commons attribution licence. You are free to:

Share

Copy, distribute and transmit this presentation.

Remix

Adapt the presentation.

Under the following conditions:

Attribution

You must attribute the presentation to Jeremy Keith.

Jeremy Keith: One Web — Update 2011 - YouTube

My short talk from Aral’s Update conference in Brighton last September. I’m pretty happy with how it turned out. If I only I had a handheld mic—then I could’ve done a microphone drop at the end.

I spoke at the DIBI conference back in June. It was a really good event, despite its annoying two-track format.

My talk was entitled One Web:

The range of devices accessing the web is increasing. We are faced with a choice in how we deal with this diversity. We can either fracture the web by designing a multitude of device-specific silos, or we can embrace the flexibility of the web and create experiences that can adapt to any device or browser.

The video has been online for a while now and I finally got ‘round to getting it transcribed. You can pop on over to the articles section and read One Web. I should really re-name that section of my site: “articles” isn’t the most accurate label for a lot of the stuff there.

If you prefer listening to reading, the audio is available for your huffduffing pleasure.

I also put the slides on Speakerdeck so you play along with the presentation.

I reprised this talk in Italy recently at the From The Front gathering. The audio from that is also online if you want to compare and contrast.

• Listen to the audio.
• Watch the video.
• Download the slides.

Thank you. Thank you. Hello. It is a pleasure for me to be here. This is my first time in either Newcastle or Gateshead, so it is a pleasure. Is everyone having a good day?

Good, because I’ve been having a fantastic day. This has so far been an excellent conference. A big hand for Gavin and Joleen and everybody putting this on, this is awesome. Thank you Gavin.

I’ve been given the opportunity to get up here and rant and ramble on so I’m going to go at it at full speed.

I want to talk about the web, sort of big picture. The Web. The Single Web.

This is an article that Tim Berners-Lee wrote last year, marking the 20th anniversary of the web. He’s re-establishing some of the original design principles and original goals driving the web: why the web was created.

The primary design principle underlying the Web’s usefulness and growth is universality. The Web should be usable by people with disabilities. It must work with any form of information, be it a document or a point of data, and information of any quality—from a silly tweet to a scholarly paper. And it should be accessible from any kind of hardware that can connect to the Internet: stationary or mobile, small screen or large.

It’s kind of hard to imagine what it must’ve been like back then, but it really was a big deal in CERN that this guy created this web; that people could use different computers with different operating systems and yet they could access the same documents, right? We don’t even think about that today. We assume if you’re using a Mac or Linux or PC, you can go to a website and you’re going to be able to access the data. It’s wonderful. I think we’ve gotten very used to the wonder of this.

Tim Berners-Lee also established the goals of the web here. One of the things he talks about is universal access. To accomplish universal access, you need to be practising universal design. When I talk about access—when I’m talking about accessibility—I mean it in the true sense of the word. We tend to use the word accessibility in terms of people with different physical needs, but accessibility in terms of devices like when he talks about a web that should be accessible from any kind of hardware: stationary or mobile, small screen or large. Yes, definitely.

But how do we design for that? How do you design for this spectrum of possibilities on the web? And to try and answer that question I’m going to go back a bit in the history of visual design.

Design

I’m going to go back about a millennia and a half. This is the Book of Kells, which you can see in Trinity College in Dublin. This is the Chi Rho page. It’s beautiful; it’s an amazing piece of work.

I would call this design. I would call this visual design rather than art, in that it is communicating a message; it’s conveying a feeling but there is content that has been designed here. In this case the content is the Gospels and the emotional design is that of religious awe.

The monks working on this did a fantastic job. They began with the sheets of vellum and they designed the content for that medium. It has its limitations. It’s very hard to reproduce this kind of design. Making a second copy of the Book of Kells takes as much time and effort as making the first copy of the Book of Kells.

Print

That did change when we got the printing press, when Gutenberg came along. Now the cost of producing that second, third, fourth, fifth copy has fallen, and that was dramatic. It certainly changed history, and very early on, what you saw from the development of the print world was these guidelines and rules being established.

This is the Gutenberg Bible here, and it still looks pretty familiar. This is a few hundred years old, but already it looks like a book. We see the columns, we start to see the grid.

It’s the same fundamental principle though: that the printer knows the size of the medium and can fit line lengths in accordingly and that’s pretty much been the way that print has worked. They’ve had hundreds of years to work on this and get rules and systems in place. It was really in the twentieth century that those rules really started to get codified and you get the Swiss School of Design; you get the grid system. People like Josef Müller Brockmann and Jan Tschichold getting this stuff down and saying, “these are the rules we can work by.”

Essentially what the print designers are doing is they’re taking the page and they’re applying the grid system on top. It’s a constraint; the page, the dimensions. But it’s a known constraint and they can apply order using the grid system. That’s wonderful and what that gives designers then is a certain amount of control, because you do have this fixed dimension of the page, and you have these established systems of rules and guidelines. So this order imposed upon that constraint gives designers that control.

And then the web comes along.

The Web

Initially I’m sure designers were not happy about the web, when this is what it looked like. Although a web document straight out of the box in HTML is viewable on any device as long as it can understand HTML and that is wonderful. But the design …what do we do about design? How do we re-establish that control?

Designers tried. Does anyone ever remember—I’m really showing my age now but—Creating Killer Websites by David Siegel? Anybody apart from Jeffrey? Okay, a few people.

David Siegel is basically the person who invented the spacer .gif and came up with the whole idea essentially of using tables for layout. Let’s be fair: at the time, that was pretty much all you could do. Yes, it’s a hack, but it was necessary.

It was the same kind of thinking that was going on here: that by applying table layout to the browser viewport, you could impose an order on that constraint and establish control, just as you could in the printed world.

But there’s a problem with this way of thinking. And sure, later on, we swapped our table layouts for CSS, and that was fantastic. We all rewired our brains by going to the Zen Garden; we all got turned on by the Web Standards Project and the Wired redesign and ESPN.com, but fundamentally, we just swapped one toolkit for another. Fundamentally what was displayed to the user was still this idea that you were imposing order on this constraint of the browser. The problem with that is that the browser is not a known constraint. The browser is not something you now about. It is unknown.

The Unknown

Now if I’m going to talk about the unknown, there’s a certain someone that has to be invoked at this point. And that is Mr Donald Rumsfeld.

History will remember him as a murderous bastard, but that’s a bit of a shame because he is also a Zen master. There’s one particular comment that he came up with. It’s just a thing of beauty.

There are known knowns; these are the things that we know. There are known unknowns; these are the things that we know we don’t know. But there are also the unknown unknowns; these are the things we don’t know we don’t know.

Now people made a lot of fun of him for saying this, but actually it’s probably the most sensible thing I’ve ever heard anybody say. It’s absolutely brilliant.

When it comes to the browser, we have this unknown. I would say it would fall into the “known unknown” category. It has a number of known unknowns:

• We don’t know the connection speed that the user using this browser has got; how fast is their connection.
• We don’t know capabilities in terms of what plug-ins are installed or what JavaScript APIs are available to us.
• We don’t know the size of the viewport.

This stuff can be found out after the fact, once you’ve sent the document to the browser—we’ll get into that later—but essentially, it’s really hard to design in advance when you don’t know ‘till later on what any of these things will be.

What is the speed going to be? What’s the capabilities of the JavaScript engine? What will the viewport size be?

Because viewport size was just constantly changing as bigger monitors came out. For a while everyone was designing pages and you would design 640 x 480; that was your standard size. Then later on it became 800 x 600, then everyone got 1024 monitors, so we kind of settled on this 960 number. But it was always just this consensual hallucination that we were going to decide: “Okay, we’ve decided all users, most users, are using this size; we’re going to design for that. The browser width is now a known known.” And it’s just not true.

So this is this whole idea of taking something that’s unknown and treating it as fixed. And this was the default for web design. The default was to treat the browser width as a fixed dimension, even though it clearly is not.

Flexibility

There were those advocating for going in a different direction using percentages, thinking in terms of proportions rather than pixels. And again this has nothing to do with whether it’s CSS or table layout. You can use percentages on either. This is much more about how you approach the problem; how you approach design.

The real manifesto on this was written just over ten years ago by John Allsopp. This was an article called A Dao of Web Design in A List Apart. Hands up who’s read A Dao of Web Design?

Okay. I would really like to see every single hand in this room go up when I ask that question because every person working on the web needs to have read that article. It is our mission plan. It is our manifesto. It is what web design is all about. It’s what distinguishes web design from other media. So please, please do read it; it’s fantastic.

The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility.

John was simply pointing out that “look, this isn’t new.” When a new medium comes along we tend to take the tropes of the previous medium and try to apply them on top. When television came along, they just put plays on the television, until television found its feet and became its own medium.

On the web, we took a lot of stuff from print and just put it on the web. And that’s fair enough; like I say, they’ve had centuries to figure out rules and systems around typography, around grids, around colour. And we don’t want to just throw that stuff away; we definitely want to learn from that. But the web is its own medium. And it got defined really nicely by John Allsopp.

Faruk was talking about this earlier; why is it we tend to design for the web as this one binary all-or-nothing thing when actually it’s this flexible medium? I think a lot of it was down to the tools.

WYSIWTF

I know a bad craftsman blames his tools. It’s easy to pick on Dreamweaver (I love that I don’t even have to explain that joke to people in this room). Dreamweaver’s the obvious choice, or any other kind of WYSIWYG editor where they’re claiming you can lay it out visually because it was never true. But I’m talking about tools in a broader sense. I’m talking about tools like Photoshop and Fireworks and Illustrator. Designing in those tools for a medium like the web? It’s not such a good match.

What’s the first thing you do when you fire up Photoshop or Fireworks? Ctrl+N: you create a new document. Before it opens up you have to give it some information, namely you have to give it some dimensions; a width and a height. Straight away you’ve made a fundamental design decision. You’ve created a known known out of something that’s a known unknown, and everything follows on from there.

So our tools have never really been up to the job—in my opinion—of web design. This is something that my friend Andy Clarke talks about; that a lot of the problems we have in trying to convince clients that things don’t have to look the same in every browser, which we all believe in. But how do we convince them?

A lot of the problem is we’re showing them comps; pixel perfect comps in Photoshop or Fireworks and then of course they’re going to expect that it’s going to look exactly like that in whatever browser they happen to open it up in. So he’s suggesting we start in the browser. That brings its own problems as well, but it’s definitely something we need to be aware of, that our tools are problematic.

One of the main reasons why many people cling to the expectation that a web design should look the same across every browser is that one of the first things that designers show them is a carefully crafted static design made in Photoshop or Fireworks.

I have my own issues with designing a comp in Photoshop and then using that as a basis for development in that, a lot of the time, the reason why the comp has been created is to get sign-off from a client, or get sign-off from the boss; that’s one purpose. And then that same document gets used as the template for developers; marking it up, coding it up, applying the behaviour, and that’s a very different use. And yet we’re using the same asset for both. It’s very problematic.

So this whole thing of what tools should we be using for the job; what’s better, designing in the browser, designing in Photoshop? This would’ve remained a fairly academic kind of discussion about our tools on the web, until a couple of years ago when things really started to change and it has become impossible to ignore that change.

Mobile

A sweeping change in the number of devices, particularly mobile devices. They’re running web browsers that are accessing web pages. Now suddenly all that known known we thought we had of a fixed width really falls apart. Because with these devices, you simply don’t know:

• You don’t know the speed of the network connection that these devices will be using,
• You don’t know the capabilities of the APIs,
• You do not know the screen size.

Look familiar? This was always the case. It’s only recently people have started to talk about these things like, oh, the performance because of the network connection, or the different screen size on an Android phone, an iPhone, a tablet. But it was always the case. What the rise of these new devices has done is it’s just thrown it into sharp relief. It’s made it really clear that the way we’ve been working just doesn’t really fit with the medium of the web in its true sense; the one universal access web.

Now one approach to solving this problem with all this multitude of devices, is just essentially trying to splinter the web. Well let’s essentially talk about one web for these devices and then another web for different devices.

This term, the mobile web, just from a point of view of political language I really don’t like it. The implication that there’s a mobile web. What’s the rest of the web called? Do we talk about the desktop web? Where do you stop? What about tablets? Are they part of the desktop web, the mobile web, or now do we have a tablet web as well? Internet enabled fridge web? Where do we stop? This stuff doesn’t scale.

I definitely prefer to think of it as one web. But the only way you can really design for this one web is if you embrace this flexibility which means giving up control. But as we’ve seen, control was always an illusion. It was this consensual hallucination; we never really had this control.

We can do this, and we have the tools available.

Responsive Web Design

Just over a year ago, Ethan Marcotte published his fantastic article on responsive web design, and just yesterday, the book of the article of the genius was published. I highly recommend you buy it, Responsive Web Design.

And, really, if you look at what Ethan’s talking about here—talking about being flexible, about embracing the different sizes, the different capabilities of devices—it’s more or less the same stuff that John Allsopp was talking about ten years ago. In fact Ethan begins his article by referencing A Dao of Web Design by John Allsopp.

What we’ve got here is simply web design the way we always should’ve been doing it, renamed Responsive Web Design. And now people are paying attention because we’ve got all these different devices. That’s good, I think; whatever it takes to get people to pay attention.

Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience. We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them.

When Ethan wrote the article, he established three key ingredients for responsive web design which was that you would have:

1. a fluid grid, a flexible grid, exactly what John Allsopp was talking about,
2. fluid images, perhaps different sized images for different media, and
3. media queries, so that you can use different CSS for different screen widths, for example.

Everyone’s concentrating on the media queries as being like the key part. In fact I often see the term responsive web design and media queries used interchangeably. From my perspective, the media query is kind of the least interesting part. It’s more about the mentality of approach that you’re not thinking in terms of one fixed dimension. The technology used—whether it’s media queries or JavaScript or frankly just floats—that doesn’t matter as much.

Clarification

I have to clarify something about responsive web design, because I see a lot of misunderstanding. I think a lot of people are misinterpreting responsive web design as, “Oh it’s okay, we don’t have to worry about mobiles, tablets, all these other devices. We can take our existing great big desktop website, smatter on some media queries, and boom, you’ve got a website that’s optimised for a mobile device or a tablet, or whatever.”

That’s not what responsive design is about. Or at least, that’s not what I would call responsible responsive web design.

Although it can, in a pinch, it could help you out. But only if you have those other things in place anyway: a fluid grid to begin with, and flexible images. If you simply try and go in and smatter on some media queries on a site that’s been designed to fixed dimensions for a fixed screen for a certain device, it will not go smoothly.

I have had a good experience. This is from last year. There was this website. It’s a desktop website. That was the brief. It’s essentially a brochure website for St Paul’s School in London.

The site was built, we coded it up, and it launched, and we got some feedback from the client that actually some people were accessing it on small screen devices. It scaled down, it was fine, but could we do something to make it that bit nicer for the small screen devices? Not that we wanted to mobile optimise the site, but simply make it better than simply scaling.

Now I hadn’t actually done the mark-up on this, as my colleague Natalie Downe had done it, but because Natalie Downe is one of the—if not the best—front-end developer I have ever met, I was able to go in and take this completely robust code that was made with a fluid grid anyway, and it was made with responsive, fluid images, fluid carousels, everything was bullet-proof to begin with, within half an hour of just smattering in some media queries, I was able to make sure that on different screen sizes, it looked okay. You didn’t need to scale it. It was just adopting to the screen size.

But I would not hold this up as an example of responsive design. Essentially what I did was I applied some responsive CSS media query layouts onto an existing design, and the brief for that existing design was for a certain sort of device, namely a desktop or laptop device.

Real responsive web design, responsible responsive web design, is not thinking about the big size first but beginning smaller.

Content First

Now Luke Wroblewski likes to talk about mobile first, which was a great sort of mental exercise. Instead of thinking about your great big 1024 screen, what if you think about the 320 screen or the 480 screen? Now how do you design it? Now you really have to concentrate on what’s the most important thing to put in there. You won’t just be throwing stuff on the screen to fill up that empty space.

I like that approach. I think it would be equally valid to talk about print stylesheet first, or telephone hotline first. All good ways of getting you to think about the content because fundamentally what it’s about is the content first. And that’s the way we should be designing, not thinking about the size of the screen and then designing for that sized screen, because that’s an unknown. Think about the content. That we know, okay?

If you don’t have the content, I’m sorry, you can’t make a website. You have to have the content. And once you’ve got that, then you can start to think about applying on the presentation and applying the behaviour for the different devices.

If this stack looks familiar; content, presentation, behaviour, it’s because that’s progressive enhancement. That is how we are supposed to be making websites anyway.

Progressive Enhancement

We talk about progressive enhancement, but we kind of do it to a certain extent, like often our progressive enhancement is simply, “Hey, IE8, IE6 or 7 don’t get round the corners or gradients, but Firefox and Safari does.” Cool. Progressive enhancement. And that’s good. Websites do not need to look the same. But I mean real progressive enhancement as in the content is the beginning, that when you’re designing you’re not thinking about a specific size.

Something I like to do on every project I start now is to try and divorce the layout from the content. I’m not just talking about text content, paragraphs of text, whatever, but the pieces, the modules of content. So when I start creating the markup and CSS, I won’t begin with the grid. I’ll begin with the individual components. I’ll create something called a pattern primer or pattern portfolio.

All these things are going to be used throughout the site and their context shouldn’t matter. They should be able to appear anywhere in the page. I’ll take this (and this also makes a good deliverable to hand over to other developers) and I can re-size this page to make sure that they don’t break at different sizes; that they scale up and down, bump the font size up and down, all this kind of stuff. It makes sure that your markup and your CSS is really bullet-proof and modular. It’s kind of similar to what Nicole Sullivan talks about with Object Oriented CSS which is kind of an unfortunate name, but basically means using CSS smart, right? Using it the right way, so you begin with the content being robust and doesn’t rely upon the layout.

I take all these styles that I’ve created and I put them into a global style sheet. This is the style sheet everyone’s going to get. Every device: I’m going to give them these styles.

<link rel="stylesheet" href="g/https://adactio.com/tags/lobal.css" media="all">

Now within those styles of course there’ll be certain things the browsers can’t do: rounded corners, gradients, whatever; that’s fine. Websites do not need to look the same in every browser. But everybody gets those global styles.

Then the layout; let’s say it’s a fairly wide grid. The layout I want to make sure I only give when the viewport is wide enough to support it, so this is when I start introducing a media query in this case (could just as easily be JavaScript). It’s a media query in this case.

<link rel="stylesheet" href="l/https://adactio.com/tags/ayout.css"
media="all and (min-width: 30em)">

When the viewport width is at least 30 ems, pull in this other style sheet which is the layout stylesheet. That stylesheet is the one with widths and floats and clears; all that kind of layout information.

I happen to use ems because most of the content I work with is text-based. That’s the unit I happen to use. You could be using pixels; that’s fine, but I just want to make sure this technique works for someone who’s bumped up the font size quite a bit, just as much: so someone with a large screen with the font size bumped up a lot should get a linear layout much like a small screen with a normal font size. Again, not thinking in terms of pixels here.

There’s a problem. This would be wonderful except for a certain class of browsers that I’m sure you’re all familiar with.

So this is the theory. Give everyone the global styles. Give every browser that has a width above a certain size this layout grid. That’s fine except for Internet Explorer less than 9. Internet Explorer 9 supports media queries. This is fine, it’s all we need. So we need to do something for Internet Explorer less than 9. We need to have some kind of hack. And let’s face it, it is a hack, but we do have something we could use. We can use conditional comments.

It’s a hack, but it kind of works for Internet Explorer in the sense it’s a browser specific hack that was invented by the browser makers themselves, so I’m okay with doing that. I don’t feel good about doing it, but it works.

So what I do is, say if it’s Internet Explorer less than 9, point to the exact same style sheet: the layout style sheet, but without the media query this time.

<!--[if lt IE 9]>
<link rel="stylesheet" href="l/https://adactio.com/tags/ayout.css" media="all">
<![endif]-->

Now this means Internet Explorer 8, Internet Explorer 7, Internet Explorer 6: they’re all going to get the layout. They’re all going to get the grid, regardless of how big the viewport is. That’s a relatively safe bet that people using those browsers won’t be on small screen devices. Or it was until earlier this year when Windows Phone 7 came out with this godawful IE7/IE8 hybrid bastardisation browser on it. So just add another little clause in there. If you’re less than IE9 and you’re not mobile, then pull in the layout, then it’s a pretty safe bet that people are going to be using Internet Explorer 6, 7, 8 are probably on a desktop.

<!--[if (lt IE 9) & (!IEMobile)]>
<link rel="stylesheet" href="l/https://adactio.com/tags/ayout.css" media="all">
<![endif]-->

I was doing this, and I noticed something actually—and this again goes back to what Faruk was saying about his answer to the question about supporting IE7, supporting these older browsers. It comes down to what you mean by “support.” Define support.

In this case, I know that the global styles are fairly safe; I want to give them to everyone. But there’s stuff in that layout, the grid, that could be getting kind of complex. And you know what Internet Explorer’s like with floating and, you don’t want to be throwing in your zoom:1s and hasLayout things and it’s crappy at calculating percentages anyway, so it might be in the best interests of users of, for example, Internet Explorer 6 to say, “No you don’t get the layout.” And it’s actually a better experience for them to get the linearised content without the layout, because they’re going to just screw up the layout anyway.

<!--[if (lt IE 9) & (!IEMobile) & (gt IE 6)]>
<link rel="stylesheet" href="l/https://adactio.com/tags/ayout.css" media="all">
<![endif]-->

It’s up to you. Depending on your usage stats and the audience you’re supporting, you may want to think about this. What I like is that you’re not thinking about support for IE6 in terms of it’s either there or it’s not. You can be more nuanced. You can say, “I’m giving most of the typography and colour styles to IE6, but I’m not going to give it the layout grid because it’s just going to screw it up anyway.” So you do this.

There’s another little hack you need to do, which is for the mobile devices like the iPhone, Android, tablet and so on, and that is the meta viewport element.

This should not be in HTML. This is presentational information. It should be in CSS. But we’re kind of stuck with it for now. There is actually a CSS @viewport query that’s currently just supported in the beta of Opera, but hopefully we’ll start to see this stuff move to CSS because this is presentation, not structure.

Essentially what you’re saying is look: make the width of this fit the width of the device. That only makes sense if you are using liquid layouts, if you’re using a flexible grid. If you have got something that’s fixed, there’s no point adding this declaration.

<meta name="viewport" content= "width=device-width">

This ensures it’ll take up whatever spaces it needs to take up. And then I tend to also add in the initial scales, so a pixel is a pixel essentially. There’s a couple of little bugs with mobile Safari when you go from portrait to landscape with this, but hopefully that’ll get ironed out pretty soon.

<meta name="viewport" content= "width=device-width, initial-scale=1.0">

Oh, and do notice with the meta element, you separate values with commas, not semi-colons. It’s not CSS. If you think about meta keywords, you separate them with commas. This is the same. You’ve got values separated by commas.

It’s ugly though, isn’t it? “content equals width equals” …uurgh. It’s just not nice!

So inside this layout style sheet then, I will have my large …now weirdly inside the layout style sheet I tend to work from the big size down, even though in the markup I’m beginning with the default of small, but then once I’ve pulled in this layout style sheet, okay here’s what I want.

[role="main"] {
  width:61.8034%;
  float:left;
}
[role="complementary"] {
  width:38.1966%;
  float:right;
}

I’ve got the main content and the subsidiary content; I want them side by side, floated left and right, so I’ve got a kind of golden ratio set up here for the main content and the complementary content.

I happen to be using ARIA roles for my attribute selectors, but you could be using classes, IDs, whatever you want.

And then I can go further and say, yes but I’ll go for some of those other sizes. Actually if it’s between 30 and 60 ems then I want to make those columns 50% each, it just looks better.

@media all and (max-width: 60em) {
  [role="main"],
  [role="complementary"] {
    width: 50%;
  }
}

And I can start tweaking it, adding in all these different ones. But do remember: Internet Explorer won’t get those ones, because it doesn’t understand media queries. Internet Explorer less than 9.

Another approach to this is to forget about conditional comments altogether. Just put all your styles into one style sheet—which is good from an HTTP request point of view—and use some JavaScript to achieve the same effect.

There’s a script called Respond.js from Scott Jehl that’s really good. That’ll bootstrap Internet Explorer less than 9. It’ll go through the styles and figure out those media queries and apply them.

Both techniques, whether you do it this way, whether you do it with JavaScript, both equally valid.

The result is I start with just linearised content, so if you’re visiting and this is less than 30 ems, you visit…

This is a site called Huffduffer that I put together. This is a profile page. You just get the content linearised. There’s no floating going on here; it’s just the content.

As it starts to expand I can start to put in more CSS. I’m going to play around with a little bit more white space here, still linearised.

Here’s that sort of in-between size where I’m making them 50%.

Then once I get bigger, I’m going for this golden ratio—main content, subsidiary content—sort of ratio.

It looks pretty good at all these different sizes. And in between each of those stages, it’s liquid. We’re not jumping between fixed widths here. It’s liquid in between all of them as well.

Conditional Loading

Something else that’s interesting this brings up with content first, thinking about the content: what must you have on the screen? For this particular site, because this stuff that’s in the subsidiary content, that’s nice to have, kind of like similar people; people who are like you on Huffduffer. That’s good, but it’s not the main purpose of the page. The main purpose of the page is “Who is this person?”, “What have they put on the website?”

So you’ve got the content you absolutely have to have, the content you can afford to lose, and then some content that’s kind of in the middle; it’s like, “Well it’d be nice to have that content.” And again the responsive approach I think helps in thinking about content that way. Not this binary “there’s content and there’s lack of content”, but “there’s content that maybe should be there if we’ve got room for it.”

In that case I start to use a bit of JavaScript, a bit of Ajax—and here I am kind of tied to pixels rather than ems, but that’s fine. I say “Look, if the document’s wider than this, I know there’s going to be a nicer layout applied to it: well, pull in this particular information from the server and put it in that part of the page using a bit of Ajax.”

if ($(document).width() > 640) {
  $.get('path/to/html',function(data){
    $('[role="complementary"]').append(data);
  });
}

Lazy loading: I don’t think is the correct term for this, but I’ve started to call it that.

Another example of starting with the basic content and putting it into different layouts. This is a site for UX London, a conference we did this year.

At the smaller size, we’ve got two pictures. As it expands, I’ve got room now to fit three side by side. Then as it gets bigger, well I’m going to put all six.

The point here is that those different break points—going from two to three to six—those weren’t set by the size of some particular device. I wasn’t arbitrarily picking 320, 480, 640, 800. It was the content. The content is a headshot, someone’s name, a little bio. When it makes sense to have that content change from two to three to six, that’s where I set the break point. Not from the device inwards, but from the content out, which is exactly what Mark Boulton’s been talking about, this idea of why web design is different to all these other forms of mediums where you have a fixed canvas; your vellum, your paper, your stone tablet, whatever it is: you know the dimensions. With the web, you don’t, but that’s okay: you have your content. You design from the content out rather than canvas in.

It’s my belief that in order to embrace designing native layouts for the web — whatever the device — we need to shed the notion that we create layouts from a canvas in. We need to flip it on its head, and create layouts from the content out.

I want to pre-empt some questions people always tend to bring up.

Web Apps?

What about web apps? This is all great when you’re talking about content based sites, but we’re making web apps.

Alright: rant approaching.

First of all, define “web app” for me. I’ve yet to hear a definition of web app. Look, the truth is, we’ve got documents, we’ve got apps, and most things on the web are somewhere in the middle. They’re documents that have a bit of interaction, or they’re really interaction based, but essentially they’re URLs; there’s a document there that you’re interacting with. Gmail is document-based. You interact with documents.

So define web app for me. Because what I see happening is that people use this as an excuse. They use this as a “get out of jail free” card. It’s like, “Oh yes, responsive design. I’m all on board with that, but I don’t have to do it because I’m designing a web app.”

I’ve been here before.

A couple of years ago, I was talking about progressive enhancement and Ajax, because I saw this fervour, the same fervour I’m seeing about the mobile web I saw about Ajax. It’s like, “Get on that shit: monetise the hell out of that shit.” And people going, “We don’t need to think about progressive enhancement, accessibility, all those rules for the boring old document-based web. No. We are using Ajax, web app,” whatever the term is that you want to use as your “get out of jail free” card to say “It doesn’t affect me.”

Bollocks to that.

It Depends

That said, as always, as with any question with design and web design specifically, it depends.

Yes, there are cases where it actually makes more sense to have a siloed m. or mobile. subdomain, and to serve up a different experience for specific devices. But they are fewer than people think.

The default is to serve up a separate mobile site, and I think in the same way that the default was to serve up fixed width websites for ten years. So what I’m questioning here is the default. There are definitely instances where it makes sense to have a silo for a certain device, but it shouldn’t be the default. I’m questioning the default here.

So I just want to say I do realise this won’t necessarily work for everything; it does depend. But I would say the number of cases where it depends are smaller than people think.

Context First?

And the other question people bring up is “Well, that’s fine, you’re talking about the content and displaying the content in different devices with all these different capabilities, widths and so on. But what about the context of the user? That’s the most important thing about these new devices; mobile, tablets, all these internet enabled devices.”

And it’s true, the context is absolutely the most important thing. But it’s always been the most important thing. Except we’ve always just assumed, “Well someone’s sitting at a desktop; we know their context. They’ve got all the time in the world. They’re not busy.” Whereas someone on a mobile’s walking down the street and they’re accessing your website like this. And that may have been true a few years ago when mobiles were not as widely spread (and certainly not using the web on mobiles).

But these days, people use mobiles all the time. At home over WiFi lounging on the sofa. In bed, they will use mobile devices, tablets, in all sorts of situations. So to assume that, “Oh I know the context of the user because of the device they’re using” …very, very dangerous. Downright insulting a lot of the time.

If someone comes to your site looking for information, you say, “Oh you’ve got a mobile phone, I’ll give you the dumbed down information. I don’t want to give you the big, bad website.” And they know the information they’re looking for is on that website, but you’re denying it to them. It’s very dangerous.

Now, serving up different content, different experiences based on the capabilities of a device? Yes, fantastic; I’m all for that. But don’t just stop at mobiles. Different desktop browsers have different capabilities. Give them the best that they can experience.

Mark Kirby is a web developer in Brighton. He summed it up and said:

Mind reading is no way to base fundamental content decisions.

Like, “Ah, I know what a mobile user wants.” No you don’t. Don’t make those assumptions. It can be very, very dangerous.

And the worst thing is, people that are thinking about these contexts, they only ever think of the mobile user. They only ever think: “Ah, someone on a mobile doesn’t have much time, he doesn’t have time to look at all this content, we’ve just got to get him straight to the most important information.”

Mobile users want to see our menu, hours, and delivery number. Desktop users definitely want this 1mb png of someone smiling at a salad.

Why just the mobile user? Why are you penalising people just because they’re sitting at a desktop or a laptop? A laptop that could be on a train over a 3D network or a dongle. Yet you’re assuming, “Ah, that’s fine, we can just throw any sort of crap at them. We can take our content and just piss all over it!”

That’s the content. That’s the content. And do you think that was designed from the content out? I don’t think so. It’s no wonder.

People get to start with a blank slate with the mobile version when they create a separate site, and I think that’s why it’s been so popular, because you can start from the content first. We’re stuck with this legacy of these big, bloated pages because of our tools, because of our thinking, and people just throw crap on the screen because there’s room for it.

And you know, people are going to find a way around this stuff. Already services are emerging. This pissing all over content is being interpreted as damage and routed around. You’ve got services like Readability and Instapaper.

There’s another article in A List Apart called Orbital Content I encourage you to read. Users are going to find a way to get at that content without that big, bloated crap so you can get on board or you’re doomed.

And we can do it. We can do this. It requires a certain change in our thinking, but it’s extremely liberating.

I think Trent Walton put it best, describing what he loves about responsive web design:

My love for responsive centers around the idea that my website will meet you wherever you are—from mobile to full-blown desktop and anywhere in between.

My website will meet you wherever you are.

That ties in really nice with what Tim Berners-Lee was saying on the twentieth anniversary of the Web.

And I feel really good about that, knowing with my website, yes I can view my website in a desktop browser, or a different desktop browser; there might be some differences. That’s fine. I can view it on a text-only browser, and it’s still going to be accessible. People can still get that content. They can view it on this new tablet device. Phones: the popular phones and the phones that are coming out every single day. If someone wants to print off that information, I should make sure I’ve designed for that experience as well. And that it can look good on devices that weren’t even around when I was making the design. And some people may want to visit my website in a user agent that isn’t even visual at all.

So we can do this. It requires a certain change of thinking. It requires giving up control and thinking fluidly, thinking in proportions rather than pixels, but we can keep having one web.

Thank you.

After giving my language-centric talk at the Breaking Development conference I found it interesting to listen out for the terms that attendees and speakers were using to describe desktop-centric websites. Some of the adjectives I heard were:

• full site,
• standard site,
• regular site.

Once again, I think that this kind of language can constrain our approaches to web design and development. In truth, a mobile site should be the standard, full, regular site; you can still go ahead and add more stuff for the desktop environment, but to think of it as the canonical instantiation isn’t helpful. It hinders our ability to think in a mobile-first responsive manner.

Jason made a great point in his closing talk at Breaking Development. He said that clients are always asking how much extra it’s going to cost them to have a mobile site. But it should be the other way around. The mobile site ought to be the default and they should be asking how much extra it will cost to optimise for the desktop (which is not very much because, let’s face it, the desktop environment is a piece of piss compared to mobile).

It can be tough to convince a client that a mobile-first responsive site is the right approach. It’s always better to show rather than tell, but up until now there haven’t been any poster children for responsible responsive design—much as I like the mediaqueri.es site, the majority of sites showcased are shrinking down from a desktop start.

This reminds of the situation with web standards ten years ago. There were plenty of great sites that has switched over from table layouts to CSS but they were mostly blogs and portfolio sites (again, take a look at mediaqueri.es). It wasn’t until large commercial entities like ESPN and Wired.com were brave enough to make the switch that the CSS floodgates opened.

As of this week, we have a poster child for responsive web design: The Boston Globe. Actually, that does it a disservice …it’s a poster child for excellence in web design and development best practices.

I was lucky enough to have Scott do a show’n’tell at my dConstruct workshop. Seeing the thought and care that went in to every step of the process was humbling. There were a lot of tough challenges but they kept their eye on the prize: universal access—regardless of what device you’re using—without compromising on visual and interactive richness.

I’m going to let the site speak for itself but I just wanted to send my heartfelt congratulations to Ethan, Miranda, Scott, Todd, Patty and everyone else at Filament Group, Upstatement and the Boston Globe. Their hard work will benefit everyone designing and development for the web. Thank you guys.

Here are some reports in their words:

• From the Boston Globe itself, here’s a look at the strategy and business goals that informed the site.
• Ethan wrote about his role in the process.
• Upstatement have a beautiful portfolio page (itself responsive) showcasing the Boston Globe.
• Patty documents Filament Group’s experience with this project.

Lots of other people are writing about the Boston Globe launch, although much of the commentary focuses on the forthcoming paywall/fence rather than the design or technology. Jeffrey has written about the site, also comparing it to Mike’s visionary work on ESPN back in the day.

I could go on and on about how well the site works on touchscreen devices, tablets and mobile phones of all kinds but I think the essence of what makes the site great is captured in Grant’s screenshot of The Boston Globe site running on… an Apple Newton.

The Breaking Development conference is wrapping up here on spacecraft Opryland One. It’s been a wonderful experience. The conference itself was superbly curated—a single track of top-notch speakers in a line-up that switched back and forth between high-level concepts and deep-dives into case studies. I hope that other conferences will take note of those key phrases: “single track”, “curated”, “top-notch speakers” (see also: An Event Apart, dConstruct, Mobilism).

I opened the show with a talk that sounds controversial: There Is No Mobile Web. Actually, it wasn’t as contentious as it sounds (I originally proposed a talk called Fuck The Mobile Web: Fuck It In The Ass—then it would’ve been controversial). You can download a PDF of my slides if you want but, as usual, they won’t make much if any sense outside the context of the presentation.

My talk was concerned with language; Lakoffian political language in particular. When I say “there is no mobile web,” I mean it quite literally: there isn’t a separate world wide web for mobile devices. But by using the phrase “mobile web” we may be unintentionally framing the discussion in terms of separate silos for different kinds of devices (desktop and mobile) in a similar way that a term like, say, “tax relief” automatically frames the discussion of taxation as something negative. By subtly changing the framing from “the mobile web” to a more accurate phrase such as “the web on mobile” we could potentially open new avenues of thinking.

By the same token the phrase “one web”—which is the drum that I bang—is really a tautology. Of course there’s only one web! But the phrase has political and philosophical overtones.

So I asked the assembled audience if we could come to an agreement: I’ll stop saying “one web” if you stop staying “mobile web.” How about …”the web”?

I also talked about the power of naming things, invoking the foreword I wrote for Ethan’s book:

When Ethan Marcotte coined the term “responsive web design” he conjured up something special. The technologies existed already: fluid grids, flexible images, and media queries. But Ethan united these techniques under a single banner, and in so doing changed the way we think about web design.

I’m not invoking the Sapir Whorf hypothesis here, I just wanted to point out how our language can—intentionally or unintentionally—have an effect on our thinking.

One of the other phrases I discussed was “web app.” The timing couldn’t have been better. Fellow Breaking Development speaker James Pearce has just written a blog post all about defining what makes something a web app. It’s very detailed and well thought-out but I’m afraid at the end of it, we’re still no closer to having a shared agreed-upon definition. It’s like the infamous Supreme Court definition of obscenity: “I know it when I see it.”

My concern is that the phrase “web app” is wielded as a talisman to avoid best practices. “Oh, I totally agree that we should care about accessibility …but this isn’t a web site, it’s a web app.” “I think that progressive enhancement is great …for websites; but this is a web app.” The term is used as a get-out-of-jail free card and yet we can’t even agree what it means. I call shenanigans. I don’t think it is useful or productive to create an artificial boundary between documents and applications when the truth is that almost everything on the web exists on a continuum between the two poles.

Luke has published his excellent notes from my talk. You should read ‘em. While you’re at it, you should read all of the notes that he took at the conference.

Make sure you check out the notes from Stephanie’s mind-blowing case study of browser.nokia.com. The slides are on Slideshare too.

As I said, the Breaking Development conference did an excellent job of balancing the practical with the inspirational. Stephanie’s intensely useful case study was perfectly balanced by an absolutely incredible call to arms from Scott Jenson called Why Mobile Apps Must Die (and you thought my talk title was contentious), in which he expanded on his brilliant writings over on the Beyond Mobile blog.

The next Breaking Development event will be next April in Orlando. Single track. Curated. Top-notch speakers.

The One Web: don’t write for devices, write for people | Opinion | .net magazine

A great opinion piece from Addy Osmani prompted by the panel discussion I took part in at the Update conference.

Jeremy Keith - One Web on Vimeo

The video of my talk/rant at the DIBI conference in Newcastle/Gateshead earlier this year, for your viewing pleasure.

Mobile-First Responsive Web Design | Brad Frost Web

A nice round-up of responsible responsive web design techniques, ‘though I would go a bit further and suggest that the rallying cry is not so much about Mobile First but Content First.

Responsive by default - Blog | Andy Hume

A superb long-zoom view of responsive design from Andy. He also talks about the pragmatism required from any front-end developer.

susan jean robertson » Assumptions

Susan pushes back on the notion of the mythical mobile user.

This is a disclaimer.

I have been writing and talking a lot about responsive web design, a pattern that I think emerges naturally from the principle of universal design. I will continue to write and talk about responsive and universal design in the future and I will continue to advocate a “one web” approach to treating all users fairly regardless of ability or device.

But here’s the thing: I am fully aware that there is no one correct answer to every situation. So even though I’m going to continue to bang the drum of one web, I’m not actually foolish enough to think that it’s a cure-all. I’m taking a deliberately Friedian approach in order to back up a stance that I think is woefully under-represented in most discussions of modern web development.

If you’re looking for the more honest, truthful answer to pretty much any question on web design and usability, here it is:

It depends.

I now return you to your regular schedule of absolutist self-righteous claims.

There is no Mobile Web | The Haystack.

Steven nails exactly why I’m so excited about the increasing diversity of devices accessing the web; not so that we can build more silos, but so that we can sure our content is robust enough for the multitude of different devices:

To be honest, I can think of a few, but not many use cases of web sites or apps which are or should be exclusively mobile. It seems like the Mobile Web allows us to revisit all of the talk of inclusion, progressive enhancement and accessibility from years ago.

I was in Dublin recently to give a little talk at the 24 Hour Universal Design Challenge 2010. It was an interesting opportunity to present my own perspective on web design to an audience that consisted not just of web designers, but designers from many different fields.

I gave an overview of the past, present and future of web design as seen from where I’m standing. You can take a look at the slides but my usual caveat applies: they won’t make much sense out of context. There is, however, a transcript of the talk on the way (the whole thing was being captioned live on the day).

Towards the end of my spiel, I pointed to Tim Berners-Lee’s recent excellent article in Scientific American, Long Live the Web: A Call for Continued Open Standards and Neutrality:

The primary design principle underlying the Web’s usefulness and growth is universality. When you make a link, you can link to anything. That means people must be able to put anything on the Web, no matter what computer they have, software they use or human language they speak and regardless of whether they have a wired or wireless Internet connection. The Web should be usable by people with disabilities. It must work with any form of information, be it a document or a point of data, and information of any quality—from a silly tweet to a scholarly paper. And it should be accessible from any kind of hardware that can connect to the Internet: stationary or mobile, small screen or large.

We’re at an interesting crossroads right now. Recent developments in areas like performance and responsive design means that we can realistically pursue that vision of serving up content at a URL to everyone to the best ability of their device. At the same time, the opposite approach—creating multiple, tailored URLs—is currently a popular technique.

At the most egregious and nefarious end of the spectrum, there’s Google’s disgusting backtracking on net neutrality which hinges on a central conceit that spits in the face of universality:

…we both recognize that wireless broadband is different from the traditional wireline world, in part because the mobile marketplace is more competitive and changing rapidly. In recognition of the still-nascent nature of the wireless broadband marketplace, under this proposal we would not now apply most of the wireline principles to wireless…

That’s the fat end of the wedge: literally having a different set of rules for one group of users based on something as arbitrary as how they are connecting to the network.

Meanwhile, over on the thin end of the wedge, there’s the fashion for serving up the same content at different URLs to different devices (often segregated within a subdomain like m. or mobile.—still better than the crack-smoking-inspired .mobi idea).

It’s not a bad technique at all, and it has served the web reasonably well as we collectively try to get our heads around the expanded browser and device landscape of recent years …although some of us cringe at the inherent reliance on browser-sniffing. At least the best practice in this area is to always offer a link back to the “regular” site.

Still, although the practice of splintering up the same content to separate URLs and devices has been a useful interim step, it just doesn’t scale. It’s also unnecessary.

Most of the time, creating a separate mobile website is simply a cop-out.

Hear me out.

First of all, I said “most of the time.” Maybe Garrett is onto something when he says:

It seems responsive pages are best for content while dedicated mobile pages are best for interactive applications. Discuss.

Although, as I pointed out in my brief list of false dichotomies, there’s no clear delineation between documents and applications (just as there’s no longer any clear delineation between desktop and mobile).

Still, let’s assume we’re talking about content-based sites. Segregating the same content into different URLs seems like a lot of work (quite apart from violating the principle of universality) if all you’re going to do is remove some crud that isn’t necessary in the first place.

As an example, here’s an article from The Guardian’s mobile site and here’s the same article as served up on the www. subdomain.

Leaving aside the way that the width is inexplicably set to a fixed number of pixels, it’s a really well-executed mobile site. The core content is presented very nicely. The cruft is gone.

But then, if that cruft is unnecessary, why serve it up on the “desktop” version? I can see how it might seem like a waste not to use extra screen space and bandwidth if it’s available, but I’d love see an approach that’s truly based on progressive enhancement. Begin with the basic content; structure it to best fit the screen using media queries or some other form of feature detection (not browser detection); pull in extra content for large-screen user-agents, perhaps using some form of lazy loading. To put it in semantic terms, if the content could be marked up as an aside, it may be a prime candidate for lazy loading based on device capability:

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content.

I’m being unfair on The Guardian site …and most content-based sites with a similar strategy. Almost every site that has an accompanying mobile version—Twitter, Flickr, Wikipedia, BBC—began life when the desktop was very much in the ascendency. If those sites were being built today, they might well choose a more responsive, scalable solution.

It’s very, very hard to change an entire existing site. There’s a lot of inertia to battle against. Also, let’s face it: most design processes are not suited to solving problems in a device-independent, content-out way. It’s going to be challenging for large organisations to adjust to this way of thinking. It’s going to be equally challenging for agencies to sell this approach to clients—although I feel Clearleft may have a bit of an advantage in having designers like Paul who really get it. I think a lot of the innovation in this area will come from more nimble quarters: personal projects and small startups, most likely.

37 Signals recently documented some of their experiments with responsive design. As it turned out, they had a relatively easy time of it because they were already using a flexible approach to layout:

The key to making it easy was that the layout was already liquid, so optimizing it for small screens meant collapsing a few margins to maximize space and tweaking the sidebar layout in the cases where the screen is too narrow to show two columns.

In the comments, James Pearce, who is not a fan of responsiveness, was quick to cry foul:

I think you should stress that building a good mobile site or app probably takes more effort than flowing a desktop page onto a narrower piece of glass. The mobile user on the other side will quite possibly want to do different things to their desktop brethren, and deserves more than some pixel shuffling.

But the very next comment gets to the heart of why this well-intentioned approach can be so destructive:

A lot of mobile sites I’ve seen are dumbed down versions of the full thing, which is really annoying when you find that the feature you want isn’t there. The design here is the same site adapted to different screens, meaning the end product doesn’t lose any functionality. I think this is much better than making decisions for your users as to what they will and won’t want to see on their mobile phone.

I concur. I think there’s a real danger in attempting to do the right thing by denying users access to content and functionality “for their own good.” It’s patronising and condescending to assume you know the wants and needs of a visitor to your site based purely on their device.

The most commonly-heard criticism of serving up the same website to everyone is that the existing pages are too large, either in size or content. I agree. Far too many URLs resolve to bloated pages locked to a single-width layout. But the solution is not to make leaner, faster pages just for mobile users; the answer is to make leaner, faster pages for everybody.

Even the brilliant Bryan Rieger, who is doing some of the best responsive web design work on the planet with the Yiibu site, still talks about optimising only for certain users in his otherwise-excellent presentation, The End of Unlimited Bandwidth.

When I was reading the W3C’s Mobile Web Best Practices, I was struck by how much of it is sensible advice for web development in general, rather than web development specifically for mobile.

This is why I’m saying that most of the time, creating a separate mobile website is simply a cop-out. It’s a tacit acknowledgement that the regular “desktop” site is beyond help. The cop-out is creating an optimised experience for one subset of users while abandoning others to their bloated fate.

A few years back, there was a trend to provide separate text-only “accessible” websites, effectively ghettoising some users. Nowadays, it’s clear that universal design is a more inclusive, more maintainable approach. I hope that the current ghettoisation of mobile users will also end.

I’m with Team Timbo. One web.