Really, killing apps is the only reason to have the multitask bar anyway - since multiple instances of running apps isnt possible in iPhone OS, you could simply return to the running app by re-tapping the app icon on the home screen. The multitask bar exists solely for a shortcut to running apps and to kill them from running.

No more stressing in the blogs about apps being killed only by the OS! You do have control if you want it. Likely what Scott was implying is that you just don't have to monitor it if you don't choose to.

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!

]]> http://www.jeffdepascale.com/index.php/mobile/bing-app-launched/feed/ 1 http://www.jeffdepascale.com/index.php/mobile/nuance-removes-contact-upload-requiremen/ http://www.jeffdepascale.com/index.php/mobile/nuance-removes-contact-upload-requiremen/#comments Wed, 16 Dec 2009 02:40:29 +0000 Jeff dePascale http://www.jeffdepascale.com/?p=379 Nuance has reacted quickly to the initial negative response towards the required upload of a user's contact names to their servers, releasing a 1.1 update to their Dragon Dictation app today that makes the upload optional, and allows existing users to remove their existing data from Nuance's servers if they had already opted in. The data upload is intended to improve the recognition of contact names by the speech to text algorithms, however the previous requirement of this upload of personal data was a frequent topic of concern in initial reviews of the app.

See my original review of the app here.

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.

 If history is any indication (and with Apple, it definitely is), we know a few things are likely facts about the next major iteration of the iPhone OS.

1. It will be announced in March and released to registered developers shortly thereafter
Apple's annoucnement schedule is growing increasingly rigid. You can bet on the beta announcement sometime around mid March, and a new device with 4.0 in June (with the release to existing users close behind).

2. It will include a fair amount of the buzz items that have been predicted, but not all of them
A lot of the speculated features won't make it to 4.0, but the good ones will, on two conditions. One, that they benefit Apple, and two, that they are timely (we'll leave technically feasible out of the mix since it goes without saying). Apple is a marketing machine, sometimes at the expense of what is best for its growing user base. The benefit to them is that those decisions often grow that same user base by destroying competition by releasing features in a timely manner, gathering more buzz than they would have, and often times implementing the functionality better by learning from the early adopters mistakes. Apple has a track record of doing just that incredibly well. Copy/Paste & MMS? I rest my case.

3. It won't do true multitasking
I'd dare say that the truth is that they probably could do it now technically, but they still won't. Its far too soon to eat their own words about why its a poor decision, and, while push notifications are still incredibly useful on their own, the way in which they were touted as a replacement for multitasking makes a larger time gap necessary to keep Apple looking like they were correct last year, and that they are still correct now.

 4. It will deliver at least one unexpected, buzzworthy feature
Apple knows that to get buzz, they need at least one thing to tie up blogs about for a two week period. to do that, it needs to be ground breaking in some way. Expect something unexpected in some form for March, but likely more of a technological benefit than a glossy, direct end user benefit - thats saved for number 5:

5. There will be at least one major feature of the final release not announced in March
OS 3.1 existed both for bug fixes and to give developers access to the unnanouced video player API that was clearly ready well before and saved for the 3GS launch. Expect at least one unnanounced API that is device specific to the next gen iPhone/iPod Touch that won't be available in the 4.0 beta, but will be in 4.1, which will probably be in September.

6. No more paid updates for Touch devices
It's been batted around the web for a while now, but the real reason this is likely is due to the huge market share the Touch now accounts for. Getting that user base on the latest OS may soon outweigh the dollars from paid upgrades.

7. The end of the road for 2G iPhone/1st gen iPod Touch device support
It was a possibility with 3.0, but its a near inevitability with 4.0 - the original 2G and the 1st gen iPod Touch will likely no longer be supported. 3.0 runs comparatively poorly on these devices as it is. 

My predictions for new OS 4.0 features:

1. Background processes
Further promoting the "we don't need multitasking" mentality, I'm guessing some form of background or shell-style app integration will be allowed, possibly via the copy/paste menu, which could easily be a full context menu. This opens up the option for simple application accessors to be available between apps, which brings me to #2:

2. Cross application access
Right now, the sandbox between third party apps and anything else is exceedingly rigid. Some form of improvement will be made to allow more explicit communication to core apps and possibly even other third party apps, but this is much less likely in this iteration of the OS.

3. Event modes and location awareness
Based on patents filed by Apple, this is a logical change to make it more lifestyle integrated. The device will change modes and operating states based on calendar events, timers, physical device location, and likely device docks as well. They need something to compete with Android 2.0's car mode (not to mention Google Navigation, which i think Apple is preparing a competitor to, but not in this release).

4. The end of the home screen as we know it
It just doesnt work anymore, and the iTunes 9 interface for moving the icons around is clearly a stopgap solution for a company that puts such emphasis on interface. Do we really think that Apple will stick to a paradigm that requires connecting a mobile device to a physical computer to easily manipulate the icons? If anything, grouping will appear, but I'd expect a substantial change to the home screen interface this time around.

5. Sync access to third party apps via iTunes
The http port workarounds for third party apps to upload and download data is a mess and confusing to most users. Moreover, the inability to sync data any way other than over the air is problematic at best, and is one of the last benefits that Palm and WinMo still hold over Apple. I'd be very surprised if Apple doesn't fix that quickly.

6. The end of the name 'iTunes'?
The application is clearly no longer named properly, and the recent acquisition of Lala is a good opportunity to spin iTunes into something brand new, cloud based, possibly a Pandora killer. If the 'tunes' portion of iTunes is due for such an overhaul, it would be an opportune time to rename the core application and clarify that audio is but one of the functions that the application serves. Apple's push into the enterprise sector will be huge this year, and an application that seems worthy, both in functionality and name, in a business environment, seems essential.

So there you have it, my thoughts for 4.0. What do you think about 4.0? Sound off in the comments.

Bucking that trend of repititive or marginally useful apps comes an elegantly simple yet profoundly useful app from Nuance. Best known as the company behind the well-known Dragon Naturally Speaking speech recognition software, they have released the first version of what could potentially be the next killer productivity app for mobile devices, Dragon Dictation.

Press a button, record, click done, and the app wooshes your voice off to Nuance's servers to be translated into text, and sent back to your device, ready to be edited and copy/pasted wherever you need it, complete with handy shortcuts to email and sms.

Users of my own flagship app, Quick Text (iTunes Link), will recognize some userflow similarity here. It's identical. Not that I take issue with that - quite the opposite. It just reinforces that my architecture was a valid one. Actually, it is immediately apparent to me that, in many cases, the Dragon Dictation app is superior to Quick Text for many short response situations, especially where phrase customization is required. Thankfully, I am happy to report that the 2.0 release of Quick Text is in build now and adds substantial new functionality that should render it useful in parallel to Dragon Dication.

Dragon Dictation NOTE: iTunes link

I've already found Dictation so useful that it has already found a place on my iPhone's homepage, right next to Quick Text, and is already proving it's worth as an often-used app, deserving of that placement. What this app does well, it does very well. It even works over bluetooth, so dictation in-vehicle is now a reality EDIT: I was mistaken, bluetooth does not work with this app. But that's not to say that it isn't without it's flaws. Let's look at a couple of those:

1. Accuracy

At first blush, I was inclined to give Nuance the benefit of the doubt here, and I still am. Given that this is a 1.0 release (actually it's already 1.0.1 as of this writing), bugs are expected, and efficiences and improvements are almost a given. Having said that though, this is Dragon we are talking about, and the technology behind the speech to text in use here is not something new. This is an implementation of what Dragon already does best. But I am still holding out hope that future updates will improve the accuracy, particularly when it comes to recognizing contact names with complex last names. Which brings me to number two.

2. Contacts are uploaded to Nuance

In the day and half since this app has been released, there has been more noise about the legal language you agree to when first running the app than the app itself. About halfway down the legal copy you'll find that Nuance uploads your contact list to their server to, in effect, build a custom add-on dictionary for Nuance to better recognize your contact's names. Let me say first say that I fully recognize the issue people are having with this, but at the same time I personally don't have an issue with it. What I do have an issue with is that, for all the hubbub about this, it doesn't really seem to work too well yet. Most names I tried, no matter how I spoke them, rarely were recognized correctly. I'll reserve final judgement after the app matures.

3. Apple's API restrictions

This one I am intimately aware of through my own frutstrations as a developer with Quick Text. You simply can't reduce the effort involved for the user to get that content out of copy/paste efficiently with OS 3.0. Until Apple opens up the API further to allow some form of multi-tasking and possibly context menu access, the flow now to paste something into anything other than email is: open Dictation->press record->press done->correct errors with keyboard (if needed, but likely)->press done button->press send to clipboard->close app->launch app to paste into->press and hold in field->choose paste. It can, and should, be simpler, and in reality it probably will be, maybe in 4.0. We'll see what Apple's next move is, but in the meantime I can't fault Nuance for this issue given my own acute awareness of this shortcoming of the API.

Given all of this, it is a groundbreaking, useful app, which is a rarity right now on the app store. And to top it all off, Nuance made it free for now, which I give them much credit for. I don't doubt this app will cost something soon, and that's a great strategy in the near term for them. It gets a solid user base in place for testing, gets the word out, and eliminates some of the obligation to provide a superior product. After all, don't we expect near perfection from paid apps? By the time they do add a price to this app, I don't doubt that it will be very stable, very useful, more feature packed, and well worth whatever they choose to charge. So kudos to Nuance for thinking outside the box, and doing it well to boot. So go grab it on the app store for free (iTunes Link) while you still can, and let me know what you think in the comments.