One Web, Two Web Primer

There are two different approaches one can take when developing a mobile web site. The first approach has been assigned the delightfully inclusive moniker ‘One Web‘. One Web involves creating a single web site accessible from both mobile and desktop web browsers and the site’s presentation is custom tailored at run time to the capabilities of the user’s device.

The second approach involves creating two completely separate web sites, one for mobile and one for the desktop. The advantage with this approach is that content and the user interface can be tailored specifically for mobile, as the user’s context while using each site is likely to be drastically different. An obvious nickname for this approach might be ‘Two Web’.

Two Web involves a white list of mobile User Agents that server side code uses to detect mobile devices and redirects them to a mobile specific site. The remaining User Agents are left to view the desktop version. An improvement to this approach allows end users to opt-out of the mobile version by simply clicking on a link that redirects to the desktop version and persists the setting (often using a cookie).

With One Web the site is customized and adapted based primarily on screen dimension, orientation, and pixel density. Contrast that to Two Web, which usually divides touch screen and non touch screen devices. While this may make it easier on developers, it’s awkward for users. For example, consider Google Plus on an iPad. The entire experience feels like it was intended for a small screen, and feels barren and feature-poor on the larger tablet screen. The full Google Plus web site would be better for the iPad.

Other downsides to Two Web include maintenance of two separate code bases, maintenance of the User Agent white list as new devices are released, and dependency on server side code to redirect mobile User Agents to the mobile site.

Developers should also be aware of the historical precedence of browser vendors borrowing User Agent strings from other devices as they become popular. That’s why almost all User Agents in existence today contain the string “Mozilla” and why WebKit User Agents contain “like Gecko.” Come to think of it, User Agent theft happens most often when the target is Netscape or Netscape progeny.

Make Your Choice

An informed reader might already be aware of the choice between One and Two Web. What you might not be aware of is that your mobile JavaScript libraries and toolkits may have already made this choice for you. The mobile web development space is clouded with tools that don’t document their requirement of Two Web.

Most of the tools that have been reviewed below have focused on WebKit support only. It is not the author’s desire to simply suggest that these tools should work on non-WebKit mobile browsers. The tools we use should not create a web divided between mobile and desktop. In a theoretical world where WebKit has a global monopoly on both mobile and desktop web browsing, it would still create problems if sites are restricted to mobile only or desktop only. Developers must be aware of the compromises we’ve inherited from our tools.

As of June 2011, mobile web browsing is only 6.5% of all web browsing, while 24.5% of all web browsing is desktop WebKit (non-mobile browsers like Chrome or Safari). While evidence would suggest that the share of mobile web browsing will increase, we should be very cautious to assume that WebKit (mobile or desktop) will ever reach anything close to 100% market share.

Let’s look at how a few sample pages render in a few desktop browsers. (Keep in mind that I did not test in the other major rendering engine, Presto currently used by Opera 11.5)

Sencha Touch 1.1.0

Trident (IE9) Not Supported	Gecko (Firefox 5) Not Supported

Instead of a nice list with large click targets, we’re greeted with a simple white screen. No error messages detailing a JavaScript error occurred on the page. No warning saying the web browser being used here isn’t supported (the bane of Progressive Enhancement advocates). Really bad user experience here.

Officially, Sencha Touch support is not “anything WebKit” as some have suggested. It officially supports Apple iOS 3+, Android 2.1+, and BlackBerry 6+ devices. It does not include WebOS, which is a WebKit browser, nor does it include any desktop web browsers.

DHTMLx Touch v.1.0 RC

Trident (IE9) Not Supported	Gecko (Firefox 5) Not Supported

DHTMLx Touch operated much better than Sencha Touch on desktop browsers. Despite the fact that many of the demos on their website are hidden behind QR codes. You can use a QR decoder to get the URLs for viewing on your desktop device. As for official web browser support, the DHTMLx Touch web site states:

While browsing the demos of DHTMLX Touch, note that the framework requires a mobile device to display and work correctly. You can also run the demos on standard PCs in Firefox 3.6 and above, and WebKit browsers (Safari, Chrome, etc.), but there still can be some issues since DHTMLX Touch is optimized for mobile devices.

Unfortunately, even though it works for the most part, desktop web browsers are still unsupported. It should also be noted that DHTMLx isn’t full WebKit either, as Blackberry 6 is not yet officially supported.

Dojo Mobile 0.2

Trident (IE9) Supported	Gecko (Firefox 5) Supported

Dojo Mobile also did fairly well. There were a few minor rendering issues with WebKit prefixed gradients (and no background color fallback) which I would consider to be very minor bugs. Here’s the good news from the Dojo documentation:

Dojox.mobile supports not only webkit-based mobile browsers, but also non-CSS3 desktop browsers such as IE and (older) Firefox.

jQuery Mobile 1.0b2

Trident (IE9) Supported	Gecko (Firefox 5) Supported

In most of the other frameworks, cross browser compatibility documentation felt like an afterthought mentioned in passing. Not jQuery Mobile. It has the most complete web browser support documentation of any mobile component framework. Not only is their documentation the best, their device support is the most comprehensive. The project officially supports Internet Explorer all the way back to version 7, which speaks volumes to their commitment to allow the developer to make the choice between One Web and Two Web.

Conclusion

If you’re developing Hybrid Native applications using software like PhoneGap, desktop web browser support doesn’t matter here. Feel free to disregard this entire article.

However, if you are developing for the web I would encourage you to look strongly at One Web as the default choice, and use Two Web as the exception when your content and context require drastically different non-adaptable versions of the site for mobile devices. Certainly I’m not suggesting that either One or Two Web are silver bullets. But we should all be aware of how the tools we choose weigh on our decision, and how this decision will affect our users in the future.

A few weeks ago at the jQuery Conference (San Francisco 2011), Nicholas Zakas delivered a wildly entertaining presentation entitled “Progressive Enhancement 2.0″ (slides 65-79 are especially great), updating the basic rules of PE for a modern age. While prior Progressive Enhancement techniques included layering content, presentation, and behavior (conveniently represented as HTML, CSS, and JavaScript). PE 2.0 (not to be confused with our other 2nd generation friend, the Web) involves multiple layers of CSS for differing device capabilities (rounded corners for example) and multiple layers of JavaScript (ECMAScript 5 capable browsers, for example). He made the argument that this also included ignoring older browsers (in some cases) and only moving forward with new functionality for newer, more capable devices.

Like any web developer that believes in getting actual work done, I agree with his argument but not without exemption.

Pieces of Flair

The benefit of Progressive Enhancement pays off when your code encounters a device is incapable of interpreting the CSS or JavaScript correctly in a way the code was intended. This could be because of a bug in the rendering or JavaScript engine (or God-forbid an error in the code itself), or it could be because the feature being utilized is newer than the device itself and it could not have supported it without clairvoyance or a time machine.

The example Nicholas used to display this case was the Twitter home page, which uses CSS border-radius to display rounded corners. In user agents that don’t support border-radius, such as IE <9, the elements have sharp rectangular corners. Using Progressive Enhancement here is a no-brainer, especially for features (like rounded corners) that have no bearing on the actual meat of the page, the content.

But when the feature is the content and degradation requires additional work, the decision is more complex. HTML5 <video> and <audio> probably aren’t an acceptible baseline for progressive enhancement yet (based on current web browser statistics), and (video/audio) may never be an acceptable baseline depending on your views on universal accessible content. The best baseline might be a text-only transcript of the media. It really depends on how much importance the video/audio is to the core functionality of the page.

Input

Historically speaking, in order of mainstream application the progression of input devices used to interact with (even back before web) applications was: keyboard, mouse, touch, and (even more recently) speech (see the speech attribute on text inputs in Google Chrome). Logical progression concludes that we’ll see gesture APIs (think Microsoft Kinect) available at some point as well. It’s very important to consider that the the mechanism of input must also be carefully layered. Start with a good baseline of keyboard support for your application, then add mouse interactions, then layer any specific (multi-)touch interactions on top of that, and so on. You don’t want to skip any intermediate input layers.

In Nicholas’ presentation, he presented an example of the Yahoo! homepage, specifically modified for tablet devices (slide 115). He went on to describe that the carousel functionality on the main image on the page was not available when viewing the page in Firefox. I think this is a good example of what happens when you skip layers of input interactions, moving straight to touch, without first layering mouse-based input. The approach the Yahoo! team took might be okay if you can afford to develop multiple independent code bases for a single home page, but most teams are going to want to get as much out of a single code-base as they can.

Cutting Fat

A side benefit of targeting Progressive Enhancement to your core functionality allows you to easily add ancillary features that don’t need to span the entirety of your browser support spectrum. Some might argue that the Carousel functionality in the Yahoo! tablet example could be considered ancillary, but the positioning and screen real estate dedicated to it suggests otherwise. Facebook’s chat in IE6 is a good example of this (slide 114). Is chat part of the core functionality that Facebook wants to guarantee device independent access to? Apparently not. Making decisions in this realm involves a real cost benefit analysis, weighing the feature against user benefit, browser market share, and development/implementation time.

Exceptions

It’s important to note that not all things can be developed using Progressive Enhancement. There are certain use cases in which viewing the content in a lower fidelity than the author originally intended would destroy the value of content altogether. While these use cases are rare for most sites, most artistic endeavors can be classified as such. Consider The Wilderness Downtown, an amazing and beautiful interactive film built by Chris Milk using HTML5. The strong, vivid emotional connection between the film and the viewer would have been destroyed had the content been a text-based transcript, or just audio, or even just a video. Art must not be compromised.

Now, some of you probably read the above paragraph and are thinking to yourself that your blog also qualifies under the above exemption (you’re the guy that doesn’t have full text feeds on his RSS aren’t you?). Just be real with yourself, most things probably don’t fit into the same level of interactivity as The Wilderness Downtown. Don’t use art as an excuse.

Conclusion

Start with the primary goal of each individual page, this must be universally accessible. If the goal is to display text content, the text must be available sans-JavaScript. If the goal is to show a video or play audio, consider a transcript as your baseline. If the goal is to solicit form input from the end user, don’t skip input interaction layers. But don’t be afraid to shirk best practices on things that aren’t necessary to that goal, like social media links, a real-time chat client, trends/statistics, etc. You’ll know what matters.

Update: Changed the title of the article.
Update: Rather than My Yahoo!, Nicholas informed me that it was just the Yahoo! homepage.

Big Enterprise is traditionally known for creating development environments that foster a “get it done” mentality, often rewarding results over correctness (mileage, of course, may vary).

My company uses IE6, and the application works in IE6, so it’s done!

This little quagmire is amplified by the fact that when using Open Web technology, there are many ways to get things done, and most of them are incorrect. But those mistakes don’t manifest themselves until the project is in the hands of the end user, whom we often punish for our oversight.

But there is hope. Using the power of web standards and Open Web best practices, we can achieve something panoramically, not microscopically, beautiful.

The secret sauce of building for the Web isn’t its distribution model, in which updates are managed on the web server without the need to update software on the client (although the Anti-IE6 vigilantes would tell you differently). It most certainly isn’t development efficiency, as most people new to the game will so readily inform you of. Cross browser quirks due to non-standard browser implementations of CSS and JavaScript, or vague standards specifications have seen to that.

When I was writing Visual Basic, I got my job done so much quicker and easier!

The power of the Open Web is Device Independence.

Visitors to our sites shouldn’t be met with warnings about what device they’ve chosen to use.

This site viewable only in IE7+, Firefox, Chrome, or Safari, and at minimum 1024×768 resolution.

This site requires Flash or Silverlight

I realize that this is a controversial stance, especially given that most sites are dropping support for IE6, and more are relying on Flash and Silverlight plugins. Architect applications to your client device usage statistics, and don’t let your tools shape the statistics for you. Using techniques like progressive enhancement, we can ensure that our sites degrade gracefully to the capabilities of the client device. At it’s truest form, this is basic accessibility. But, Device Independence might be a more accurate term, since accessibility is unfortunately an overloaded term scoped solely with devices tied to disabilities (screen readers, for example). While screen readers are a very important piece, there is a bigger picture.

When the iPhone came out, there was an uproar because it didn’t support Flash, for battery life and other reasons. But the uproar was from developers who had designed applications specifically for Flash! Would you say that those Flash applications were designed with device independence in mind? YouTube got around this by encoding their videos in MP4 format, which arguably has a higher device independence rating than the Flash format.

Keep in mind that we’re not attempting to handle every permutation of end user browser settings, since most don’t change the defaults. Instead we are trying to scoop up the largest base of supported devices with the least amount of effort! Who cares if an end user disabled JavaScript in their preferences? I’m more worried about the mobile browser that doesn’t even support JavaScript at all. But when you use Open Web properly, you get support for both!

Output Device Independence

• Full Web Browsers: Does your site work in Opera? Don’t worry about pixel perfection, that’s something completely different — does it work?
• Web Browsers on Mobiles
• Search Engine Spiders and other Screen Scrapers
• Screen Readers
• Printers: Ever had to make an entirely separate page for print-friendly version of your application? Flash/Silverlight do not print well
• Televisions: Xbox 360, Wii, and Other Media Center Devices
• Projectors
• and more…

Take a look at the CSS specification for media types. The standards are there! Support for CSS media types isn’t fool proof by any means, but the end goal is clearly visible.

Input Device Independence

But I’m not just talking about output device independence either. User interfaces should be adaptable to different input devices as well.

• Mouse
• Keyboard (often overlooked in web applications)
• Touch Screens (Single and Multi-touch)
• Voice, Motion Capture, and Facial Recognition (the standards and technology aren’t quite there yet, but progress is being made)
• and more…

The world is developing the Open Web, and it isn’t limited by a single company’s goals and timelines. At times, Open Web may seem like it’s a very slow moving glacier headed our way, but what else can you do but laugh when companies try to power their Titanic right through it?

Article originally inspired by Yahoo’s Graded Browser Support.

So, some sites have gone two ways, allowing OpenID, but also a proprietary registration system. This too, is problematic. It would seem that given a choice, the John Doe the Plumber style user will choose a proprietary account over the confusing user experience presented to them through OpenID.

But the annoyance doesn’t just lie with account registration for web applications. Typing your personal information on every blog you comment at is also repetitive and unnecessary. Some sites even require account registration for something so minor and transient as a blog comment.

Unfortunately, for the time being, it looks like registration forms are here to stay. So, what can we do to make those registration forms more usable, more efficient, and ultimately downright friendly? I know that you’re ahead of me on this one: Let’s auto-complete information for the user.

Please keep in mind that this power can be used for both good and evil. Essentially what we’re discussing here is data mining available information from various social networking sites on the internet, trying to glean personal information about an end user that has volunteered a piece of their data already. What can we get from what we already have?

Once a user has typed in their e-mail address, we can:

• Retrieve Twitter profile information (example shown on Chris Heilmann’s blog):
  • Full Name
  • Short Personal Description
  • Location
  • Web site URL
  • Time Zone
  • Favorite Colors (used on their profile)
• Retrieve an avatar if they’ve registered for the Gravatar web service (See my earlier post discussing this).
• Get their upcoming calendar events from a public Google Calendar. (Perhaps not as useful for autocompleting forms, but interesting)
• Find their UID on Flickr, which gives you a source for:
  • Full Name
  • Location
  • Flickr Avatar

If you know any of their social networking usernames, you can:

• find their MyBlogLog profile, if they’ve linked the service to their account (Sample query, I added my twitter). Now we have:
  • MyBlogLog Screen Name and ID, from which you get their MyBlogLog profile:
    • Nickname
    • Picture
    • Age
    • Sex
    • Location
    • A list of tags they use to describe themselves.
  • MyBlogLog Avatar

Those are only some of the proof of concept API’s that I’ve listed here. The interesting piece of this, is that once you have a small piece of information, it opens up the door to other searches.

One can only imagine how many leaves are in this tree. For example:

• Facebook’s Users.getInfo (in JavaScript)
• Yahoo’s Social Tools, get an end user’s GUID and go to town on their profile.
• Google Contacts, I didn’t even start to look through their API’s.

Before you start jumping the privacy fence to a self induced heart attack, remember that all this information has been volunteered by each individual participating in each of these services. Remember, with great power comes great responsibility.

What do you think? Scary or useful?

Own your Identity had a great post today detailing a great feature on the signup form of the Get Satisfaction site.

They rely on the fact that sites like Twitter and Flickr publish an hCard microformat for all of their users publicly on their website. If you go to my twitter page and view the source, you’ll find the following code available to anyone (without authentication):

<address>
   <ul class="about vcard entry-author">
      <li><span class="label">Name</span> <span class="fn">Zach Leatherman</span></li>
      <li><span class="label">Location</span> <span class="adr">Omaha, NE USA</span></li>
      <li><span class="label">Web</span> <a href="http://www.zachleat.com/" class="url" rel="me">http://www.zachle...</a></li>
      <li id="bio"><span class="label">Bio</span> <span class="bio">UI Programmer, JavaScript Enthusiast, Soccer Hooligan</span></li>
   </ul>
</address>

The premise here is that hCard tells you how to parse this markup to get usable information. The adr CSS class tells you what my address is. The fn CSS class tells you what my name is, and so on. So, Get Satisfaction goes and spiders this page behind the scenes and autopopulates your profile with what it can find. Pretty sweet.

Now, they don’t limit you to the services they provide, which are: Flickr, Technorati, Twitter, Upcoming, and last.fm. They provide an Other category for any hCard enabled URL (your personal homepage or perhaps an hResume you have posted on the web).

Integrate with OpenID

However, why not take it to the next level? Why not integrate this microformat functionality WITH an openid login system? You’d be able to kill two birds (not a twitter joke) with one stone in some cases, since both Twitter and Technorati are also OpenID producers (re-echo: We need more consumers).

So, not only do you get the benefits of having OpenID authentication on your website, but you’d be able to prepopulate a certain amount of profile data with an hCard parser. And the best part is, if you already have a nice clean user interface set up to handle different OpenID producers, there wouldn’t be any additional clutter on the interface to get this benefit. It’d be transparent to the user when it works, and fall back to a normal empty profile form when it doesn’t.

What I’d like to see, is more sites that are OpenID producers, also serve hCard microformats as well. If we can get all the major producers on board, we’d have a nice tidy little system going.

• Automatic Print Styling: Is the page going to be able to be printed properly without a “Printer friendly” link? CSS style sheets can be used to modify the output of the page using the @media print declaration. Are the widget components you’re using in your JavaScript library able to support easy printing?
• Browser History Management: Will your application support the back button, especially with the increased usage of AJAX interactions on a full page application. Don’t use XMLHTTPRequest’s to fetch the entire content of a page. Just redirect them to a new page when you are only saving the header and the footer.
• Graded Browser Support: support of the web browsers with a large percentage of market share using the ideas put forth by Nate Koechley in his Graded Browser Support descriptions.
• Bookmark and Permanent Linking: is the behavior of your JavaScript application changing how data is being displayed? You’d better modify the URL to allow the user to bookmark link straight to the same view.
• File Compression: Minimize your CSS and JavaScript for delivery. GZip your CSS and JavaScript for browsers that support it (most all modern browsers do).
• Efficient Caching Mechanisms: server side caching of data is necessary for high volume traffic.
• Internationalization (i18n): will your application be viewed in other countries by non-English speakers? Are your dates in an international format? How about 24 hour time formats? Time zones? Do they observe Daylight Saving Time?
• Error Logging: Both server side and client side (using AJAX to log JavaScript errors can be very helpful)

Recommended Luxury Items

• Support mobile devices: How will your application look on a Blackberry? How does it render in Opera Mini?
• Offline Mode: Add and modify data offline, with the ability to automatically synchronize changes when an internet connection becomes available.
• Exportable data: PDF, Excel, RSS, even offline static HTML. JavaScript can sometimes give unknown results when using the browser to save the page locally. Make sure this is supported. Don’t force your users to save screenshots.

Enterprise Client Side Widgets

• Data Grid: businesses just love data grids. Nothing like a nice standard set of cookie cutter constraints to force upon your data.
• Charts and Graphs: metrics are important. Existing client side JavaScript charting packages can be limited when it comes to printing, or even saving the chart as an image file. These are important.

There are many facets that a developer must consider when designing a new application. I hope this list will at least make you think about some things that you may not have considered before. Thanks for reading.