It seems the main desire for multitasking in iPhoneOS is twofold: (1) Running background processes, either to do something else like Pandora music (the #1 complaint I've seen mentioned) or to update other apps like Twitter or Facebook. (2) Relating to information in one app from within another app.
Putting aside the first issue, which has been half excused with push notifications (though it seems like a hack) the second issue has perhaps even a better solution than multitasking.
If iPhoneOS apps could publish controls that other apps could access then a user's experience could be more seemless and smoother than the current multitasking experience in Windows or OSX.
Imagine for a minute, if you want to quote a mail you recently received, you perform the 'include' gesture and you are presented with a popover or modal screen presenting you with a choice of the 'include' controls published by your other installed apps. You can click the include mail control, and be presented with a list of your mail to select one or more messages and 'include' them in your current app. The means by which they are 'included' depends on how your current app chooses to deal with included material.
This is essentially what the many image manipulation programs do now when you go to your photo roll to select an image to edit. In addition to being more seemless and more intuitive from a simple user workflow, we've eliminated the concept of files and replaced them with resources belonging to one app or another.
Similarly you could provide 'peek' functionality to just look at another app (at least the info they make available through their peek control) for a moment without leaving your current app. I'm sure there's probably six main types of controls (including 'include' and 'peek' mentioned here) that could create a standard visual and user-flow language that would answer most of a user's multitasking needs in a way that is better than multitasking.
The controls have to feel very responsive lightweight and fast, of course, but the benefit is that the line between the OS and the apps is blurred in terms of who provides functionality, but clear in that it is apparent when you are using an app's controls, and apple still has ultimate control to ensure the user experience doesn't suffer. You could even use the 'lift up the app to reveal a page behind' interface we saw in the map app in the iPad demo as the default place for the user to choose one of the six control types, and then be presented with a list of controls.
I for one would welcome an iPhone/iPad app-control-oriented future instead of a multitasking future. Users won't be able to lose windows, or leave tasks running in the background which they have forgotten about. It's a serious win for the 80% users.
There is some sense in this, but I'm not sure what it has to do with multi-tasking.
ReplyDeleteWhat you are describe sounds like a generic API for sharing data between apps. Although you mention "published controls", if the other app is not running then it's either the host app, or the OS, that is hydrating them from data.
Sharing data between apps is not an easy problem to solve generically.
At the most basic level we can already share data, of course. Copy-and-paste allows us to copy text and simple media between applications.
But beyond that we need an established protocol. This is hard if you don't know what the apps will need. Maybe we could establish a protocol for your "published controls". Certainly a xib file could handle the controls themselves, perhaps extended with url-style hooks into the other app. That could work.
The iPad will give us something new (or at least something we no longer have easy access to on the iPhone) - a shared area in the file system.
It's concievable that we could drop xibs in there (perhaps by a different extension) to "publish" external controls, and have an app scan for them. We could do that with no further input from Apple.
To do any more than this would, I think, require more knowledge of what the publishing apps can do. Then you can have an interface published as an API itself. This can only work for very well-known, ubiquitous apps. You know, like email, photos, calendar etc. The sort of apps that Apple would provide anyway - and they have. Sure enough these apps do have APIs baked into the platform.
One possible "enhancement" here would be to allow app developers to replace those apps with their own implementations - such that the platform APIs work with them instead. Historically Apple has not been very keen on this route and I don't think they are likely to change there. Neither do I think they are wrong (or right) in doing so. There are trade-offs either way and they have made a choice.
BTW, another way for apps to share data with, and control (to some extent) other apps is to go via "the cloud". For a secondary class of "well known" apps this is already in use. Services like Instapaper work on this principle.
But in the end I think the only multi-tasking principle this all relates to is fast-app switching.
I mention that, and my own ideas for alternatives to multitasking in my own blog (from which your comments brought me here :-) ).
Hi Phil, thanks for taking the time to read my post, and for leaving the lengthy comment! I really appreciate it!
ReplyDeleteFor certain, I was only addressing the fast-app switching problem. (Which I thought I had made clear from the introductory paragraphs)
The original idea was intended as a better way for Apple to handle fast-app switching at the OS level, but your idea of using files in the shared space on the iPad sounds neat.
I was thinking more along the lines of services as in OSX, but I recently read that Android has implemented something very similar to my idea. (Can't seem to find the source of that info, I'll have to check out android to see how they do it.)
And, as you suggested, I've actually got my eye on an app idea that would sit in the cloud but let people develop and share code on the iPad/iPhone without violating the "no running downloaded code" app restriction.
Thanks again for your time!