A rather interesting post by Rob Foster where he observes that no one seems to know how to use the file system, besides the Documents folder and the Desktop, and so arguably, the elimination of the visual file system in favor of “apps and their stuff” in the iPhone/iPad was a good thing (link via Daring Fireball).
As a developer, I am not a big fan of the direction Apple is going with the new locked down OS and I completely echo Alex Payne’s sentiment where he talks about the iPad and the Tinkerer’s sunset:
The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, Iâ€™d never be a programmer today. Iâ€™d never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write. I wouldnâ€™t have been able to fire up ResEdit and edit out the Mac startup sound so I could tinker on the computer at all hours without waking my parents. The iPad may be a boon to traditional eduction, insofar as it allows for multimedia textbooks and such, but in its current form, itâ€™s a detriment to the sort of hacker culture that has propelled the digital economy.
However that said, there does seem to be some grain of truth to the idea that I dont really know what half the folders in my file system are. Or, well, I may know theoretically what they are meant for but I dont ever use them myself so do I really need the clutter when I open Finder or Windows Explorer. For example, a while back I went from writing different text files at different locations for different reasons to writing them all in EverNote and tagging them appropriately. I dont care where EverNote is placing my files but I know to find anything I just need to launch it and search either on the text or tag.
I think we need to differentiate the concepts of the file system and the visual file system browser though. An available file system is essential for applications to write sharable data even if as an end user I may never need to see those locations. The problem of the iPad/iPhone OS is that the data produced by an application is not really sharable between applications, except for data produced by (some of) Apple’s own applications which are available as frameworks. Some developers have managed to enable inter application communication using custom URL registrations like Innerfence and their Credit Card Terminal application, but that definitely is a hack. In the linked post, the author mentions:
By registering to handle a URL scheme, an iPhone app becomes a de facto web app, subject to many of the nasty attacks that work on the web. Apps implementing this scheme must be careful to validate any parameters they get from the URL lest they be vulnerable to old friends like SQL injection. Another one to be careful of is unsolicited response attacks.
So locking down the OS seems to make my data even more vulnerable to being compromised since an application developer could have a bug in this code. The available file system enables inter application in a much better way in the Android OS, where an application can write to a location and then trigger another application passing it a reference to that location. That’s how Photoshop for Android allows developers to leverage it as an image editor in their own applications. This seems to be the exact translation of the Unix Philosophy in the mobile space and the philosophy has been validated in the Unix space over time already.
So my points are:
- The file system itself is not an outdated concept. Applications should still have a file system to write sharable data to.
- The visual file system showing references to rarely used locations or locations only needed by developers can be evolved to one that doesn’t show those to regular users and only shows items relevant to them (my photos, my videos, etc).
Even more, such a mechanism that could be easily evolved to do this is already available in Windows and Mac OS’s, which involves preceding the file’s name with a period. Such files are not visible to the end user but a developer can enable the “show all” behavior.
[Update] David Shoemaker also talks about Death to filesystems and notes that the Google Chrome OS is also going the same way with no filesystem the user can browse (ink via Karl’s blog), though in that case, the data is all stored on the cloud and can be made accessible via the web service’s APIs. Another aspect of that that would be really cool is that chrome browser extensions could even add custom actions to such files: For example, Picnic could create a browser extension that adds menu items to the browser’s chrome when the user is on Picasa or a new photo service and then when that is clicked on, can pull the data from the Picasa using the web service.