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.

WordPress 2 - CMS management
Free, app store link

If you have a wordpress blog, whether hosted on your own domain or at wordpress directly, you simply need this app. The reality is that if you aren't jotting down ideas already on your mobile device, you should be. And if you aren't doing it in this app, you should be. Create posts and add media/tags/categories, approve comments, edit pages...and undoubtedly more planned for the future. You will be more productive and be more involved with your content with this app. And best of all,  its free, first party, and very stable.

CPanel - host management
$3.99, app store link

This one is still a bit early and lacking in overall features, but the potential is there for a great app. If your hosting is cPanel based, you can manage subdomains, see data quotas and usage, manage email addresses, and more. It's still a bit sparse, I don't open this one too often. But the promise of new features makes this one to look at.

Analytics - Google Analytics data viewer
$5.99, app store link

Google Analytics is becoming a defacto standard for analytics. If this isn't your primary metric, odds are good that it is at least a secondary. This third party app is worth every penny of $5.99, and they are still adding features. They just added multiple login capability, so you can see all of your GA data quickly, easily, and most importantly, formatted well for your mobile device.

Pinch Media Watcher - Pinch Media Analytics data viewer
$2.99, app store link

If you develop mobile apps, you probably know Pinch Media already, who recently merged with Flurry. This third party app allows you on the go access to your app analytics data. Good stuff.

FTPOnTheGo - FTP Client
$6.99, app store link

Some may balk at $6.99 for an app. But what did you pay for your desktop FTP client? FTPOnTheGo does a lot for $7 dollars, and the ability to view and edit (text editing only) any file on your server is a must have.

MobileMe iDisk - Cloud storage client
Free, app store link

For mobileme users, this one is a no brainer. You could argue this has nothing to do with web maintenance, but that all depends how (and if) you use the content on iDisk, so I included it in this list.

Echofon - Twitter client
Free, app store link

My blog spits out tweets to my posts behind the scenes. I always check that they were formatted correctly, and if I'm mobile when I post, a twitter client is essential. I'm torn between Echofon and TweetDeck. Either one will do the job well.

LinkedIn - LinkedIn client
Free, app store link

Same goes for LinkedIn, my status is tied to Twitter. So, as above, blog post==tweet==linkedIn status. Gotta be able to verify.

GoDaddy.com Mobile - domain management
Free, app store link

If you register through goDaddy, rejoice - they are fleshing out their domain management app, and it is comforting to know (especially if you own multiple domains, I'm at 20 currently) that you can access your info whenever, wherever.

There are more apps out there to do similar tasks, many are dependent on a users particular needs and the services they use. Peruse the app store, and be sure to use appropriate keywords. You may be surprised what pops up that will allow you instant access to something you just didn't have before.

What apps are you using? Drop recommendations in the comments.

The real time feed could cause far reaching benefits for all of Google's services over the next few months as the big G continues their roll out. It's a safe bet that as this technology matures in the coming months we'll see further improvements that are thanks to the accessibility of real time data.

Google real-time search results

Announced on Monday (see Mashable's post on the topic), Google's real-time search functionality appears to now be fully live. Try some timely topical searches (Tiger is a safe bet these days) and you should see comments, posts, and articles streaming in as they are created. As this technology matures this has the potential to blur or completely erase the line that exists between live feed based informational searches and traditional crawl based searches, and the reach of microblogs suddenly becomes that much more vast as well. Google's video demo after the break.