There's been a fundamental limitation of web applications that has bugged me for the longest time. I don't think I got a good idea of what it was until I started looking at my iOS devices, and realized it was the same thing that bugged me about them. There's no common filesystem on any of them.
This is something incredibly frustrating about the iOS: Each application has its own filesystem. Each application has its own way of listing your available documents. Each application has its own way of interfacing with external document storage systems (i.e., Dropbox, iCloud, etc...). It's possible to move documents between these filesystems: There's a shared photo repository, and a way for users to explicitly send documents from one application to another, but this functionality has to be enabled by the developers of both applications, has to be initiated by the user explicitly, and creates a copy of the document, which makes it a pain to keep track of which application currently has the "working" copy of your document.
This same thing has been showing up in web applications. The scarcity of fully featured web applications makes it difficult to see this effect clearly, but try editing a document with both Office 365 and Google Docs, and see how sane you stay.
This begs the question: why? Why limit your applications in this way?
In the case of web applications, it's a technical limitation. I'll get back to that, but first let's have a look at the iOS. There's an actual hierarchical filesystem under the hood. App developers must deal with paths and file pointers. Yet, there was a conscious decision on the part of iOS's designers to force application developers to build their own document management systems:
- There's no file management widget or application.
- There's no integration support for alternative hierarchical document management systems (e.g., Dropbox).
- Each application has (conceptually at least) its own independent filesystem.
So why? Why build each application into a walled garden?
I don't have a singular answer to this question, but this model actually has a number of very nice benefits.
Specialized vs Standardized Formats
There are a number of formats out there, many of which are (explicitly or implicitly) standardized. PDF, Jpeg, PNG, TIFF, MP3, Matroshka Video, Powerpoint, and Rich Text Format are all examples of formats for encoding a wide range of different document types. Even among standards, there is some duplication. Jpeg, PNG, and TIFF are all formats for encoding image data, but each has a slightly different set of benefits, each applicable to different types of image data.
If there's this much duplication among standard image formats, imagine how much duplication there is among non-standards. Let's have a look at some image formats used by the products of a single company: Adobe. Photoshop, Illustrator, and InDesign each manage image data, but have their own distinct formats.
Each application is designed to do something different. Photoshop is designed to edit raster data, Illustrator is designed to edit vector data, and InDesign is designed to manage page layouts. Because the applications are designed with different functionality in mind, each has a different notion of what an ideal layout is for the data being managed. If nothing else, different applications may find different metadata or index structures necessary on top of the core data.
My blog editor is a good example. At the heart of it, the editor just manages a list of rich text (HTML) files organized in a nice simple hierarchy. But then for each directory it has some metadata (the blog that the directory corresponds to), and for each text file it has some metadata (title, tags, categories, server options). There are inter-document relationships that it keeps track of (if a post has media/images/etc...), and it keeps itself synchronized with the blog posts already on the server. The core content (the HTML text file) is enhanced by application-specific metadata that allows the editor to effectively interact with the blog. It would be much harder to design such an application if the user was required to explicitly manage application state. Inter document relationships in particular are extremely difficult to manage (as anyone who has tried to move HTML from one website to another can attest to).
Meanwhile, providing an explicit export function (a'la iOS) forces the application developer to provide functionality for translating their own custom document format/metadata/etc... into a standardized format. This clearly demarcated boundary, if used properly, could actually increase compatibility between applications, while allowing each to maintain their own custom data formats appropriate for their own specific application.
This is running a little long, so I'll return next week with a few more benefits of the iOS document model.