Skip to main content

New to Mobile? Welcome to the One Web Debate.

By Jason Grigsby

Published on August 11th, 2010

Topics

In the midst of the conversation last week about CSS media query for mobile, Brian Fling said, “this is very similar to the ‘one web’ debate which has been raging in mobile for over five years.”

Exactly. In fact, it’s the same debate with new participants.

Four years ago, Barbara Ballard described the debate like this:

“There are two main camps in the mobile web:

  1. One Web. The Internet is the Internet, and sites should run well on all devices. Optimization should be based on CSS and device detection, but should not change site function or content beyond the necessary.
  2. Mobile Web. The mobile is a different platform with different capabilities and different user needs. Sites should be optimized for mobile in many (but not all) cases.”

One of the things that struck me about last week’s discussion of CSS media queries was that there was an assumption on the part of many that delivering a single html document no matter the device was a desirable goal.

Whether people realize it or not, they’ve subscribed to the One Web viewpoint.

By contrast, many of the people who I consider leaders in mobile thought—Brian Fling, Jeff Croft, Barbara Ballard, Cameron Moll, etc.—were quick to point out that delivering different HTML makes sense most of the time for a variety of reasons ranging from performance to user context.

In a bit of fortunate timing, between last night when I finished the draft of this post and this morning, Daniel Davis from Opera wrote about his perspective on CSS media query and One Web.

Daniel points out that Opera has “championed media queries for several years now” and points to a dedicated page detailing Opera’s full support of One Web.

Daniel outlines several positives of the One Web approach including “the obvious benefit of having only one codebase, albeit possibly more complex, to update and maintain,” and points out some potential pitfalls of content adaptation including the “there’s always likely to be an off–the–wall or cutting–edge device that falls between the cracks” of device detection databases like WURFL.

Daniel’s article is well-articulated and worth a read.

I don’t disagree with the points he makes about appeal of delivering a single HTML document, but I have yet to see anyone do it on anything other than small sites and personal blogs. And even then, the ones I’ve seen suffer from the performance items I mentioned last week.

Opera has been promoting CSS media query for mobile for several years and has a stated position on One Web, yet it doesn’t use these techniques for it’s own site.

Daniel writes that if his team “had more control over the company-wide CMS.” I wish that they did as well so we could see how they would build it.

So here we are several years after the One Web debate started and it’s easy to find sites that are based on the content adaptation and provide different html and assets based on the device class.

But outside of personal blogs and demo sites, it is difficult to find examples of pages based on delivering the same HTML to every device and using Javascript and CSS to progressively enhance the content.

Anyone who has worked on a site that supports multiple languages knows that we don’t have One Web on the desktop web. We don’t have any problem delivering different html documents and assets to someone who speaks a different language.

I have yet to see a single article arguing that we should deliver a baseline English version of web page and then use javascript to progressively enhance the page with Spanish or Chinese.

Why is it ok for us to deliver different HTML documents because the user uses a different language, but it isn’t ok for us to deliver different HTML documents because the user is using a different device?

The W3C’s Mobile Best Practices Working Group tackled the issue of One Web long ago. They came to a conclusion that matches up well to my view of the mobile web.

The W3C’s Mobile Best Practices Working Group defines the One Web Principle as:

One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation.

They go on further to define “Thematic Consistency of Resource Identified by a URI“:

Content should be accessible on a range of devices irrespective of differences in presentation capabilities and access mechanism…

A bookmark captured on one device should be usable on another, different type of device even if it does not yield exactly the same experience. If the page that was bookmarked is not appropriate for the device that is now using it, an alternative that is suitable should be provided.

To summarize:

  • Mobile devices should receive content that is thematically consistent with the content that someone would see at a given URI in a desktop browser.
  • The content, functionality, and appearance of the information delivered to mobile devices may vary significantly from that which is delivered to the desktop web.

This is a definition of One Web that I can get behind.

As more web developers start thinking about and developing for mobile, we can expect to see this debate about the One Web reemerge again and again.

You may not agree with the conclusions I’ve come to about the One Web. That’s fine.

But at minimum, make sure that you’re not simply adopting the idea of a single HTML document as being inherently better without questioning where that assumption comes from.

Is a single HTML document the best solution for your users? Or is it simply the best solution for you?

To me, One Web is about universal access to information, not delivering the exact same code, assets or even content.

In my vision, I can send a url to someone and know that no matter where they are in the world, no matter what device they are using, that they will be able see that information in a way that is optimized for them.

Comments

igor.faletski said:

Great summary, Jason!

I think there are several problems here, with various optimal solutions. Reading a blog? Shouldn’t have to zoom and pinch to find the right paragraph, or go to a different URL to get the content. Trying to interact with a web service? Optimizing the presentation layer alone is likely not sufficient – might need to build a new app/webapp just for mobile.

The beauty of the Web is in its ever evolving diversity built on a common foundation that is HTML/CSS/JS. In the coming years web on mobile will only get better, but probably without a clear winner in terms of technology.

Igor / Mobify

Patrick H. Lauke said:

In fairness, I find the argument of “different pages based on language, so why not different pages sent to devices” a bit weak. The simple counterpoint is: we have to serve different language pages to users because they don’t understand a “baseline” language. However, browsers do – web standards…the esperanto of the web. By all means, there are situations where a separate mobile site is advisable…for instance, very complex sites, so on your small-screen device version you may want to completely refactor your navigation for it…a good example of where this has been done very successfully is m.flickr for instance – all the functionality is there, just differently organised to better use smaller form factor (and notice that I don’t talk about the mobile context as such, as browsing a site on a “mobile” device doesn’t actually mean that the user is, to quote the classic example, at a bus stop or rushing to a meeting…I for instance use my phone when watching TV on the couch, so quite “stationary”…just happen to be using a small form factor device).
But for each massive site that benefits from a separate version there are probably the same amount of simple sites that, with a few simple layout adaptations, work just as well on small and large form factors. And for these, things like CSS Media Queries are the tools that can be used. No one solutions is perfect, but for the majority of cases an adaptable (or “responsive”, if we go by the ALA coined term) layout can make all the difference without having to drag out a completely separate version (in a similar way that CSS Media Types have mostly replaced the need for separate “printer friendly” versions of pages).
The truth, as ever, lies somewhere in the middle – and each site will have its own additional sets of requirements that may swing the implemented solution one way (separate site) or the other (one site, adaptable layout).

Jason Grigsby (Article Author ) said:

@Patrick I concur with most of what you’re saying. The example of languages was given to prove that there is nothing inherently better in delivering a single HTML document versus different HTML documents.

It seems like many adopt the goal of a single HTML document as it were “purer” or something. If it were a goal we should seek above all else, we’d be seeking ways to deliver a single HTML document for different languages.

It makes sense in my head, but I’ll readily admit it didn’t translate as well to prose.

“The truth, as ever, lies somewhere in the middle – and each site will have its own additional sets of requirements that may swing the implemented solution one way (separate site) or the other (one site, adaptable layout).”

Yes. Indeed.

David Storey said:

Opera has been promoting CSS media query for mobile for several years and has a stated position on One Web, yet it doesn’t use these techniques for it’s own site.

No true. Opera has been using media types on its properties for a long time. Opera.com was one of the first sites (even before ESPN) which lanched with multiple media types like print and handheld. It even had a TV media type (and still does. And there lies the problem of maintainablity if you want to make a mobile version, a smart phone version, and a tablet version and a TV version, and a Apple iCoffee Machine version…). If you look at the opera.com source code you’ll see the handheld stylesheet.

We’ve also used Media Queries extensively on opera.com in the past. One reason why you haven’t seen too many big sites use Media Queries until relativity recently is that Opera was the only browser that really supported it properly, and desktop browsers had issues with it (you could completly break IE and Safari 2 so they had no styling back in the day when I was first playing around with it). The browser limitations have more or less gone now on both mobile (with Opera and WebKit-based browsers) and desktop. Media Queries are also very useful for desktop browers of course to make much more fluid designs.

Jason Grigsby (Article Author ) said:

@david My comments on Opera were specific to the using media queries screen width and progressive enhancement techniques. I was basing my comments on this exchange with Daniel over twitter:

@ourmaninjapan is there an example of progressively enhanced mobile to desktop page on Opera’s site? One that is in use, not a demo page?”
http://twitter.com/grigs/status/20890289683

@grigs No non-demos yet, unfortunately.
http://twitter.com/ourmaninjapan/status/20891850036

@grigs I’m aware that makes me sound hypocritical, BTW. If our team had more control over the company-wide CMS…
http://twitter.com/ourmaninjapan/status/20892053353

But it is confusing because of CSS Media Query (e.g., for screen, mobile) versus the CSS3 abilities to target different screen sizes.

When I listed the problems with CSS Media Query based on screen sizes, the response was someone could deliver a mobile first version of HTML then progressively enhance with JS and CSS.

Yes, someone could. I’d love to see it when they do. But so far, I’m not seeing it.

David Storey said:

But it is confusing because of CSS Media Query (e.g., for screen, mobile) versus the CSS3 abilities to target different screen sizes.

I think you mean between media types (screen, print, handheld, tv, etc) and Media Queries? Yes we seem to not be using the later right now on opera.com (I’ve not digged in too deep as it is friday night, so I could be wrong), but Daniel is not quite correct in that we have used Media Queries (and viewport meta element later on) for a number of years on opera.com. They may have been removed in the recent redesign. They worked pretty well, but we do have a number of very good developers who know what they’re doing. We did have to introduce some browser sniffing with the approach to avoid giving IE and Safari 2 no styles at all (they would see the media query in the link element and not load the stylesheet at all). That isn’t really needed now as IE can have conditional comments and Safari 2 is dead these days.

David Storey said:

This is an example of the kind of approach I think we used to take in around 2007 on opera.com. Opera.com was obviously more complex and had other kind of rules and different values for the queries etc.

http://files.myopera.com/dstorey/experiments/mediaqueryexample3.html

Here you can load styles to different widths without having to override styles for mobile, and thus give no more CSS data to mobile than is needed (although the benefit to Opera isn’t as great as we don’t load backgound-images an such that are not displayed).

Aeron said:

Does the “Mobile Web” camp also include Mobile Apps? I ask this with native apps already accounting for half of mobile internet traffic:

http://www.readwriteweb.com/archives/native_apps_account_for_half_of_mobile_internet_traffic.php

And some groups already sounding the death knell of the web:

http://www.wired.com/magazine/2010/08/ff_webrip/all/1

Or are apps something else altogether?