10 Jan 2013

Thinking Different with iCloud

iCloud is different in many ways from Dropbox, Google Drive or SkyDrive (which are pretty similar to one another, so I'll just refer to them as Dropbox below).

To begin with, Dropbox is ultimately a folder that syncs. It's a cloud version of your Documents folder on OS X or My Documents on Windows. You still manage files and folders in your Dropbox. iCloud is different — it's not a folder, and does not have a filesystem user interface. In fact, it doesn't have any interface of its own. Instead, you access your data through the app that created them. So if the Dropbox model looks like:

App <-> User <-> Dropbox

the iCloud model is:

User <-> App <-> iCloud

In that sense, iCloud is used directly by the app rather than the user. The user interacts only with the app and never directly with iCloud.

This frees iCloud from the files and folder paradigm. Many apps don't expose their data as files that you have to manage. For example, a tasks app lets you think in terms of tasks, not files.

Many of these apps store their information in a database. (iCloud syncs these by syncing the transaction log and replaying it on your other devices.) And some apps store their information in a hidden directory, perhaps each note in a file by itself. Whatever the technical details, from the user's point of view, these apps don't store data in documents for the user to save, open and generally manage.

Even apps that could represent data as files often don't. A notes app like Simplenote could in effect be a text editor that lets you open, save and manage files. But Simplenote abstracts away the filesystem, freeing you from the tedium of managing files, and letting you think in terms of notes. Apple calls these shoebox apps.

As John Gruber astutely points out, this means no more losing unsaved data, or trying to find the right place in the filesystem every time you save a new file. Apple fixed these two problems with autosave, but you still have to deal with the mechanics of opening and closing files. And when you open a file, you have to deal with the file open dialog box and locate the document, often using a name that doesn't make it fully clear what you are opening. This in turn means that you have to choose a good name while saving, lest you end up with Untitled, Untitled2, Untitled3 and so on. Even if you are careful to give files descriptive names, how often do you end up having to open a file to see what's in it? As John points out, the friction of the file system subtly dissuades us from creating or saving small items of data in the first place. Shoebox apps do away with the filesystem, and all its complexity, and just show you your data.

Another example is iTunes — a song is better identified by its title, album and band than by a file name. Similarly, you would want a photo viewer to identify a photo by its actual content rather than its file name. We all have folders full of files like IMG_8348.

So, the bottom line is that file names are often not the best way of identifying what's in the file. They are instead a least common denominator identifier imposed by the file system on all apps, when the app can often do better. File names at their worst are not merely non-optimal but downright useless, as with IMG_8348.

In addition to names, files in the file system are also identified visually by an icon. This again is a bad idea — a document is better represented visually by its actual content rather than by an abstract representation of its file format (which is a secondary detail), or by a tiny version so small that you can't even see it clearly. Compare:

(credit: Pocket Lint)
with:

Tell me how this tiny low-res icon is a better representation of the document than the document itself? Put differently, why have two different representations of a document, one when opened, which is the real deal, and a second tiny, extremely low-fidelity, often unintelligible copy of it? This is a recipe for failure. How often have to had to open a document to see what it is?

And the correct representation of something varies from app to app. Compare an album in iTunes:


 with a note in Simpenote:


and a photo in Picasa:


They are nothing like one another.

So, if file names and icons are bad ways to represent documents, and a full-fidelity representation of a file can be presented only by its app, and varies from app to app, it follows that the only way we can solve these problems is by getting rid of the filesystem as a user interface. This is exactly what iCloud (and iOS) do. The app is in control.

(In addition to app data, there's app settings. iCloud handles these by providing a key-value store, in addition to a file store. Dropbox doesn't have this.)

Doing away with the filesystem not only allows a better representation of files, but also makes iCloud work for data that's not files (or, equivalently, not represented to the user as files), as with a tasks or notes app. iCloud works one level of abstraction up from files, which is the Dropbox model, letting you think in terms of your data.

This certainly has disadvantages. For example, iCloud effectively forces users to manage synced data in a different way from local data, which is often managed using the filesystem. Whatever iCloud's merits, why should users have to learn and use a different method for organizing data based on where it's stored (local or cloud)?

Moreover, apps are not always the right way to organize your data. For example, I have a folder in Dropbox for my financial information. It doesn't make sense to think of it as Preview files, even if they happen to be PDFs that happen to open in Preview. Logically they are my financial information.

Further, some of my financial files are saved web pages or screenshots, but again, they are not Safari files or Photos files, so organizing by app wouldn't make sense. It doesn't make sense to split up my financial folder by file type. Moreover, I also have some ebooks in my Dropbox, which shouldn't be grouped along with my financial information as Preview files.

So, files that are logically related should be grouped together even if they are of different file formats, as with my financial folder, and files that are logically unrelated to one another should not be grouped together just because they happen to use the same file format, as with my bank statements and ebooks, which are both PDFs.

Besides, I might switch to another PDF viewer later, perhaps Skim, so my PDFs should not be Preview files. This separation between apps and data seems important.

And what if a future version of Microsoft Office does not let you open your files in LibreOffice (née OpenOffice) or upload them to Google Docs (disclosure: my employer)? Your files should belong to you, not to the app.

Not that putting the app in control doesn't have advantages, like security. iCloud protects your data from being accessed by apps that have no business accessing them. Whereas any app can access any data on my Dropbox. Sandboxing is still possible in the Dropbox model, as with the OS X's sandbox, but harder when the data is not associated with a particular app.

But, at the end of the day, security should ideally not be at the cost of lock-in. Fortunately, this seems to be an easily solvable problem — sure, restrict apps from silently accessing data created by other apps, but let the user choose to open a document in another app.

This will require iCloud to have its own file browser UI, which brings back all the problems of the file system, but users won't have to interact with it on a day-to-day basis. This is like Google's data liberation efforts — they don't complicate the products on a day-day-day basis, or for casual users like my mom, but they're there when you need them. Or, as a perhaps closer example, installing a file manager app on an Android phone doesn't make the phone harder to use when you don't use the file manager, which is most of the time. Similarly, iCloud can provide this kind of "data liberation" file browser, without complicating the user experience the vast majority of the time. And when you do need it, it's there.

Of course, iCloud itself is probably a far bigger lock-in than apps — you can't access your data on Android, or Windows Phone 8, or Linux or Windows (only some iCloud APIs are available on Windows). This doesn't make sense unless you're a zealous Apple fan.

Most of the time, Apple gets away with, and in fact benefits from, not having to make least common denominator products that have to work well on all platforms, instead making products that work great on iOS and OS X. In general, that works great — I don't need Safari, or Apple's Mail app, on my Android or Linux devices, because they do not hold my data. Better make these apps as good as they can be. I can just as well use another browser or mail app. But when it comes to personal data, you can't hold the user hostage.

iCloud fails to deliver the most fundamental benefit of the cloud, which is letting you access your data from any device. Without that, iCloud is really a toy cloud.

The flip side is that iCloud's integration with the OS means that the entire state of the device can be backed up and restored. When I bought a new iPad, I chose to restore it from an iCloud backup of my old iPad, and everything was restored -- all apps, all data in all apps [1], all app settings, OS settings, all my email/contacts/calendar/Twitter/Facebook accounts (I had to type the passwords again for security), everything right down to the order of the app icons on the home screen and the folders in which I placed them, the wallpaper, the order of apps in the multitasking menu...

Whereas setting up a new PC takes hours. iPads are not quite as zero-setup as Chromebooks, but close.

Another advantage of integration is that apps seamlessly work together behind the scenes. For example, when a conflict occurs because a file is simultaneously modified on two devices, iCloud notifies the app of the conflict and lets it resolve it. This makes sense because the app is in the best position to resolve the conflict. Even if the best way to resolve a conflict is to ask the user, the app is in the best position to present this UI. Dropbox, on the other hand, is reduced to simply dumping both versions of the files and letting you sort it out.

So, iCloud is fascinating. It does some things far better than Dropbox and friends, but it does have its own equally serious downsides. It's not surprising that Apple built such a product.




[1] Apps that have their own backend also store the cookie on iCloud, so that your data in those apps is restored on a new device, while avoiding the walled garden of iCloud. Smart.

No comments:

Post a Comment