One Web
A presentation from the DIBI conference held in Gateshead in June 2011.
- 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.
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:
- a fluid grid, a flexible grid, exactly what John Allsopp was talking about,
- fluid images, perhaps different sized images for different media, and
- 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="global.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="layout.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="layout.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="layout.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="layout.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.