“The cloud” is touted as one of the biggest advances of the current era. And it promises to be: having information stored centrally and synchronized seamlessly across multiple devices would be a dogsend. The operative word being “would.” There are a few potentially faulty assumptions here, one of which is that there is a single “cloud.” And there is also a catch: that is, the “multiple devices” bit. Just how many, and of what capabilities, are we talking about?

It turns out that when you start to mix and match, as invariably happens in real life, things become slightly more complicated. I have encountered this recently when trying to understand exactly how and where all the data is flying around between and among my two Macs and my iPod touch, and MobileMe (personal information) and Exchange Server (work). I had quite a time putting together the following diagram, but I think it is accurate.

The iTunes sync from the Mac Pro to iPod touch is tethered; everything else is wireless on wired internet. I should note that this is actually a simplification of my setup: I have several private domains as well. But it gives a good picture of the problem: by default, not everything is synchronized, or synchronized live. And I’m using a single vendor (Apple), at least for my devices. First, due to what appears to be a bug, address book information doesn’t work between Exchange Server and Macs—though on the iPod touch this is not an issue. However, for me the crux of the problem is trying to undertand why only mail is “ON” (whatever that means) by default:

There’s nothing to indicate what “ON” versus “OFF” means. My address book and calendar are synced via iTunes; as an expert user, I made the leap to assuming that this means “over the air” sync, rather than depending on a tethered sync via iTunes. But when I flip the switch to turn on, say, Calendars, I am presented with what I think may be the most confusing dialog message I have received in thirty years of computing:

I defy anyone to explain to me, based solely on the message and buttons, what this means. I spent half an hour today chatting with an Apple support representative, and I’m not convinced that he fully understood either.

• Of course there are calendars on my iPod not synchronized with Exchange; of all vendors, one might think that Apple would make the assumption that living in an all-Microsoft world isn’t necessarily the norm.
• Would I like to merge the (non-Exchange-synced) calendars with MobileMe? Well, they’re already synced with MobileMe via iTunes. What is the difference between “syncing” and “merging”? Will the latter duplicate information?
• Which “server-based calendars” are being referred to here: MobileMe, Exchange, or both? I assume “removed” is a synonym for “deleted,” but removed from where? My iPod, Exchange, and/or MobileMe? Scary.
• What is the difference between “Do not Merge” and “Cancel”?

I’m going to take a chance—while I’m writing this post—and tap “Merge with MobileMe.” I have backups.

After proceeding, I get a progress message, “Turning On Calendars…”. This lasts for a long while (at least five minutes), until finally I stop tapping and the iPod turns off its screen. When I rouse it again, the Calendars setting is “ON”.

And what is the result? I created a new event on my iPod touch, and it has appeared on MobileMe without a tethered sync. So much confusion and stress for something that should have been set up by default. If it took me this much analysis and thought, what is the lot of the average user? Synchronization strikes me as a complex development challenge, but it should be the default: that is the promise. If Apple hasn’t got it right, what chance do we have?

Now I’m going to try turning on Google sync …

I subscribe to Canada Post’s epost service, which promises to consolidate delivery of all your bills. It doesn’t quite manage that, largely because not all vendors support the service. That may change; in the meantime there’s a certain convenience to it, particularly in that it’s apparently the only way to get my Vancity Visa bills in PDF format rather than paper.

I’ve been thinking recently about usability issues related to this kind of regular but infrequent online experience. It seems that it’s often the simple things that cause frustration: the details surrounding getting to the desired or promised information. Destinations can be obscured by giving equal or greater weight to tasks and audiences not directly related to the notification. Memorability is an important aspect of design in this case, and it seems that this it often not well supported due to a lack of focus on the interaction initiated by the email.

The following screen shot shows the body of the email sent by epost when a new “mail delivery” is ready. Where would you click? Notice the prominence of the big blue “Remind Me” button, compared to the link to the service itself, where the bill can be accessed. Every couple of weeks I have to think consciously about where to click. How many people want to be reminded again, rather than just retrieve the bill, or leave the email in their in box, flagged or unread?

After remembering to click the link, the main epost page is displayed. The email notes that they don’t link directly to the log in screen from the email due to security concerns. I’m not sure what value this really has, as a phishing attack could simply replicate the main screen as well as the log in page. So the epost customer is delivered to the same page that any new user would see upon first going to the site, which is focused on getting people to sign up for the service. The “Sign in” button is also in a non-standard location, and perhaps even below the fold for some people.

Given that the security concern is a real one, why not pass a parameter via the email’s url so that the page swaps focus from “sign up” to “sign in”?

Simple changes to the email and landing page might prevent thousands of people from having to stop and think—twice—every time they receive a notification from epost.

My recent video blog on interaction design in online market research for Vision Critical.