An interim solution for iOS ‘multitasking’
Tue, Feb 26, 13
There are many counterintuitive ‘rules’ in product design, these two are among the most intractable:
• The more successful a product, the harder it’s to upgrade.
• The more users say they want a product update, the more they complain when the change arrives.
It wouldn’t be unkind to ascribe both of them to the iOS platform: spectacularly successful and at the crossroads for the mother of all upgrades for both hardware and software, now commandeered for the first time by a single person who’s not named Steve Jobs. The financial impact of these design decisions is easily the 64-billion dollar question at Cupertino.
What has changed?
Having already sold over 120 million iPads in less than two years, Apple’s now making the sales pitch to hundreds of millions of potential post-PC consumers that iPads may be ‘OR’ devices, not just ‘AND’ adjuncts to their desktops and notebooks of yesteryear.
The iPhone in 2007 and the iPad in 2010 created their respective industry segments, then went on to dominate what was mostly virgin territory with a simple proposition: One Device > One Account > One App > One Window.
Several years after their introduction, now with many competitors, Apple is under pressure to examine every link in that chain of platform definition. And the one most contested is the last: One Window. While it’s true that iOS apps can contain two (and sometimes even more) ‘views’ in one screen, like the standard Master-Detail views, two different apps cannot share the same window. A blog writing app on an iPad can, for example, dedicate portions of its single window to video, map, search engine results or tweet displays, but not specifically to Vimeo, Google Maps, Bing or Twitter apps. In the sandboxed territories of iOS, ‘One Device > One Account > One App > One Window’ is still the law of the land.
As iPads move into business, education, healthcare and other vertical markets, however, expectations of what iPads should do beyond audio, video, ebook and simple app consumption have gone up dramatically. After all, users don’t just inertly read in one app at a time but write, code, design, compose, calculate, paint, clip, tweet, and, in general, perform multiple operations in multiple apps to complete a single task in one app.
In iOS, this involves double-clicking the Home button, swiping in the tray to find the other app, waiting for it to (re)load fully, locating the app view necessary to copy, double-clicking the Home button, finding the previous app in the tray and waiting for it to (re)load fully to paste the previously copied material. That’s just one operation between two apps. Composing a patient review for a doctor or creating a presentation for a student can easily involve many such operations among multiple apps.
Indeed, among the major post-iOS mobile platforms like Android, Metro and BlackBerry, iOS is the most cumbersome and slowest at inter-app navigation and task completion. There have been a few mitigating advances: gestural swipes, faster processors and more memory certainly help but the inter-app task sharing problem is becoming increasingly more acute. Unfortunately, solving iOS’s multitasking problem in general involves many other considerations, including introduction of UX complexity and thus considerable user re-education, to say nothing of major architectural OS changes. It may thus take Apple longer than expected to find an optimal solution. What can Apple do in the interim then?
Is ‘Multi’ the opposite of ‘One’?
Systems designers know all too well: when you just don’t have the time, money, staff or technology to solve a given problem, there are ways to cheat. Steve Jobs would be the first to tell you: that’s OK. A well executed cheat can be indistinguishable from a fundamental architectural transition.
From a design perspective, the weakest link in the one-task-many-operations-in-different-apps problem is the iOS clipboard. The single-slot clipboard. The one that forces the user to shuffle laboriously among apps to collect all the disparate items one. at. a. time.
But with a multi-slot clipboard, if you were writing a report, for example, you could go to a web page, copy the URL, a paragraph, maybe a photo and a person’s email address in one trip. Now a single trip back to the initial app and you have four items ready to be pasted into appropriate places with no more inter-app shuffle necessary. Instant 4X productivity gain. Simply put, if you had a four-slot clipboard, you can instantly quadruple your productivity. For a ten-slot clipboard, 10X!
Well, obviously, it’s not that easy. First of all, Apple doesn’t believe in multi-slot clipboards and doesn’t even ship one with Mac OS X. Also, you couldn’t really have an ‘infinite-slot’ clipboard, for iOS would run out of memory quickly. Finally, a multi-slot clipboard would require a visible UI for the user to select the right content, thereby introducing some cognitive complexity.
None of these objections seem insurmountable, though. iOS already has a similarly useful ‘option selectors’ like the recent ‘share sheets’ from which a user can send stuff to Twitter, Facebook, email, etc. Limiting the clipboard to four slots would enable at least 250-pixel square previews of each slot’s contents for easy identification. The Clipboard could pop, move up, slide in from right or perform some other clever animated appearance. Yes, there could be a cognitive penalty for having to be concerned about system-memory management, but a bit of user training for the concept of ‘First In, First Out’ or a little alert to the user indicating memory-intensive copying would go a long way.
It’s not my job to suggest Jony Ive how this might be implemented in UI and UX. But until Apple has a more general solution to multitasking and inter-app navigation, the four-slot clipboard with a visible UI should be announced at WWDC. I believe it would buy Ive another year for a more comprehensive architectural solution, as he’ll likely need it.