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!

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.

At the begin of 2009, Apple was the only real player in the mobile app market, and today there is no argument that the platform still holds the lead by a huge amount for quality, useful third party applications. But as we push further into 2010 and app stores for Android, Palm WebOS, and even Blackberry and WinMo gain market share, users considering jumping ship will face a similar plight for the first time. How many invested dollars in platform specific apps do I stand to lose by jumping platforms?

The cost of mobile apps and the .99 cent phenomenon
An interesting factor to consider is the actual cost for these apps. Amazingly, the iPhone App Store has somehow managed to make the one dollar purchase a new cultural standard. There are three unspoken rules for price point that near every app purchaser follows, whether conscious or not. If it doesn't offer incredibly deep functionality, it should probably be free. If it does offer something useful, it should be .99 cents and have incredible customer support to boot. If it costs more than that, it'd better either be something for a niche market or the latest 3D game from EA. Anything else will get low ranked into submission, and subsequently the .99 cent price point always seems to show up eventually. The interesting result of this is that the average user may have up to 50 apps loaded in their device, and have only paid in the neighborhood of 20 dollars, if even that. For these users, the cost involved with switching platforms is low enough that the cost barrier doesn't outweigh enough of the device cost to rule out the switch.

Higher cost apps
Low cost apps may ultimately be less of a concern, but what about higher cost apps? Navigation apps are an obvious first contender here, with dollar figures as high as $99 and up. But even if we disregard this app category, $5 apps add up very quickly. A mobile professional using a few more expensive apps can be looking at an app bill up to the $50-$100 range to get their existing applications onto their new device.

Free apps
Even free apps still pose issues. In the past, the worst part of getting a new device was re-entering all of your contacts into your shiny new device (on a monochrome screen, no less). Thankfully those days are generally over, thanks to desktop sync or carriers handling the move for you. But for the first time users may face a new transition nuisance in the form of setting up their apps all over again in their new device, if the app (or an equivalent one) even exists in the new platform's store. There's both learning curve considerations and the time required to re-enter all of your preferences and logins. It can be a full days venture or more depending on the apps in question.

Pulling the trigger
For most, the deciding factor will be cost, and it's likely a percentage. If a user is looking at $150 for a subsidized phone and then immediately face an additional initial outlay of $50 or more in app costs right from the get go, plus a day to get their device setup with those apps, it may be enough to make users think twice about the switch. I'd wager that if the total app cost is less than 30% of the device cost, it's negligible to the user. It's a phenomenon that we haven't truly experienced yet, with the exception of possibly legacy WinMo users who may have purchased software for the platform and jumped ship to the iPhone. But the percentages of users will grow exponentially this year as Apple faces what is likely to be a much larger platform and apps push than they've seen yet from Android and Palm. Inevitably a portion of users will consider the switch. What is unknown is whether those users will have the foresight to realize the app transition cost and, if so, if that will be enough for them to stay with their existing platform instead of jumping ship.

It's an interesting notion to think that perhaps Apple intended this all along, anticipating the competition that was guaranteed to emerge. Unlike on desktop OS's, mobile platforms don't follow the serial number registration paradigm. As such, it is near impossible for third party developers to even allow a free or low cost transition between platforms, as many desktop software providers do today. Time will tell whether platform agnosticism will begin to appear in third party app purchases,  but for the time being, as users continue to download and purchase more apps, they are effectively creating more vested interest in sticking to their existing platform, making the inevitable question of jumping platforms all that much harder to stomach.

So what do you think? What would be your threshold for switching platforms being simply too much to contend with? Sound off in the comments.

I'll leave the specs to the tech blogs, here's some links:

Engadget

Mashable

Gizmodo

Got all that? Good. So what does this all mean? Google's sudden announcement of sorts (of course, this is still all very unofficial) could signal an important shift in the way Google is marketing Android. Clearly, the real competition for Android is the Apple iPhone OS. Apple has always been a hardware manufacturer who also makes their own software and OS, however Google has always kept a hard line of being the exist opposite, focusing on data as a product. If Android is to succeed, part of that success will be to distance itself from the third party only precedent that Windows Mobile has already set, and adding a first party device could help to do just that. Even Microsoft has realized the value of a first party device with the often rumored pink phone.

Android is still a third party first platform, and although this may create some buzz for Android in Q1, this is still a third party phone from HTC with a Google logo on it. That does make it a gold standard Android device (with no third party skins and theoretically first priority ROM updates), but so is the Droid, so what is the justification for Google? If the no contract purchase rumor holds true, is this just Google making an attempt to try and shift the market away from subsidized devices? We'll have to wait and see, but since we've already effectively seen the ROM that will be in the device in the Droid (2.1), that really only leaves room for hardware surprises to capture market share. We'll likely see what cards Google has to play at CES in January.

http://gotoandlearn.com/play?id=116

While the tutorial itself gives a clearer illustration of the development process, what's more interesting are some of the notable details that clarify or improve upon the MAX announcement back in October.

Perhaps most intriguing is the hardware accelerated demo at the end of the video, which definitely contradicts the relatively poor performance of some of the demo apps already in the app store, and is impressive versus those case studies that Adobe initially revealed.

Even more notably, Adobe has clearly made some substantial headway on the file size bloat issue. 8-9MB base weights were initially stated by Adobe at the MAX announcement, however the test app exported here weighs in at 3.2MB:

It should be noted that this is not a final compile for distribution, which could potentially add more weight (only Adobe knows for sure at this point), but it does appear that Adobe has put some effort into fixing that glaring problem. Bearing in mind that apps over 10MB in size require WiFi to download apps over the air to the iPhone, a high base weight poses a significant barrier to entry for end users to install even the simplest of AS3 based apps.

Also seen in this tutorial is the new  'flash.sensors' package, part of the 10.1 (and likely future Flash Player 11 release) which gives access to device interactions. In this demo, we see an implementation of the accelerometer class on the iPhone, and Lee does note that this will, as expected, be accessible with other 10.1 enabled mobile devices.

Finally, Adobe made it a point at MAX to be very clear about the lengthy compile times for iPhone applications, potentially in the neighborhood of five minutes in length. While this tutorial is for as basic as an app can get, the app demonstrated her takes a mere 38 seconds to compile. Again, this is not a distribution compile, but compile time issues aren't a concern for one-off compiles for distribution. Rather, it's the time suck of test builds that are potential deal breakers. 38 seconds is a promising number, but it remains to be seen what real world app compile times will wind up at when the Flash CS5 beta drops on Adobe Labs, which this tutorial further confirms as on track for the end of this year.

Lee's original post on theflashblog.com can be found here:

http://theflashblog.com/?p=1510

Adobe Labs - Adobe Flash Professional CS5: Applications for iPhone.

Fosfr .9 release change log

In other news, 'QuickText', my first iPhone app store app, has been out for a few weeks, I'll add more detail on that soon.