New to Mobile? Welcome to the One Web Debate.
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.
Blast from the Past: One Web Debate in 2006
Four years ago, Barbara Ballard described the debate like this:
“There are two main camps in the mobile web:
- 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.
- 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.
A Contrasting Viewpoint from Opera
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.
Translation: We Don’t Deliver Single HTML Documents Now
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.
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?
W3C’s Definition of the One Web Does Not Mean One HTML Document
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.
- 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.
One Web Means Access to Optimized Content
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.
Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.