I'll admit it: I drank the kool-aid. I am a new iPad owner, even though admittedly initialy being somewhat of a detractor of the device at launch. However, a minimal amount of time with the iPad yields two very important takeaways: 1- the potential in the device is huge (barring that pesky missing camera for skype-ing), limited mostly by software, which Apple can and will change at any time (iPhone OS 4.0 will be announced in just a few days), and 2- slates as a device category really will be a big deal very soon regardless of OS, and should be cased for in web development. Period. And it doesn't take much to do so. The web at large has moved away from full Flash websites for many reasons (including myself, and I am the developer behind a full bore AS3 framework). Times have changed, and what worked before just isn't appropriate anymore. Forget the Apple argument, just look at SEO and full Flash sites are instantly a problem. These days, Flash modules are king for rich content, a use case that generally doesn't get in the way of proper indexing of pages.

As of this writing, mobile specific variants of websites are really just starting to become an expectation of end users. It's becoming common practice, and that's a good thing. Understanding your end users context gets you that much closer to retaining them. Suddenly however, the manner in which those mobile versions are detected is a problem. Many sites still force mobile variants to users without an option to switch to the full site. I am mostly opposed to this logic, unless your site is completely unusable on said devices (Full Flash sites being a prime example). Otherwise, the user should always be presented with an option to opt out of a mobile variant, even if some of the site will break - its the users choice, and by presenting mobile first, you have effectively warned them and gated appropriately. If they choose to go through, so be it.

This problem is amplified now by the iPad. With 300,000 iPads sold at launch alone, there's no denying that it will be a segment worth targeting. RIM/Blackberry only account for roughly 8% of web traffic according to AdMob as of Febuary and typically their devices are still cased for in mobile development. iPad will likely surpass that number quickly. Currently, the iPad user agent string represents itself as a mobile device. Subsequently, many sites are presenting mobile variants by default, and in many cases are forcing that version without an option to switch to the regular site. This problem is amplified by the fact that these mobile variants were designed for 480x320 displays, not 1024x768. They render fine, but in some cases they look very off. Clearly this will need to be cased for. But how? Should tablets as a device type be given their own variant? I don't think so, but I'm sure some sites will soon go this route. But there is another option: progressive enhancement.

The concept is simple: only show your users what they are capable of consuming. Let's take Flash as a case study. First, lets assume the two variation web development model: mobile and desktop. I am all for serving desktop to tablets, lets leave the mobile variants for truly mobile devices - the one you are likely to pull  out in the grocery store and search for a product. That's not going to be a tablet device, it's going to be a smartphone. Additionally, note that many Android tablets won't support Flash in the near term, so the Flash problem isn't just an iPad issue. Moreover, even if Flash is supported, that doesn't mean that the design of the Flash content is well suited for touch either, so it may still be an issue to present that content to your user. It's likely that tablet users generally are going to be expecting the full web on their large screens. So how do we go about presenting the 'full web' site experience to a plugin limited end user?

For Flash content, detect if the player is present and the version is adequate for the content, and if it is, serve the Flash. If not, serve alternate content in the same location as where the Flash should be. If you're content is fed from XML (which it should be whenever possible), that same source can be used to feed an ajax replacement (video content could conceivably be rendered in HTML5 or using HTML4 and an alternate plugin to Flash such as Quicktime). Extra bonus: Googlebot is now executing limited javascript, so your initial load dynamic content may even be indexed for SEO. If that content matches the flash, there's the fix for Flash SEO indexing in module content. It's an elegant and simple solution to the problem. Architecting from step one with this methodology in mind will produce a cohesive, rich, SEO optimized experience across mobile, tablet and desktop variants.

Have any other suggestions? Leave a comment!

Note: This post has been getting a fair amount of traffic. I originally posted this directly after launch, and subsequently it contained outdated information from what is now known from the final release of OS 3.2. I originally had left the original post info for the sake of blogging/ journalistic integrity, however after three revisions because of newer info, I decided to strip the clutter of invalid content. Having said my disclaimer, below is the revised new post, and here is the release version of the iPad UA string as of 4/6/10, pulled directly from my 32GB wifi model:

Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) version/4.0.4 Mobile/7B367 Safari/531.21.10

more after the break.

The iPad represents itself in line with how the iPhone and iPod Touch differentiate themselves by specifying different device strings, but still contains the word 'mobile' - so Apple is currently explicitly classing this device as a mobile browser. But we now have a new class of devices to case for, segmented somewhere between mobile and non-mobile. While Apple has taken the first real swing at a tablet user agent, it's up in the air whether other tablet browsers will fall in line with this or do their own thing. Consistency is critical for proper detection without necessitating device specific casing.

This is intriguing and presents an interesting new issue for web developers. In their marketing materials, Apple has classified the iPad as designed for a full web experience (barring Flash of course), but they themselves are saying to the developers that this is a mobile device, right in the UA string. Moreover, technically the UA string classification is correct - this is a mobile browser. This isn't the desktop version of Safari. While they are both webkit based, it is inevitable that considerations will want to be made for the glorified Safari mobile browser in the iPad, and using the user agent string to identify that and case for it is problematic unless Apple modifies the UA string. My guess is at some point they will, possibly as soon as 4.0 hits.

It's not so much that this matters for development now as much as that it sets a precedent for future slate browsers. Apple has said here that slate browsers, even if they are larger versions of existing mobile browsers, should identify as a mobile browser, but clearly full sites should, and will be ultimately presented to iPad users in many cases. Even if the UA string wasn't an issue, there's still the question of how to architect a full site for both tablets and desktop viewing (primarily casing for browsers that do and don't have Flash). Proper implementation of progressive enhancement techniques is a great solution (see my related post on this topic here).

Maybe this whole UA string mess will all be a moot point when we see the 4.0 beta. As with all things Apple launch related, time will tell. One thing you can count on is that if the iPad succeeds, the precedent will be set. We'll see who follows.