Cupertino Kremlinology

In preparation to try my hand at Apple prognostication, the standard disclaimers apply: I have no inside information, I am engaging in idle speculation, and I am fully prepared to eat my words. Okay. Let’s get started.

I’m not interested in what unreleased hardware will look like, since it’s safe to say anything designed by Apple will be simple and breathtakingly beautiful (as usual), and will solve the associated design challenges with kick-you-in-the-pants obviousness.* The interesting question I keep coming back to is whether a tablet device will run the iPhone OS, and by extension, run iPhone apps.

First of all, since the rumored tablet would presumably have more in common with an iPhone than your mom’s MacBook—multitouch screen, accelerometer—it’s safe to say it would not be running Mac OS X. Apple has already created a mobile version of OS X—the iPhone OS. Furthermore, it’s clear that Apple has designed Cocoa Touch from the beginning to have enough headroom to grow into a device with a larger screen. (Which might explain why the SDK took so long.) Evidence of this includes the UIWindow class, which exists even though iPhone applications display only one window. I bet Cocoa Touch on the tablet will allow multi-windowed applications.

I would also wager that the device would be able to run existing iPhone apps without any trouble. I’m almost positive, however, that they won’t run full screen. App developers have spent too much time optimizing their UIs so widgets are relatively finger-sized. The interfaces simply won’t scale without usability problems.

Given that size is less of a constraint in a tablet device, I expect the hardware to be powerful enough to support multitasking. This, combined with the presumption that the tablet would run iPhone apps at their native size presents an interesting UI possibility. I envision a dashboard-like layer where a limited number iPhone apps run as widgets on the tablet.

Picture this: iPhone apps launch on a translucent layer where a pair of widgets run side-by-side on the screen. A simple swipe will switch between pages of running apps that don’t fit on the first screen—just like having multiple pages open in Mobile Safari. Capping the number of simultaneously running apps is as simple as limiting the number of pages in the widget layer.

Apple would be crazy to launch a device without the momentum of the App Store behind it, and the only way hit the ground running would be to let existing iPhone apps run on a tablet. In the end though, Apple has spent far more time thinking about these problems and refining the solutions than all of the armchair product-designers and rumormongers combined. I may be wildly off predicting the app switcher, but it’s a fairly safe bet that whatever we see next Wednesday will blow us away.

* I won’t speculate on text input other than saying that I don’t expect to see Inkwell, Mac OS X’s pen input software, anywhere near this thing. Considering there’s no page dedicated to Inkwell on Apple’s website, it’s easy to guess how Jobs feels about this technology.

In the Cards

John Gruber responds to Justin Blanton’s To Pre or Not To Pre:

The entire user interface is built around the concept of cards rather than apps. So while the iPhone’s Mail app already stays running while in the background, what you cannot do on the iPhone but can on the Pre is have multiple email messages “open” at the same time.

There are a few things going on here. The SDK only displays a single 320 x 480 window per application. This is most likely some combination of a design decision (application switching happens through the depth axis) and an engineering decision (it’s easier to manage windows when an app gets only one of them). Developers, of course, are free to implement an interface like the ‘pages’ in Mobile Safari. (Ah-ha! The card metaphor has been on the iPhone since day one.)

So the decision not to implement pages in Mail has nothing to do with whether the iPhone OS supports cards or whether a developer is capable of displaying and switching between multiple open documents in any other way. My guess is that implementing pages in Mail was either considered too trivial or too confusing to implement.

The interesting thing is that views within an iPhone application belong to a window object. Currently, of course, an application can only display one of these, but I suspect it wouldn’t be too hard for the OS to allow multiple windows of an application to behave like cards.

How Microsoft Will Fuck Up the Future: Healthcare

The future according to Microsoft 2019:

1. Doctors will never feel like lab rats in a maze because they’ll have tablet computers to help show the way. Instead, they’ll be more like lemmings and blindly follow arrows projected on the floor.
2. In the future, even pill bottles will need complex interfaces.
3. Doctors will need tablet computers with magic x-ray vision to find their equipment, because apparently med school won’t teach you how to look for things without help.
4. Microsoft will finally release Microsoft Wallet, and even though it will have more computing power than the entire moon mission, you will still have to flip though various store rewards cards to find the right one.

How Microsoft Will Fuck Up the Future: Banking

The future according to Microsoft 2019:

1. You are nothing but a blinking dot on a computer screen in the eyes of bank associates.
2. Online banking has disappeared. You have to go to a branch office to view account statements and fill out forms.
3. Even though everyone has tablet computers, you still apply for mortgages by filling out a paper form on a clipboard.
4. There’s a real person at the teller window, but she won’t be able to help you so you’ll have to video chat with a guy on a park bench.

Regarding iCal Usability

Marco, in a post about mediocre Apple software, complained that “Moving the ‘drawer’ event-editing interface into an annoying popup, [introduced] even more interface quirks and unnecessary clicks.”

The latest version of iCal made a few interface improvements, and the pop-up editor should be counted as one of them. Perhaps it’s time to do a usability tear-down. I won’t pretend to be unbiased, but I will try to back my points up with examples. For those of you following along at home, I’m comparing iCal version 2.0.5 to version 3.0.5 simply because those are the versions installed on my old laptop and new one.

The immediate differences are obvious, when side by side. Taking advantage of the new unified title bar and toolbar look in Leopard, the day/week/month segmented control and the search box have been moved to the window’s toolbar, where they’re more prominent. Also, the mini-month view has been redesigned, and the editing drawer has been replaced with a pop-up editor.

The redesign of the mini-month view was much needed. The new view is roomier and offers more information. It uses three-letter abbreviations for the weekdays instead of the cryptic initial letters. When the first and last weeks of the current month share days with the previous and next months, they are now shown, but in a much lighter gray. By grouping the previous and next arrows around the month label, their function is more intuitive. The confusing diamond button in the old month view has been replaced by a “Today” button in the toolbar. Overall, these improvements are subtle but worthwhile.

I found the editing drawer in version 2 problematic. I would frequently move the window to one side of my screen to transcribe info into new events, but the drawer would get hidden off the edge. So I’d usually just keep the damn thing closed. At least the drawer did the right thing (it would automatically open on the side of the window with enough room) when double-clicking calendar whitespace to add a new event. But double-clicking an existing event only selected the event name for editing. To edit the event, I had to either type Command – I or click the info button in the bottom right corner of the window.

In version 3, double-clicking an event will always bring up the info pop-up, and double-clicking whitespace in the calendar will create a new event and bring up the editing pop-up. I haven’t found the pop-up to be quirky at all. However, double-clicking the date portion of a square in month view will switch to view that day.

There is one major issue I still have with iCal. Its time zone support has sucked from day one, and I have never been able to get event times to stay consistent across time zones. It’s some sort of black magic or something, and I don’t have the time to figure it out. Overall, the under-the-hood issues with the software are more annoying than any interface quirks.

The iPhone Continues to Ruin the Desktop Experience

I popped over to Google Maps on my trusty MacBook Pro, looking for the nearest Staples. It took me a couple seconds to realize that Mac OS X doesn’t give me a nifty Core Location button.

Location-based technologies are an obvious addition to mobile devices and portable computers, but I would argue that even desktop computers would benefit from knowing their location in meatspace. Eliminating a step in the “find stores / ATMs / movie theaters / homicides near me” process would be worth it alone.

Hardcopy

My boyfriend was flipping through a copy of my thesis today and spilled some water on it. Without thinking, my first reaction was to say, “Don’t worry. I have a hard copy on the computer.”

Have we reached some sort of tipping point in favor of the paperless office? Paper tears easily; it becomes yellow and brittle; it is a sponge for humidity, oil, and dirt; it presents myriad environmental issues. A hard copy used to be a way to be extra super sure that important information wouldn’t get lost, but with today’s reliable hardware and regular backups it’s quite likely that digital formats will outlast physical ones.