One web

December 9th, 2010

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

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

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

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

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

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

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

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

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

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

Hear me out.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Responses

Too often we find the difference between one format of a website and another is to it’s detriment. The argument that there is a need for more than one type is moot. It’s the "lazy man’s load" as my grandmother would have called it. There are those that will argue (as you’ve pointed out) that there is more work in producing a mobile version and a desktop version of a website/web application but why is that time not invested in producing a more universal approach to the site or application being built? The result of the latter is a far more rewarding experience for users coming from their various access points around the web and will, in turn, generate more repeated traffic. Not only traffic from a desktop source, but will encourage users to visit from alternative technologies and word of mouth always helps with that type of advertising.

Thought provoking post. One particular concern: given that your writing is influential with regards to how people markup web pages, I think the way you’ve suggested that the aside element is a good candidate for "cruft" is unfortunate. The aside is certainly for things that are "aside" a main text, but those things may well be essential or even critical to the page in all renderings.

In any case, I think your comments might be taken by some to suggest that aside is an element specifically for layout or interaction design features, and not for textual features.

I’ve followed your commentary on this issue with a lot of interest lately, but also with a certain amount of frustration. I very much agree with your stance on "one web" when it comes to content. The ideal state of the web is that all the content should be available on any device that can access the web. As designers and developers, to the extent we can do this without compromising the experience, we should.

When it comes to design, though, I’m more conflicted. I don’t believe in "one design", and I don’t think it’s realistic (or desirable) to expect one design to adapt programmatically to every size and layout, even with all the full force of tools and techniques we have available to us on the web. Even if I had the technology to design a poster that scaled down automatically to become a postcard, I wouldn’t do it. Both the poster and the postcard would suffer.

To be fair, I don’t think this is what you’re suggesting at all. I do think it’s important as we have this conversation as a community that we distinguish between loss of functionality and degradation of experience, and acknowledge that they are interdependent. We can adapt everything on the spectrum of pages and apps to retain their full functionality at any possible size and shape of display and mode of interaction. But if in doing so we give up the ability to deliver an ideal experience to any of them, I think we’re taking a step backwards.

There’s nothing revolutionary about best practices - it’s just that the implementation becomes easier over time. I still see websites with "click here for printable version" when we’ve had the benefit of print stylesheets since as far back as I can remember.

Media queries and responsive design are just layering another level of granularity onto what we should all have been doing all along, which is to design from the content out.

The (paraphrased) ‘one-url-for-one-document’ mantra is great when the web is one of essentially immutable documents.

But isn’t it time to bust through this assumption? - as we (and even consumers) start to think of the web as being more one of apps? One which should flex and adapt to give the user the best experience (by which I include content, functionality as well as user interface and pixels) possible, given everything we can divine about the human using it?

If an application is to provide the service that its user needs, the more clues about what that human is doing the better. If they are using a mobile device, there’s already a big clue about what that user’s state might be. I’m intrigued by things like Nokia’s Situations project too, as it permits more insight into what the user is doing, where they are, and what state of mind they’re in. Imagine how you might be able to optimize a web experience - to the human - given such clues!

So as you can tell, I’m excited about this. A far more fluid web that is truly responsive like this. Responsive to human context (in all its possible forms) and not just the temporary challenge of smaller numbers of pixels. It’s not that I’m not a fan of RWD - just that it’s far too superficial to help move the web to this higher plane.

However, I also still believe in ‘thematic consistency’, by which the W3C means that the same URL should get you to the same content. BUT that is not the same as saying that the same users actually want to use the same content or that web providers want to give it to them.

In practical terms, this might mean promoting or demoting certain types of content that the designer thinks are more or less useful for users known to be in the mobile context. (I’ve talked about promoting ‘contact us’ from the conventional end-of-secondary-menu to front-and-foremost on mobile sites, for example.)

But why not create entirely separate services? I certainly don’t find it condescending when a user-interface designer has thought about what I actually want to do in a given context. More likely I’ll be thrilled.

And by the way, with this point of view, separate URLs or domains are entirely consistent: "we don’t mind which device you actually use, but you should be aware that the content on our mobile URL is better suited to humans on the move".

Finally I should add that this is really nothing more controversial than using country-code top level domains. The reason there is an amazon.co.uk is because user in the ‘UK context’ want (or need to be given) different content and functionality. No-one ever complains about detecting IP ranges to encourage users from different countries to go to the best service for their likely location.

One web, and I second that! There was always a tendency among web designers to jump on the hype band wagon in order to provide a ‘the’ user experience to a very narrow audience. Think of the early days of Flash, the browser wars… We all know the story.
But nowadays no serious web designer should have an excuse: standards are there to follow. Nevertheless I experience the same "let’s negelct that One Web for a second or two" atitude even amongst big designers: typekit driven websites will not degrade on all webkit devices as graceful as it should (webOS, Android), some content is only made available for users owning an Apple branded device… Is this pure ignorance or just the bliss of not knowing it better?

I don’t recall specifically talking about ‘optimising only for certain users’ in that presentation, as those principles are relevant on all platforms - including the desktop web. That said, there was a definite focus on iOS users, but that was actually due to laziness on my part as it was easier to get samples/screenshots. ;)

Can you let me know what you felt communicated ‘optimising for only certain users’ as I’d really like to avoid similar confusion in the future.

The thing that frustrates me is the content that is put on the web is, in its raw form, pretty accessible. It’s the design of the website - the effort to present that content in a "better" form - that creates problems.

Formerly I was against responsive design as well because I thought about it’s impact in a different way. Many of the points in James Pearce’s article rang true for me, but I think some of the specific design faults mentioned are true of all sites and not due to responsiveness.

My personal Internet use is rarely away from a 24" display, which (Mac predicated) means I’m likely not browsing at full screen. I think there is contrast between mobile/netbook and desktop devices because two dichotomy exist within the Web’s infinite canvas.

2) Desktop. Browser viewport is variable, but probably does not change very often. The larger a screen is the less likely a browser is using 100% of it.

In this worldview, the desktop is a much greater challenge because tabbed browsing is an unsung constraint. I’ve always tended to dislike liquid layouts because one liquid tab determines the width of all tabs. My browser is usually sized for optimal reading in Gmail or Basecamp, which can place fixed or responsive designs in awkward proportion.

When content determines viewport size more so than display capacity that’s a new design problem. My negative disposition toward responsive design comes from a feeling that designers are shuffling this responsibility to the user. When my browser is 1400px wide for Gmail’s sake, I don’t necessarily want all other tabs to "use the whitespace" with responsiveness. A fixed width design would sit comfortably with margins.

This is less criticism of responsive techniques than a complaint against the implementation of scaling in reaction to large viewports. Desktop browsers have scaling baked in, while mobile browsers implement pinch/zoom mechanics. A wide browser does not warrant increasing text sizes under the assumption that my reading distance is greater. It may not be.

I am generally impressed with responsive design for small screens however, and tend to agree with Jeremy Keith’s points about mobile-specific sites being imperfect solutions. Designing with mobile in mind will probably aid in decrufting content that would normally make it into websites. I think Jeremy’s persistence and the signaling work Ethan Marcotte did for ALA are still the infancy of responsive design techniques. I’m excited for more.

You may be interested that in the BBC the mobile team (who were responsible for the entire "mobile version" of the BBC site under bbc.co.uk/mobile) has recently been disbanded and responsibility for the "mobile versions" of products has shifted to the team also producing the "desktop" version. This is an interesting and I hope a good move as it gives teams the power and flexibility to cater for mobile devices without completely separating those devices from the original content.

I’m hoping to see some excellent mobile sites coming out of the Beeb in the not too distant future, although our insistence on supporting IE6 and up to the extent that the layout should be approximately the same as in all other browsers could be a bit of a thorn in the paw.

Excellent post. By building for mobile/tablet first and using responsive design, feature detection, progressive enhancement, lazy loading content, and ARIA, we already have all the tools we need to deliver on promise of universal access without resorting to slicing up the web by user agent and dumbing down sites for mobile devices. Sure, it requires some new skills and thinking but I think we’ll start seeing a lot of mainstream sites embracing these techniques because they work right now and ensure that everyone will have a great experience.

"But then, if that cruft is unnecessary, why serve it up on the “desktop” version?"

This is exactly how I feel about this debate. Why serve up a bloated version of a website? All sites should be streamlined so that they will load quickly on all hardware, not only the bleeding edge that many technophiles are used to.

I remember reading about a designer who felt they would love to design first for mobile devices and then extend the design to the desktop. Easy way to force yourself to cut the bull.

I think that CSS is the key. Why cant we offer the same content (HTML) but lay it out differently by serving up a different CSS file.

seutje

I totally agree with you on the point that it’s a way better idea to tailor for conditions rather than predefined devices/browsers/platforms, but the problem with "responsive webdesign" (hate that buzzword btw) is that there doesn’t seem to be a way to set conditions for things like download speed.

for instance: every1 seems to assume that mobile devices have a crappy connection by definition, but I’d say there’s a world of difference between say, a mobile device on EDGE or one on 3G, or even one on speedy wifies. Or the other side of it: a 17" laptop on a 3G stick (or tethering over a phone) vs one on a cable modem. Regardless of viewport size, you might want to present the user on 3G with a link to an image, allowing them to decide if they want to load it up, and present the user on a cable modem with the image straight up. This is just a quick example off the top of my head, but I’m sure others can think of more examples…

Also, I’ve noticed that most ppl struggle with doing "responsive webdesign" right, making everything relative and not imposing any limits isn’t always a good idea, as Andy Clarke recently illustrated by accident (http://bit.ly/ejfJP6). Most "responsive" websites I’ve seen actually end up disabling the ability to zoom out on some devices, by accident, because when the content fits in the window, the client automagically disabled it. It sort of makes me sad to see you don’t impose any minimum on your website, which might cause things like your logo to be cut off and only partially visible (http://bit.ly/gudlCZ granted, this might not seem like a realistic resolution to you today, but imagine web-enabled wrist-watches or something…). Others even go as far as to disable zooming entirely by using the (much dreaded) . Why anyone in their right might would even consider doing that (and why you are able to do that) is entirely beyond me and I’m glad to see you’re not doing this.

It seems that it’s easy to do this "responsive webdesign" thing in a horrible way, making the experience for the user even worse than with a regular, fixed-width 960 site, and it’s hard to do it right.
If I were to give any advice from a user-perspective, it would be to make as little assumptions as possible (e.g. don’t assume that low resolution === low bandwidth or vice versa), but also don’t make things too relative and please do impose minimums and maximums. Test like a crazy mofo, even for conditions that don’t necessarily translate to a certain device/browser/platform today but also test for conditions that might one day exist. I can already hear you thinking "oh, but we’ll just update it then", but seriously, we all know that’s not going to happen. There’s still sites lingering out there that pretty much only work properly on netscape 4 @ 640x480 or some shit…

Hope my writing style didn’t make you throw up all over your , I am not a native english speaker.

I actually prefer to use "desktop" layouts on my mobile device. They’re 2-dimensional. I can zoom out and easily navigate to any part of the page.

"Mobile-friendly" layouts take that away. They break zooming, forcing me to slowly scroll through a completely linear page.

Given that all mobile browsers support zooming now — not only iPhone, but also all versions of Opera from Mini to fully-featured Android version — creating dumbed-down "mobile" layouts is counter-productive.

I have to fake my User-Agent string on iPhone as desktop browser to get fully-featured pages. And I fake my User-Agent on desktop as iPhone to get HTML5 video. Madness!

Great article. Perhaps it helps clear the blurred line between applications and content sites to think about it this way: anything you want people to find on a search engine or share with others should be a URL that is viewable on all devices.