Brad reminisces about the scene ten years ago.
I’m not sure I’ll ever be a part of such an exciting moment in this field again. Of course technology continues to evolve, but the web landscape has settled down a bit. While I’m more than okay with that, I occasionally miss the electric, optimistic feeling of being on the cusp of something new and exciting.
All the videos from last year’s Breaking Development conference in Dallas are up on the site. They’re all excellent.
The opening keynote from the Breaking Development conference held in Nashville, Tennessee in September 2011.
I thought I’d kind of pull back a bit, so I’m not going to be giving you any practical take-aways today. I’m going to sort of look at a bit of a higher level; hence this talk. There Is No Mobile Web.
Now I know this sounds controversial, “Ooooh, controversial!” It’s not: really I’m not being controversial; not today. Usually I am, but not today. Really. Actually this is far less controversial than the original talk title I proposed. Ask me in the bar. No, what I’m talking about here when I say there is no mobile web is it’s simply the language pedant in me coming out.
There is no mobile web, right? There isn’t a second web specifically for mobile devices, right? We’re still using HTML, HTTP, URLs; it’s the same web. And we all know this, OK? When we say The Mobile Web, we know we’re not literally talking about “There’s this web and then there’s the mobile web, and now we’re talking about the mobile…” No; we know it’s all the same web and we’re talking about the web as accessed by mobile devices and this is a nice short way of saying that.
But even so, the words we use can, I think, somewhat influence our framing of things. This isn’t a new idea. George Lakoff who wrote the book, Metaphors We Live By and others, talks about political language. Now I’m not going to say that the language we use directly influences our thoughts or what we’re capable of thinking—that’s kind of the Sapir-Whorf hypothesis, I don’t really go with that—but I do think that the language we use can affect the way we approach things, subconsciously.
So we’re all familiar with political language, I think. There’s like the obvious ones, like the military euphemisms, like ‘friendly fire’ and ‘collateral damage’. We all know what they actually mean and we’re generally kind of disgusted by these kind of euphemisms that try to tidy stuff away. But there’s more than that. All the time you see politicians talk about tax relief, right? So tax is something you need to be relieved from. Straight away, the framing of the debate has kind of keeled to one side, without even realising it. Conservative values; those two words getting put together. You don’t tend to hear about liberal values, right?
So the framing of discussions can subconsciously affect how we approach something right from the start, without even realising it. And this isn’t something new. Again, George Orwell wrote about this in Politics and the English Language, and how euphemisms like this can subtly influence us.
So when I talk about “there is no mobile web,” what it means is that phrase, mobile web, perhaps accidentally can lead us into thinking of silos, of thinking of the web as accessed by mobile devices as being something that needs to be siloed off from the rest of the web. And I challenge that.
I challenge that because I don’t think that’s particularly true for the underlying design principles of the web. (This is like the bit iin Annie Hall where Woody Allen goes, “I’ve got Marshall McLuhan right here,” Well I’ve got Tim Berners-Lee right here.) He wrote this article this year—I think it was earlier this year—coming up to the twentieth anniversary of the World Wide Web, sort of reiterating the fundamental design principles underlying the web. And you can see that the watchword here is universality, right? It was true twenty years ago and it’s still true today, that you should be able to access anything on the web, as he says, be it a silly tweet or a scholarly paper, whether it’s a document or a point of data, and it should be accessible from any device, large screen or small, mobile or stationary. And I tend to cling to that.
Now I think most people would agree with that in principle. But in reality we have all these problems and we all have to, you know, silo stuff off into the mobile web. Well perhaps. But I think this should be the default. I think this should be what we aim for and while yes, there are use cases for siloing things into this almost separate web, I think it should kind of be a last resort, and we should aim for this.
The issue with this, this great theory—the web should be accessible from any device, screen size, bandwidth, capabilities; anybody should be able to access a website—is how do you design for that? How do you design for a medium that theoretically could be accessed by any device that you don’t know the size of it?
That’s tricky. So I want to step back. I’m going to go back further than simply twenty years ago with the birth of the web. I’m going to go back a few hundred years with the birth of print. A revolution of course; I mean in human history, the invention of the printing press kind of changed everything, and it was a revolution for design. It was the beginning of a whole new kind of visual design for the printed page. And right from the start—this is the Gutenberg Bible—right from the start you can see things that we would recognise to this day. You can sort of see the emergence of a grid system, of the way that the type has been set out. That’s stayed with us, and that’s evolved over centuries; centuries and centuries. And I think it really came to its peak in the twentieth century, sort of mid-twentieth century when you started to get these schools of thought formulating rules, formulating systems like the idea of a grid system. So Jan Tschichold and Josef Müller Brockmann coming up with these not-quite rules, but guidelines to make things beautiful on the printed page.
And effectively what designers are doing here is they’re taking the page which is their known constraint, okay—they know the size of the page, that’s something they understand—and they’re taking the grid system—which is a set of guidelines and rules, a methodology—and effectively they’re applying order onto that known constraint. So what that gives a designer in the print world is control. They have a certain level of control over what’s presented.
Fast forward twenty years ago, and the web comes along, and a lot of print designers took one look at the Web and were like “Aaargh!” Not pretty, right? We’ve had hundreds of years of designing for print and making things look beautiful: the web comes along and we don’t even have images, right, we’ve got no way to control the experience on the web. But some smart folks came up with systems.
Does anybody remember this book, Creating Killer Websites, by David Siegel? All right, Scott remembers it. Jen remembers it. Okay, we’re showing our age here. Oh, Jason and Kevin. So David Siegel was basically the man who came up with the spacer gif and the idea of using tables for layout. And to be fair, at the time, that was all we had. I mean there was no other way to lay stuff out on the web. It was a hack, sure, but it was a really clever hack, and a really useful hack. And now we could start to impose a certain amount of control onto what was presented to the end user.
Actually, a couple of years later, David Siegel wrote something like, ‘the Web is broken and I broke it’, so he did repent his ways.
So what was happening here was exactly the same as what was happening with print, it’s that you were applying the table layout onto the browser to apply that order onto your constraint, to give you that sense of control. And later on, we swapped from tables to CSS, which you know, took a completely different mindset. We all had our brains re-tuned by the CSS Zen garden. But fundamentally, it didn’t change this model. We were just using a different tool set now; instead of using tables for layout and spacer gifs, we were using CSS for layout and presentation. But it was the same idea that the CSS would impose the order, would impose the rules and guidelines onto the constraint of the browser window. But that’s the problem. That’s the problem. The browser is not a known entity. It’s not like the page. When you’ve got a page, you know the width, you know the height. With a browser, you don’t know that. It is unknown.
Now, if I’m going to start talking about unknowns, there’s one expert I must invoke at this point. History will remember him as a murderous bastard, but he actually said a very clever thing. Donald Rumsfeld said:
There are known knowns. There are things we know that we know. There are known unknowns; that is to say they’re the things that we know we don’t know, but there are also unknown unknowns. There are things we do not know we don’t know.
People made fun of him for this, but it’s probably the most sensible thing any human being’s ever said ever. It’s brilliant; it’s absolute genius, and it’s absolutely true to the web. We have our known knowns, our known unknowns, and our unknown unknowns.
So with the browser, there’s a whole bunch of unknowns that would probably fall into the known unknowns category. Like, we know that we don’t know about the speed of the user’s network connection, right? We don’t know whether it’s a high bandwidth, low bandwidth. We don’t know the capability of the device. At least until we’ve served something from the server. I mean, when a browser sends a request to the server, at that point we don’t know whether the browser supports a certain plug-in, or what its JavaScript support is like, or any of these other capabilities. And crucially, we don’t know the size of the viewport. Until we’ve sent something to the browser, we don’t know that. It’s a known unknown. So very different to the printed page.
So how did web designers deal with this? How did they deal with the unknown? I’m going to look at size in particular here for a moment.
Well, they basically pretended that they did know. Kind of there was this unspoken agreement to pretend that we had a certain size. And that size changed over the years. For a while, we all sort of tacitly agreed that 640 by 480 was the right size, and then later than changed to 800:600, and 1024; we seem to have settled on this 960 pixel as being this like, default. It’s still unknown. We still don’t know the size of the browser; it’s just like this consensual hallucination that we’ve all agreed to participate in: “Let’s assume the browser has a browser width of at least 960 pixels.” That’s a pretty dangerous assumption. It’s like the old physics jokes “assume a spherical cow.” It’s a very dangerous assumption to be beginning with at the very start of your process.
But I understand why designers wanted to do this, because then they could think in fixed dimensions, and especially if they’re coming from that print background, they have hundreds of years’ worth of guidelines and rules on how to deal with a fixed medium, that if we do know this size, then okay, now we can start using everything we’ve learned from print; typography and grids and colour, all this stuff. And there’s a lot to be learned from print. As I say, hundreds of years of thinking of methodologies, of guidelines.
But the Web is not print. Okay? We know that. It needs to be embraced as its own medium.
And I think the first step to embracing the web as its own medium is to stop thinking in terms of fixed sizes and to start thinking flexibly, which when it comes down to your CSS—or your table layouts, frankly; it doesn’t matter whether we’re talking about tables for layout or CSS—thinking in terms of percentages rather than fixed units like pixels.
So this is what I’ve been ranting about for about, you know, over a decade now, I’ve been saying that the default way we should build our websites is flexibly, because the Web is a flexible medium. And yet, the default way that websites have been built for so long has been fixed. The default is that people open up whatever their design tool is, and they start with a 960 grid; that consensual hallucination, and take it from there.
Now there may well be times when that’s the right course of action, but I don’t believe it’s the right default course of action.
I’m not the only one who’s been thinking of flexibility as the way to go; percentages are the way to go. In fact, over ten years ago now, Jon Allsopp wrote an article on A List Apart magazine called A Dao of Web Design. Raise your hand if you have read this article. Good, okay, good to see some hands. Everyone else: please read this article. Honestly, this is probably the greatest piece of writing on the Web. It’s almost eleven years old and it’s more relevant today than ever before. And it is a manifesto for us. It is the star we sail our ship by; an amazing piece of work.
And all John was really saying in this is let’s embrace the web for what it is. From back then, print designers were railing against what they saw as the constraints of the web. We don’t know the browser size; there’s certain colours we can’t use; we can’t use the fonts we want. Yes, all those things are true; embrace that. But also embrace the flexibility the web gives you; the fact anybody can visit your site using any kind of device: that’s fantastic. The fact you can link off to other resources: can’t do that in print. The fact that you can update things immediately: can’t do that with a physical medium. Embrace all these things that are true only of the web. To accept it as its own medium.
In this article, he talks about how pretty much every new medium begins by aping the medium that come before. So when radio came along, they started doing plays in the radio, and when television came along, it was radio on television. And it took a while for these mediums to evolve their own language, their own tropes, to really become their own medium. And I think the web, it’s still pretty young, right? Twenty years, one month and a few days old, I think. And I think we are still kind of aping the previous medium which was mostly print. I think we’re taking a lot of our cues from print, and that’s fine; there’s a lot to learn, but this is what we should be doing. It was true back then and it’s true now, embracing the flexibility. Designing for that flexibility.
So I was wondering why didn’t designers do this. Why didn’t designers embrace the flexibility of the Web? Why do they keep thinking about it in fixed terms rather than flexible terms. And I think a lot of it is to do with the tools. The tools that they were using to create their websites. Thanks, Jason.
And I don’t just mean the WYSIWYG editors like Dreamweaver, FrontPage, all these things: it’s easy to pick on them, they’re clearly in the wrong because WYSIWYG as applies to web design doesn’t make sense. But I kind of mean all the visual design tools. I mean things like Photoshop or Fireworks, Illustrator. Because what’s the first thing you do when you open up a Photoshop document or a Fireworks document? You create a new document and input dimensions. Fixed dimensions. Straight away, you’ve made a really fundamental design decision that’s going to affect the course of the whole site; really fundamental. So I think the tools are problematic.
And other people have been talking about this, you know, Jason Santa Maria wrote a blog post about a truly web-native tool that kind of combined the best of the browser and the best of Photoshop, and we need that. I don’t think it’s going to come from a company like Adobe, frankly. Monopolies rarely innovate in that field.
Other people have been saying that the way to go would be to get straight into the browser. Andy Clarke advocates this, and he’s got a good point that we’re kind of being dishonest to our clients when we show them pixel-perfect mock-ups and say, this is what your website’s going to look like. Okay, it’s going to look like that in one set of browsers, but you can’t really know, and to start showing them it in a browser itself is much more honest and a much clearer way to show how it’s going to behave in its own medium. And I think he’s onto something. And people talk about the constraints of designing in the browser, but I think Photoshop has its own constraints as well.
But all of this debate about what’s the best design tool to use for the web, you know, starting in Photoshop, moving to the browser, starting in the browser, doing a little bit of …it all would’ve remained fairly academic, I think. I think we’d still be just having, you know, discussions on blogs and we wouldn’t fundamentally be changing the way we work, except that things changed in a big way with the rise of mobile devices.
This really changes everything and I would say going back the past few years, especially with the iPhone coming out and realising that, wait a minute, you can actually view websites on a mobile device and it doesn’t have to be a really shitty experience. It was a kick up the ass for every other mobile browser, mobile vendor out there.
And developers freaked the hell out, because how the hell are we supposed to design for this? We’ve got all these devices with all these different sizes, different capabilities; how are we supposed to deal with all these unknowns? We don’t know the network speed; we don’t know the capabilities, JavaScript and otherwise. We don’t know the size, the dimensions of the viewport.
We never knew.
We never knew any of these things, but the rise of the diversity of devices of mobile devices, tablet devices; it just highlights how much we never knew this stuff. Because it isn’t actually anything new. All of these unknowns were always there, but we all just agreed to ignore them. We all agreed to pretend that everybody’s got a fast connection and we’ll pretend everybody’s got 960 pixels to play with, right?
But now it’s been thrown into sharp relief that we don’t know these things and we never knew these things. And that’s going to change everything; the way we’ve been building websites; it just doesn’t work.
Now there’s different ways to react to this, and one way is to start talking about this idea of a mobile web, that everything we’ve been doing for ten, twenty years, we’ll keep doing that. But we’re going to silo things for this diversity of devices and refer to it as a mobile web, which as I say, it’s kind of silly; there isn’t a separate mobile web. That kind of thinking, I guess it’s epitomised with the idea of the .mobi TLD, right? You actually have a different top level domain because of the kind of device you’re going to be serving up to. Probably the stupidest idea in the history of stupid ideas. You can quote me on that.
I don’t think this scales particularly well to immediately just start siloing, and to just, you know, leave things the way they are for the rest of the web, to say we’re going to continue doing 960 pixels and fast connection illusory design over there, but we’re going to silo things for this specific class of device over here. There’s just so many different devices.
And where do you stop? I mean what about you know, you’re going to have a mobile web and a desktop web; tablet web? Where’s that? Is that the mobile? Is that the desktop? Erh? Maybe it isn’t as black and white as we’d like to pretend. It’s actually the sliding scale. If I’m on my laptop with a 3G dongle while I’m travelling somewhere, am I mobile? My desktop? It’s that large screen, small connection. You don’t know. These are all unknowns.
So I don’t think it makes sense to be siloing into these different silos because it doesn’t scale. Internet-enabled fridge web? How many webs are we going to have?
So the language, as I say, the language we use I think influences our thinking here, so I’d like to stop us saying this, mobile web. I know it’s tricky, because it’s a nice short-hand way, you say, “Oh I work on the mobile web.” But straight away you’re framing things in terms of silos, so at least just question this idea of thinking in terms of mobile web.
The other approach is to talk about one web. Okay, that one web is the way to go. And this is the drum that I bang all the time, right? One web, one web is the way to go, and I do believe that, staying true to Tim Berners-Lee’s vision. But talking about language, this is a tautology, one web. Of course it’s one web, you know, it’s redundant.
So we could come to an agreement; if you guys all stop saying mobile web, I’ll stop saying one web. And we all just start saying web, okay? We’re developing for the web. And we don’t know what the devices are. And the default device probably won’t be desktop; it’ll probably be mobile most of the time. I’ll stop saying one web; you stop saying mobile web, we could agree on that?
But most importantly I think what we all need to do is what I need to do, everybody needs to do, is to start embracing that flexibility, okay?
I don’t think it’s good in the long run for our businesses, for our clients, to just be siloing for the now and not thinking about the future unknowns. You might make loads of mobile silos for all the current devices; next week a new device comes out. Now what you gonna do? It’s a red queen arms race; it just doesn’t scale.
Which I think James pointed out really well, that maybe a couple of years ago it made sense; you could concentrate on one class of device, but then as more and more devices came out, it simply doesn’t scale.
In fact, what I’m seeing, and what really worries me, is a repeat of a lot of the mistakes we made maybe eight years ago, when we started making sites for a specific type of browser because that browser was in the ascendant at that time, and I’m seeing that same mistake now. In short, I think WebKit is the new Internet Explorer. Not in terms of device capabilities; it’s a very capable browser, but as I see a lot of developers developing specifically for WebKit, and they might as well slap a button on their site saying, “best viewed with.” It’s again trying to pretend that there is a known where really it’s an unknown.
And it’s not really a choice, I think. You can pretend for maybe a bit longer than we can continue to build desktop sites and we can silo things for mobile sites, and if you have the budget for that; that’s great, but it’s not going to scale and eventually you’re going to have to change. I feel that the mood in web development right now, there’s a lot of fear about this changing landscape, but it’s also really, really exciting, and it actually reminds me of the Web Standards movement when that came along, trying to convince people to move away from table layouts and spacer gifs and start embracing CSS and separating your presentation and your markup and all that. There was a lot of resistance to that because people were very comfortable, and there’s a lot of resistance for thinking about the mobile experience for all users, for thinking about the diversity of devices, because people have been very comfortable for a long time, pretending that there’s a set of known devices that we’re designing for.
Now, I’m pretty sure you’re all familiar with the idea of responsive web design. Who’s read Ethan’s article on A List Apart? Okay, most of you; good. Now Ethan actually references John Allsopp’s article, the one that I think everyone should read.
So responsive web design is kind of a way of marrying the old and the new, and what I really liked about Ethan’s article and Ethan’s thinking, coming back to the language perspective, is that he didn’t just give it this term as a wishy-washy thing, like, “Oh, responsive web design is a state of mind; responsive web design is an approach.” No, no. He made it really clear that it was a set of technologies; three technologies in particular: that it was fluid grids, which Ethan and myself had been railing for years. You should really be using liquid layouts. And everyone ignored us. Haha; who’s laughing now? Fluid grids. Fluid media: images, video that that stuff can scale. And media queries.
Now, media queries as that third technological part, that’s the bit everyone focuses on. In fact I tend to see people use the term responsive web design and media queries interchangeably, but media queries are just one part of responsive web design, and in my opinion, maybe the least interesting part.
So I really like the fact that Ethan had not just coined a new phrase, but had been very specific about it, because I think there is power to language. I was very honoured when Ethan asked me to write the foreword to his book, Responsive Web Design. Who’s got this book? Awesome. awesome.
So in the foreword, that’s what I focussed on, was the power that comes with naming something. If you don’t mind, I’ll read what I wrote there. I said:
Language has magical properties. The word ‘glamour’, which was originally a pseudonym for magic or spell-casting, has its origins in the word ‘grammar’. Of all the capabilities of language, the act of naming is the most magical and powerful of all.
The short history of web design has already shown us the transformative power of language. Jeffrey Zeldman gave us the term ‘Web Standards’ to rally behind. Jesse James Garrett changed the nature of interaction on the web by minting the word ‘Ajax’.
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 doing so, changed the way we think about web design.
Kind of getting back to that George Lakoff idea, metaphors we live by.
There was resistance to Ethan’s approach. I think a lot of it stemmed from some misunderstanding, and I’d like to clarify some of that misunderstanding.
I think there was this idea that responsive web design offered an easy way out for traditional web designers who had been building 960 pixel pages with bloated images and all that stuff, saying “Oh, it’s okay; we’ve got an escape hatch which is responsive web design. All you need to do is sprinkle some magic media query fairy-dust onto your website and now it’s a mobile optimised site.” No. That’s not ever what Ethan was trying to say. In fact, he doesn’t really specifically talk about mobile so much as small screens, because things like flexible grids, flexible images, that’s about sizes. It’s not about device capability, any of this stuff. So this idea that you can smatter on media queries after the fact, I don’t think works very well.
That said, when I was first experimenting with things like this, I did have some success. I’ll show you an example of this.
So this was a website for a school in London that we built at Clearleft. Now the brief for this was that it was a desktop optimised site, so it is a device specific site. I think almost every website that’s been built for the last twenty years has been a device specific site and that device has been the desktop or laptop computer, and this is very much a device specific site. It’s not a mobile site.
And it’s essentially a brochure site, so it’s all about, you know, this beautiful place with lots of big images. Really not for mobile devices.
So we launched it and the client was very happy, but he said he noticed there was a lot of people accessing it on, you know, iPhone, it was teachers using iPhones and stuff, or iPads that they’d got for Christmas and you know, could we make it look a bit nicer on those devices? These phones would scale things down nicely, and that worked fine, but it made it a little tricky to hit some of those links, stuff like that.
And I was like, “Oh boy, that…that’s not really the way it works. You can’t come in after the fact and retro-fit for a mobile device.”
But I went in there to see what I could do. And as it turned out, within an hour or two I was able to make it look okay on these small screen devices. But that was only possible because the developer who was working on this originally, Natalie Downe, is probably the best front-end developer I’ve ever met, and everything was already built in a bulletproof, fluid way.
It was a fixed width design, but she had built it with percentages anyway, and added one rule at the top to fix it to that 960 grid. There was a carousel on there, fixed dimensions. She built it so that it was flexible. She was designing for the unknown. She didn’t know that this design would have to adapt to different devices, but because she’s a proper web developer, she approached it that way.
So by throwing in a few media queries, I was able to adjust to different screen dimensions and ensure that it was at least legible at these different sizes. But that’s not a mobile optimised site. That’s small screen optimised to a certain degree, though you know, serving up the user a whole bunch of navigation as the first thing they see is not really a great experience.
So I would never claim that this is a solution for mobile devices. This approach of, “Oh we carry on building our desktop ways, and if you’re lucky and you’ve already built with flexible grids anyway, and you’re already thinking of fluid images, then a smattering of media queries will take care of it.” You know, it helps; it’s better than nothing, but it’s not really a sustainable approach either.
So a lot of people were picking on sites like this—there’s a lot of blogs out there that take a similar approach—a lot of person sites saying that’s really not mobile optimised, and they’re right. It’s not mobile optimised: they never claimed to be mobile optimised. Small screen optimised to a certain extent, but not mobile optimised.
I think if you want to really ensure that a site is going to work well on this multitude of devices, then the only way to approach it is to think of those devices first. And this is something that Luke talks about, this idea of Mobile First.
And it’s actually a great way to design, I’ve found; really forcing you to clarify. What is this page about? When a user goes to this URL, what’s the one thing they need? If it’s some content, get them that content. If it’s a task they need to accomplish, get them that task straight away. Instead of thinking, “Hey we’ve got a 960 pixel wide grid here to play with, what can we throw in there? Let’s have this, let’s have that.” No, no, you’ve really got to clarify and focus.
And once you’ve got that sort of mobile first approach, then you can start to enhance for those larger devices, larger screens, faster connections. But beginning this way is definitely the way to go.
Even if you never actually build a mobile site, it’s a great thought exercise. To a certain extent, you could try it with other things; you could say, okay, let’s do print first. What if we start with the print stylesheet? If you’re building a food site with lots of recipes, that might be a way to go.
Really what this exercise gets down to is this idea of Content First; thinking about what is it that the visitor to this site needs to get at.
And when I say content first, I don’t mean copy first. That could be the case if your site is copy heavy or a newspaper site: it’s about getting to the headlines straight away. But this could also be a task. What’s the task that the user needs to accomplish on this page? Do that. Get that to them first.
So this Content First approach, it’s the way we should’ve been doing things all along, but I don’t think we have. Instead, what we’ve done is we’ve focused on the container; we’ve focused on the layout and then we pour the content in. We’ve been making buckets for our content. And you have to start with the content; that’s always been true, even before this rise of mobile devices.
And the nice thing about this Content First approach is that it maps really well to the methodology that hopefully most of us have been using a long time on the web: you begin with your content, then you layer on your presentation using CSS and then you layer on your behaviour using JavaScript. And hopefully you’ll recognise this stack as the idea of progressive enhancement on the web.
Progressive enhancement is effectively what differentiates the web technology, the web stack, from other technology stacks. If you’re building a Flash site, then either someone has the Flash plug-in or they don’t. It’s binary. One or zero. If you’re building a native app for a phone, either the person has the operating system that runs your app or they don’t. One or zero: on or off.
But on the web, it’s this tiered layer of support. You can at least assume that they will be able to parse HTML, that can be your lowest common denominator, and then if you add on your CSS in the right way, the browsers understand that CSS will get it; the browsers that don’t, don’t, then that’s fine. Inside the CSS itself you can start using more advanced selectors, start using stuff in CSS3; get your rounded corners and your gradients, whatever. The browsers that support it get that; the browsers that don’t, don’t. Nobody dies, it’s fine. Same with JavaScript, okay, you do detection first. Does this browser understand this object? Does it have this capability? If so, execute this script. If not, stop right now. Progressive enhancement.
So while I’m saying that the way we’ve been building websites for all these years has been fundamentally flawed, and we need to change everything, the one thing I don’t want to lose is this idea of progressive enhancement. I don’t want to throw the baby out with the bathwater there.
So we’re very lucky on the Web to have this stack. It’s because of progressive enhancement, because of these layers of technology that we can cater to all these different browsers and devices.
Because these three ideas map very well to the technologies that we use: HTML, CSS and JavaScript. You’ve got your structured content, your presentation and your behaviour. This, by the way, is the upper back torso of my friend Lynn who’s really into web standards. Even I do not have that kind of dedication.
So: content first is the way to go in my opinion, although my friend Drew says coffee first. Probably true: coffee first, then content, and we’ll take it from there.
Something I do when I’m designing now is to stop thinking about the container first. Stop thinking about the buckets that you’re going to pour the content into, and instead start with the atoms. Start with the pieces that the site will be built of, without thinking about the container that those pieces will be in.
So I put together these kind of pattern portfolios, all the different patterns we’re going to need on the site. This also by the way makes a great deliverable when I’m working with server-side developers; here’s the HTML, here’s what you get. And I can be re-sizing the screen, make sure it works at all sorts of sizes: really wide, really small, not thinking about the context in which these pieces will find themselves, just making sure they work, you know, the kind of things you’re going to see on most …error messages, breadcrumb trails, pagination, all these kind of patterns. Sometimes they get a bit complicated …buttons and all this stuff. Starting from these small pieces and working out, instead of starting from the layout working in.
Here’s an example of a site built for last year’s UX London conference. This is a conference we put on every year in London. There’s a new design now for next year’s conference which is also worth checking out. But here you see on a small, constrained kind of sized screen, and you see I managed to fit in two bios here; there’s a head shot and a person’s name and a little bit of information. And on this sized screen, that’s about as much as I can fit in, but as a device with a larger screen visits the site, I can start to expand a bit, say, “oK now I’ve got room to fit maybe three of these head shots in one line.” And as we get wider again, I’ll say “Oh great, now I can fit all six.” It’s really liberating. I started small, now I get to expand in these larger things.
Now the important thing is, each time I switch the layout there, going from two to three to six, those break-points, those changes, were not dictated by the size of devices; they were dictated by the content. When did it make sense for the content to switch from two to three to six? Because again, I don’t think it scales to just choose your break points based on whatever’s currently popular. So at the moment we’ve got 320, 480, 640, whatever, but there’s so many different devices out there with so many different sizes and dimensions that it makes much more sense to let your content decide when is it time to expand; when is it time to allow some breathing room.
Here’s another site, Tim mentioned this site, Huffduffer, that I’ve built in my spare time. So here we see this is a profile page and this is the default, this is how it’s going to look on a small screen, and as I get a bit more room to play with it, I can start adding in some white space; this is good, a bit of breathing room. And as it gets bigger again, start introducing a column structure, sort of 50:50% there, and as I get wider still, I’ve got a different ratio, sort of a golden ratio between these columns, and it makes for a really bulletproof site.
And everything in between those points, because I’m using percentages, everything in between those break points also works. All those unknown unknowns; it’s because I’m being flexible, it’s just going to work.
And something else I actually do on this page, is in the sidebar, once the screen is large enough, I start to pull in some content after the page load.
So this idea of content first, you think about what’s the most important content on this page? What is this URL for? Whether it’s a task, whether it’s a piece of content, a silly tweet or a scholarly paper; what’s it for? And that’s where you start. That’s your HTML. But once you get this larger playground to play with, then you can start to think, what will be nice to have? What could I introduce for the people, you know, assuming larger connections—dangerous assumption—but definitely larger screen, because we can test that with Javascript. And then I start to pull in the nice to have content. So often it’ll be content from a third party that could drop into a sidebar on a large layout. But on the smaller screens like, you know, let’s leave it with the core content; let’s not pull that in.
So this is essentially the idea of conditional loading. I was referring to this as lazy loading, which is a programming term that I think is probably completely the wrong term to use for this, but it kind of makes intuitive sense, again with the language, lazy loading has a nice ring to it.
But then that allows us to think of our content as a tri-state. Up ‘till now, when we’re designing websites, at the start you think your content strategy, it’s like, what’s the content on this page? And either the content is on the page or it isn’t. Binary. One or zero, on or off. But with the idea of conditional loading, you get to think, okay, what’s the main content on this page and what’s the content it would be nice to have if there’s room for it?
So now you start to see how this approach of content first, of thinking about the smaller devices first and building out fundamentally changes every step of the design process, even before we get to the visual design and we’re talking, you know, the content audit, the content strategy of the site that is affected by this approach. So this really is a very different way of thinking.
And I’m excited about this thinking. My friend Mark Boulton talks about this as really quite a fundamental change from the way we’ve been designing for centuries on print, which is that for centuries, we’ve had the known dimensions of the canvas and we’ve been designing canvas in, as he calls it. Now it’s time for us to change and design from the content out.
And as I said, I think it’s going to happen. Some people will be dragged kicking and screaming into this new way of thinking, but it’s going to happen. I mean right now, the amount of people visiting sites on mobiles is huge; it’s growing exponentially. The rate of change is just unbelievable. I’m sure you’re going to hear a lot of data points from the other presenters over the next few days about just the sheer number and sheer diversity of mobile devices. So we do need to change the way we think.
But I want to pre-empt some questions you might be thinking, so yeah, that’s all well and good, but….I’m going to try and address some of the buts.
But, you say, what about web apps? All this is well and good for websites, but what about web apps? Now here we do get once again to the idea of language and naming things, and in this case, the question of language comes down to, what the hell is a web app? Define web app for me? I just did the tautological explanation that, well it’s an application on the web. That doesn’t really help.
James recently published a blog post, actually just two days ago: perfect timing because he’s written a wonderful long blog post, examining what is a web app, and puts forward this explanation, that explanation and I don’t know: I don’t think it is possible to define it. Everyone kind of has their own definition, which isn’t really that helpful. If you’re trying to discuss something, if everyone has their own definition of the same word, that actually doesn’t aid communication, it hinders it.
A good example of that would be the term, Web 2.0. A couple of years ago, everyone was using that term. You’d be sitting in a meeting, one person uses the term, Web 2.0, and they mean it to mean like, you know, oh rounded corners and friendly typefaces and bright colours. Meanwhile, the person sitting across the table, oh Web 2.0, this new kind of business model. And someone else is saying, oh Web 2.0, that’s about, you know, network effects and sharing and collaboration. Everyone using the same term, meaning different things.
I think we have that with web apps. Nobody’s ever defined what a web app is, but everyone’s using the term web app all the time. It’s kind of like there’s the famous obscenity trial where the Judge had to try and define obscenity, and ended up saying, I know it when I see it. That’s kind of how we talk about web apps, like I can’t define it, but I know it when I see it.
I want a definition. We demand rigidly defined areas of doubt and uncertainty. I want to know what you mean when you say web app.
Sure, you can point to things, like “Oh well something like Twitter.” Wait, so you a reverse-chronological list of texts with one form field and one button is all it takes to be a web app?
Hmm …Gmail. Again, actually mostly text and inputting into a text area. These things could be progressively enhanced. Generally they’re not; people are doing it wrong, but they could be progressively enhanced.
And I don’t know if it’s useful to talk about web apps this way. Brian, I think, shares my feelings generally when these kind of debates come up, you know, web apps versus documents this versus that; we spend a lot of time debating it, I’m not sure it’s useful. I’m not sure it gets us very far.
The problem with web apps in particular as a term is I see it used as a Get Out of Jail Free card. People say, “Oh yes, I’m totally behind universal access and I think progressive enhancement is the way we should build websites, but I’m actually not building a website: I’m building a web app, so none of that stuff applies to me.” It’s like, no, web app card. I don’t have to think about accessibility; I don’t have to think about people on feature phones: I’m building a web app, so none of it applies to me.
And we’ve been here before with Ajax. When Ajax came along it was like “Great, now I don’t have to worry about all the stuff because I’m building a web app using Ajax; therefore progressive enhancement no longer matters. Accessibility no longer matters.”
So I worry when I see people cling to the term web app, that what they’re actually doing is looking for an escape hatch to make things easier for themselves.
But the truth is, there is of course this scale; documents; apps. Everything lies somewhere in between. As soon as you put a link on a page, it’s interactive, it’s kind of appy. As soon as you have a form on a page, it’s kind of an application: you’re accepting input from the user.
And the truth is, whether you do serve up one document to everybody or whether you do put things in a silo for specific devices—that can sometimes be the right solution, sure—because this is the real answer, isn’t it, to everything when it comes to web design:
It depends.
I would love to be able to stand up here and say, you know, one web is the way to go; responsive design is the only way we should be doing it, but come on, let’s be honest: this is the only true answer to pretty much every question there is about web design. So that’s…my response to what about web apps is, (a) define a web app, and (b) sure, it depends, maybe.
What I’m questioning is the default. What I’m questioning is what we do by default. Don’t cling to that lifeboat of web apps and say, “Oh none of this stuff applies to me and I’m not even going to try to reach everyone. I’m building a web app, therefore I have a Get Out of Jail Free card.”
And the other thing you might be thinking is, “Okay, content first; that’s all well and good, but with these mobile devices, surely what matters is the context. The context of where the person is, what they’re doing with their device at that moment that they access your URL.”
And that’s absolutely true. The context is probably the most important thing when it comes to design, and if we could design for context, it would be great. But I’m sorry. We can’t.
Now we talked about the known knowns, the known unknowns, the unknown unknowns. This is a known unknown that we know we can’t know what people are thinking. We can’t read people’s minds when they come to a site. We don’t know what they want when they come to our site.
We make assumptions. Sometimes they’re good assumptions, sometimes they’re very, very dangerous, and making assumptions about someone’s intent based purely on the class of device that they’re using: that’s a really dangerous assumption. This idea that, “Oh I’ve got all this information, but I see you’re on a mobile phone, therefore I’m just going to give you this little sliver. Don’t you worry your little head, you poor little mobile user…”
It’s kind of insulting, right? But it happens all the time, where mobile users are kind of ghettoised and treated differently like they have their special needs. Here’s the cut-down version for the mobile users.
And I wish we could. I wish we could know what people were doing at the moment they access our URL, but we can’t. We’ve never known that, and mobile doesn’t change that.
I mean, I see some developers trying to even do it programmatically, it’s like “Well, I’ve got access to the accelerometer and if I see that they’re moving at a speed of this much than I can therefore infer that they must be on a train and therefore I can do this…” No. Don’t do that. This isn’t a technological problem. This is something you solve early in the process when you’re doing personas, when you’re getting user research and you’re trying to empathise with the user. You can’t know what they’re thinking.
And then we fall into this trap as well of thinking like, “Ph yes, well the person with the mobile phone is walking down the street like this; they’re on the train, they’re on the tube….they’re trying to get directions to the restaurant they’re going to.”
Actually this is a good sort of a bingo card to play over the next two days. Every time that somebody mentions public transport in relation to the mobile context, add an extra line to your bingo card.
But I think Mark Kirby, a developer in Brighton, he put it best when he said that mind-reading is really no way to base fundamental content decisions. I wish we could; I really wish we could, but I don’t think we can.
The other thing, this whole mobile web, desktop web, inferring things about the mobile user and what they want to do. I think it’s dangerous from the other direction as well.
Even if we do try and help out the mobile user by thinking, “Okay, they must be on a slow connection, so we’ll make sure we’re not going to serve up big bloated images and we’re going to get them straight to the content. Forget about the navigation first; put the content first, put the navigation second. Great.” But what about the desktop user? Oh yes, we’ll just keep serving up, you know, nasty big sites to them.
So this is what I question when I see people talk about how everything has change with mobile. I question why just mobile?
So when someone says, performance really matters on mobile. Say, performance really matters, full stop.
I mean really matters. Performance is probably the most fundamental design decision you can make. I say that as the designer. I mean I love my typography and I think typography is hugely important, but I’ve got to say, it’s pipped to the post by performance, the arrow of time takes precedence.
That’s why you are extremely lucky to have Steve Souders here. Seriously, I mean he is literally the man. He wrote the book on performance and he’s going to give you some very valuable advice. But what I would say is all that advice applies everywhere, not just in the mobile context.
I don’t think we should assume, just because the mobile user wants to get to your content fast that the desktop user’s going to be lounging back and has all the time in the world and doesn’t mind being served up big bloated images and loads of crap in their layout, right?
So if you decide, “Oh for the mobile user we’re going to make things really streamlined and get them to the content first and it’s going to be a really fast experience,” then just cut off that first sub-clause where you said “for the mobile user” and just do that for everybody. You’re going to have to.
I mean, these are the kind of sites that are being built today, and it’s unbelievable. Merlin Mann has this Flickr set called the Noise to Noise Ratio. He takes screenshots of sites and then highlight where the content is on the site.
Everything else around it: not the content. This is the content. This is what the visitor to the site actually wanted to read.
I mean, this cannot stand. I’m sure if you went to the mobile version it would be nice and optimised, but where does that leave someone who happens to be visiting on a laptop, happens to be visiting on a desktop?
So in a way what’s happening is we’re kind of preferring, giving a preferential treatment to the mobile user and allowing the desktop user to wallow in this swamp of bloated images in high-bandwidth crap that’s being served around the content.
And you know, people say, “Ah but there’s all sorts of reasons why we have to do this, political reasons, you know, advertising, all this stuff, and so we have to serve up all this crap around our content.”
You keep telling yourself that, but users interpret this as damage and route around it. They will find a way to get straight to your content. It started with RSS; now we’ve got things like Readability and Instapaper. Where they will find a way to get that content first experience that they want. They’ll find a way to make your content live outside of the silo that you were proposing for it.
That’s something worth remembering. You don’t get to dictate. The user has the final say. Every time you write a line of CSS, you’re not dictating the appearance; you are suggesting the appearance. The user can override that with their tools.
Don’t try and force people to use whatever new shiny toy that you think is the best way for them to consume your content, just because of the device they’re using, okay? Let people access your website if they’ve come to your website. Content first.
So the thing I really like about responsive design and this new approach, and specifically I’m talking about the marriage of content first and responsive design, starting small screen and building up. What I like about it is it changes that relationship between the designer and the person who’s going to be consuming the content.
Instead of the designer now trying to impose control, trying to impose that form of tyranny onto the reader or the user, now the user, the reader, gets to decide. And what responsive design does and what this whole new mobile first, content first, marriage with responsive design does, is it meets the user half way, saying “Okay, you’re going to choose to visit my site, with whatever device you want, and that’s Okay, and I’ll meet you half way. I’m not going to try to dictate what you should do.”
And that’s what I’ve been doing, so you know, you want to visit my site on your desktop browser? Sure. Another desktop browser? That’s fine, I’m not going to block you. If you want to access my content on a text-only device or browser, sure, do that. Phones and tablets and all these things, different kinds of phones. Sure, you want to print out my content? If you want to access my content with a device that wasn’t even around when I was building this site, I’m going to try and make sure I’ve catered for that known unknown. Or you may be accessing my site with something that isn’t even a visual reader.
So in short, there is no mobile web, is kind of what I’m saying. There are plenty of mobile devices. And equally there is no desktop web. It is just the web. So that’s why I always bang this drum: one web.
But I think we can come to the agreement, I’ll stop saying one web; you stop saying mobile web. Let’s all just start saying web.
And this idea of starting from the content out and meeting people half way, no matter what device they’re using. I’ve got a name for that too. Let’s call it web design.
Thank you very much for your attention.
The video of the opening keynote I delivered at the Breaking Development conference in Nashville earlier this year. It expands on the One Web presentation I gave at DIBI, focusing on the language we use to talk about our approaches to web development.
Online communication is a wonderful thing but I firmly believe that there’s enormous value to be had in getting together in meatspace for some proper face-to-face discussion. Take the gathering in New York of what later came to be known as HTML5 Super Friends. It was an intense two days of poring over the spec with really smart people. My brain hurt by the end of it but that was a small price to pay for such a rewarding experience.
When the finest minds in mobile recently gathered together in Nashville for the Breaking Development conference, the opportunity for extending the gathering was too good to pass up. By some clerical error, I was also asked along. Thus it was that I found myself in the company of these fine people in a secluded house in Tennessee:
We called it Mobilewood. It was a blast.
It wasn’t all hot tubs and campfires—although there was plenty of both. We worked hard and played hard. Luke did a great job of structuring the event, wielding his managerial experience to make sure that we never got bogged down. We began with some ambitious discussions which led to more focused brainstorming which in turn led to a number of individual projects.
It became clear from fairly early on that simply focusing on mobile alone would be missing the bigger picture. Instead of being overwhelmed by the ever-increasing range of devices out there, we need to embrace the chaos and accept there will be even more devices—and types of devices—that we can’t even anticipate. We should embrace that. Instead of focusing on whatever this season’s model happens to be, we should be crafting our services in a robust way, striving for universal access tomorrow as well as today.
The first project to launch is a manifesto of sorts. It’s a called to arms. Or rather, it’s a call to be future friendly:
- Acknowledge and embrace unpredictability.
- Think and behave in a future-friendly way.
- Help others do the same.
The future friendly site also contains a set of design principles, but they are the starting points for discussions rather than the end points for solutions. Consider them a work in progress.
You can also find a list of future-friendly resources that will most definitely grow over time—probably beyond the bounds of the site.
This is just the beginning. The future is ours to make—friendly.
Luke’s excellent detailed notes from Scott’s talk at Breaking Development about building the Boston Globe site.
One of the recurring themes at the Mobilism conference earlier this year—and more recently at the Breaking Development conference—was the subject of server-side user-agent detection. I posed the question in absurdum on the Mobilism browser panel:
A useful tool for developers or spawn of Satan: which is it?
It’s a contentious issue, as Alex’s strident defence illustrates. Personally, I’ve never been a fan but that’s mostly because of the long history of really, really bad UA-detection in the past. When I discussed this issue with Lyza we came to a détente, agreeing that there is nothing inherently wrong with server-side UA-detection: it’s what you do with it that counts.
In their presentation at Breaking Development Bryan and Stephanie outlined the kind of detection that they have used. Crucially, it assumes a very basic small-screen default—rather than assuming a desktop browser—and later double-checks the profile on the client-side using feature detection.
Luke recently outlined another kind of cautious device detection that he’s calling RESS: Responsive Design + Server Side Components, sending subtly-different DOMs to different classes of device. He also recently wrote about why Bagcheck has a separate mobile site and it strikes me that RESS could alleviate the concerns he mentioned regarding responsive design for Bagcheck.
I think that RESS could be a very useful technique as long as it assumes a safe default: a small-screen, low-bandwidth default. That way, any UA detection would be done against a fairly limited set of user agents: desktop browsers and maybe tablets. To me, that seems far more reasonable than trying to pattern-match against the sprawling jungle of mobile devices in the wild …not to mention the swampy morass of licensing issues with Device Atlas (and now WURFL too).
As ever, smart defaults are really important. Just as truly responsible responsive web design goes hand-in-hand with a mobile/content first approach, I think that any server-side detection should do the same. It completely inverts the problem space. Instead of thinking “How can I stop this nice-to-have content/functionality being sent to mobile devices?” you can assume a mobile device by default and then your question becomes “How can I make sure that this nice-to-have content/functionality is only sent to desktop devices?” (the answer probably involves some kind of conditional loading with JavaScript).
A thornier problem with server-side UA-sniffing is that, regardless of whether you’re testing against a list of mobile devices or you’re testing against a list of desktop devices, you’re still committing yourself to an arms race. You are now obligated to keep your list of browsers up to date.
Still, the rate of desktop browser releases is a lot slower than the rate of mobile browser releases. So if a new desktop browser is released and it ends up being served a mobile-optimised DOM, I think that’s better than inadvertently serving a desktop-optimised DOM to a whole bunch of mobile devices.
That’s just my opinion of course. As ever, the standard disclaimer applies.
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.
I flew into Nashville on the weekend for the Breaking Development conference, which is proving to be excellent so far.
The event is taking place within the Gaylord Opryland (stop sniggering). It’s a very unusual environment. At one point it was a theme park. Now it’s a complex of hotel buildings, parks and restaurants all contained under a glass and metal ceiling. The whole place feels like it’s hermetically sealed—the ideal place to hole up during a zombie apocalypse.
I’ve been inside this world since Saturday evening. I have memories of the outside world. I remember the feeling of a breeze on my face, the sun on my skin. I remember the cash-based monetary system used by the surface dwellers; so inefficient compared to the unique identifier contained in my room key.
I began to realise that, in the absence of any evidence that I was in fact still in Tennessee, it was entirely possible that this self-contained ecosystem was not necessarily earthbound. What if I’m in an orbital habitat? Or a generation starship?
I’ve been surreptitiously attempting to explore the shape of the complex—without drawing too much attention to myself (I think they’re watching)—trying to figure out if I’m in a Stanford torus or, more likely, a Bernal sphere.
The builders have created a near-flawless illusion of the homeworld. The climate control has been consistent and the gravity is a perfect Earth 1. I’m a little nervous about the possibility of a meteor penetrating the shell and causing decompression problems, but I think they must have a phalanx of automated lasers on the outside hull to take care of that eventuality.
There are plenty of plants under the glass dome, which should ensure a renewable supply of food. Strangely, I haven’t seen any animals (apart from fish) but most of the food available in the restaurant appears to be meat-based.
I don’t know how long the voyage will last. I don’t even know where our destination lies. But so far there are no hardships to endure. Our hosts are ensuring our psychological wellbeing with a plentiful supply of piped music …though why it is exclusively country music remains a mystery to me. We are, after all, a long, long way from Nashville.
Luke’s notes from my talk at the Breaking Development conference in Nashville summarise my points nicely.
I’ve just seen this incredible presentation from Stephanie Rieger at the Breaking Development conference in Nashville. It’s absolutely packed full of fantastically useful ideas. You really should’ve been there, but these slides can give you a taste of the presentation.
I’m living inside Keynote these days. I’ve got a string of speaking engagements coming up and I’m freaking out about all of them.
The big one is the full-day dConstruct workshop I’ll be leading called Responsive Enhancement. I’ve been working on it solidly for the last month and I hope that it’s all going to come together this week. I’m quite excited about it. If anything, my concern is that there won’t be enough time in one day to cover all the things I want to geek about.
Lest you think that is a blatant plug to entice you to book a place on the workshop, that ship has sailed, my friend: the workshop sold out a while back. But you can still book a place on Scott’s jQuery Mobile workshop or Josh’s Mobile Design workshop. And remember, a workshop ticket gets you complementary access to the dConstruct conference (which sold out in a day).
Maker Faire Brighton will take place the day after dConstruct but I’ll probably be too busy making frantic last-minute preparations for Aral’s Update conference at the Brighton Dome two days later. I’ve been invited to deliver an 18 minute rant and permission has been granted for me to be as controversial as I wish. I’ll try not to disappoint. Tickets are still available if you want a piece of the action.
Later that week I’ll be up in London for the Adobe Expressive Web Tour. In this case, I haven’t explicitly asked permission to rant but I’m going to do so anyway. Hey, if you’re going to ask me to give a talk called “The State of the Web” in the same month that you dump Adobe Muse on the world, you’ve gotta expect some flak, right?
Then I’ll be flying out to Nashville for the Breaking Development conference which kicks off on September 12th. I’m feeling distinctly outclassed by the ludicrously smart line-up of talent that will be presenting there. And I’m supposed to open the show! gulp
Given that the title of my talk is There Is No Mobile Web, it may sound like I am once again courting controversy, but actually, I consider that to be a fairly uncontroversial viewpoint.
Much as I’m looking forward to the time in Tennessee, it’s a shame that I’ll have to duck out of town in the middle of the Brighton Digital Festival. I’ll miss out on BarCamp Brighton and Flash On The Beach.
Fortunately I will still be in town for Brainy Hacks on September 6th. It looks like Clare is putting together a great event: an evening of brainstorming design solutions for a non-profit:
Calling all creatives, strategists and planners - we need you to donate your brain to charity. We have a great brief from a not-for-profit organisation and you have two hours to solve it competing in teams of up to five to have your idea judged the best by our mega judges.
But if the time is going to pass pleasantly—with some food and drink to stir the creative juices—then a sponsor needs to step up and claim the glory. If you know of an appropriate organisation, get in touch with Clare.
Now, if you’ll excuse me, I need to get back to frantically putting slides together while I swirl deeper and deeper down into a pit of inadequacy-fuelled pseudocompetence.