Two Things the PC Should Borrow from iOS
Ever since Apple unveiled Lion last year, there has been a fairly predictable range of reactions to the basic concept. Apple’s tagline for the OS is “Back To The Mac,” symbolic of a general philosophy that the best ideas from iOS should come full-circle to the Mac. Some of these ideas are pretty universally regarded as great. For example, instant-on computing and always-saved documents should have been added to modern operating systems years ago. Others have been ridiculed, perhaps rightly. The LaunchPad adds further confusion to the processing of installing and running Mac apps. (Where do my apps live? On the Dock? In the Applications folder? On the LaunchPad?) The Mission Control idea is solid, but it confounds the desktop metaphor and adds to a suite of features that reek of being developed for a whiz-bang keynote. Remember seeing Scott Forstall tripping over the gestures on the Magic Mouse at the keynote? To be fair, I do think that LaunchPad and Mission Control are targeted at the problems stated (the confusion about where apps live and the lack of utility of the current Spaces, Dashboard, and Expose implementations). Time will tell whether these are a step in the right direction or whether they merely compound the problem. As someone who works primarily on an iMac but uses an iPad for almost all non-work computing, a few other ideas have occurred to me that the desktop could bear to borrow from the Mac. Some of these are implemented to some extent or another in OSX or Windows, but none of them (as far as I know) work as reliably and consistently on the desktop as they do on iOS. 1. Notifications iOS’s notifications are famously bad. They are modal, essentially non-interactive, they don’t persist when interrupted, and they leave very little flexibility to the developer. But nevertheless, iOS has a consistent, reliable way to deliver both local and remote (push) notifications, regardless of whether the app is active. The desktop OS needs this. While PCs have system-tray notifications (bubble pop ups) and, in Windows 7, jump lists, these depend on helper apps, systray icons, and/or leaving the app running. They are also minimally interactive, are not logged, and are typically transient (such as systray popups which fade before you notice them). On the Mac, Growl is a popular third-party solution which is aesthetically appealing and widely supported by other apps. However, it is not very interactive, unintuitive and laborious to configure, and is not supported at the OS level. Android and webOS devices provide a good model here. Typically these devices have some kind of pull-down (or up) notification tray which logs missed notifications and provides sensible interaction options (reply to a text, snooze an alarm, kill a background process, etc.). These are devices which are chronically starved of CPU resources, memory, screen real-estate, and battery. It makes all the sense in the world that they would evolve to handle interacting with common tasks with minimal actual application interaction to preserve all of these resources. However, the desktop could do much more with the same sort of notification system. Imagine, if you will: when you hit the Expose button on a Lion Mac (which I can only assume will be remapped to Mission Control), a pane at the top or bottom of the screen shows active notifications. Stylistically,this could resemble the iOS multitasking menu. Here, you would see all notifications, even for apps not running (via a system-level push/local notifications API): missed iChat messages, FaceTime calls, red-banged emails, failed backups, active filesystem actions (downloads, copies), etc. A subtle desktop popover or menubar alert would tell the user when there are unviewed notifications; Mission Control would track the log and provide interaction options (type your iChat response directly, run the backup,tell the filesystem to “replace all”). This is a relatively low-cost way to provide important information to the user without interrupting workflows, popping up modals, leaving the current app, or relying on cryptic and annoying Dock icons (bouncing up and down like a jack-russel-fucking-terrier). 2. Audio APIs Something happened to me today when I tried to join a conference call in Skype. After five solid minutes of fiddling, I couldn’t get Skype for Mac or Windows to recognize the device. I eventually gave up and used my integrated speakers and mic. I have a Creative USB headset which I used extensively in a former life for VOIP. However, since I got my iPhone and iPad, I haven’t plugged an audio device of any kind (besides my desktop speakers) into a computer in years. On an iPad, if you have headphones plugged in, it will play through those. If you have Bluetooth headphones paired, it will play through those. Have you ever tried using Bluetooth audio on a Mac or PC? It involves endless control panels with dozens of sliders, incoherent binary toggles, and endless menus. On iOS, there is always a simple button next to the volume slider that lists all connected (and remote via Bluetooth or AirPlay) audio devices. It is nearly zero-configuration, it is easy, and it works well. I understand that fundamentally the audio interface on an iPad is simpler, and USB audio will always be a trickier beast than a single 3.5mm input/output jack. but desktop computers are not just “more complicated” when it comes to audio - they are obtuse, frustrating and effectively impossible. Another example: when you are listening to music on iOS, hitting pause will pause it. It doesn’t matter if it is the iPod app, a YouTube video, Pandora, GarageBand or djay (I was pleasantly surprised the first time I accidentally backgrounded djay, and I was delighted when I found that pausing or changing tracks used the app’s vinyl transition effects). On the Mac, play/pause is mapped to iTunes and often has a 2-3 second delay even on my quad-core i7. If you are watching a full-screen Netflix video and hit pause, iTunes will launch and start playing. If you are listening to Pandora or Last.fm and hit pause, iTunes will launch and start playing. This is stupid. Why doesn’t my quad-core desktop with 12GB of RAM understand what app is playing music as well as my smartphone? (It’s not any better on Windows, but Microsoft doesn’t mandate that Windows keyboards include media buttons.) These are just a couple of examples. I’m quite sure there are many, many more. My point, though, is that “Back To The Mac” shouldn’t and doesn’t have to mean we give OSX icon-grid app launching and mouse-heavy hunt and click navigation. It shouldn’t even mean we obsessively copy iOS sliders and toolbar icons and inverted scrolling behavior. It should mean we observe what evolved on devices with severely limited resources, and think seriously about what that can do for devices with tremendous amounts of screen real estate and brute processing power to spare. Apple clearly gets this, and has made/is making strides in the right direction with auto-save, file versioning, and the app-store. But: How long do we have to wait for a computer to delight us the way our first iPhone did?
