Filesystems, Application Semantics, and Walled Gardens (Part 2)

Last week, I started talking about some advantages of the iOS data model -- specifically its lack of a common filesystem.  I started by talking about the issue from a file format/metadata perspective.  Today, I look at three more benefits: Security, Presentation, and the Data Cloud


Perhaps the strongest argument for giving each application a walled garden is security.  As far back as I can remember, security has been a huge usability problem.  In this case, the problem being attacked is authorization of code: How can a user safely grant an application the right to access a user's secure data?  

The traditional way has been to ask the user (i.e., "Can 'Irate Avians' access your contacts?").  Unfortunately, questions like this require the user to think.  The user has to sit there and ask themselves questions like

"Why is Irate Avians asking me for my address book?"  

"Do I trust the code of Irate Avians to not do anything I wouldn't want with my address book?"

Odds are that a typical user won't have the background to be able to answer questions like this by themselves.  Worse still, because most code running on a typical user's device(s) is perfectly trustworthy, so generally, the answer to these questions is yes and the user learns that it's ok to not think about these questions.  

So how do you get the user to really think about these questions?  

Quite simply, you don't. 

Instead of having the user try to figure out the application's intent, you design your user interface so that the user's intent is clear.  

The walled garden model forces a user to push state from one application to another, rather than the filesystem based model where each application pulls state from the filesystem.  In both cases, the application sit's between the user's intent and the filesystem.  

However, in one case, a (potentially) untrusted application is acting on its own, while in the other a trusted application (one that already has access to the data) is indicating that it wishes to extend that trust to another application.  In the latter case, the user (through the trusted application) has explicitly given permission for their data to be accessed.


Different types of documents can be presented in different ways.  For code, a nice hierarchical, alphabetical listing is often best.  For photos, you want thumbnails.  In short, the nature of the browser being used depends heavily on the type of work you're doing.  We're seeing this phenomenon with apps like iPhoto, Front Row, Eclipse and Xcode, each of which has a custom file browser (some of which don't even correspond to the underlying filesystem).  

There's not really much to this point, just that different types of data need to be organized in different ways, and the entity best suited to managing this organization is the application that created/is responsible for managing the data.

The Data Cloud

On a related note, some data doesn't fit into a neat little document (or similarly, into the filesystem) model.  Sometimes you want to keep different datatypes independent (i.e., The giant mess of files in a website).  Sometimes you have data that can't be structured exactly into a hierarchical model (i.e., email, or music).  

A perfect example of data that doesn't fit into the document model is social network data (and graph data in general).  In this type of data model, you have lots of little nuggets of information, which can be sorted, organized, collected, distributed, and aggregated in any number of ways.  There's not generally a single concept that you can group each comment, post, or message into.  Sure, you can put this data into a file, but more likely than not, all of this data will go into a single file (or equivalently, into a single grouping of files).

For this type of data, the walled garden is great.  You can present the user with an interface ideally suited to organizing, aggregating, and displaying all of these little nuggets of information.  Since such applications tend to be decentralized, you can easily interface with networked components as well.  You don't need to forcibly coerce this application-specific data presentation model into the filessytem model that everything else expects.


So there you have it.  Four particularly nice aspects of the iOS walled garden application state model.  Next week, I'll talk about how this all connects to web applications.