My life situation has changed somewhat since I started writing Utopian Dreams. Unfortunately, this has meant less and less blog-writing time. So I’m going on an indefinite hiatus. There are still many things I hope to write about, and I may publish occasional posts, but it won’t be anywhere close to the current pace for a while. I suggest subscribing if you want to be notified when I return.
TLDR: Computer operating systems should adopt a smartphone-style approach to file management, with each application managing its own files in a sandbox. This principle can be extended to provide first-class support for databases and structured data.
Prerequisites: None
Computer data can be roughly split into two broad categories: applications (apps) and files. This distinction is a bit fake — the act of programming a computer typically involves writing a file which is then treated as an app, for instance. And likewise, it’s possible to send apps over a network as though they were files like any other.
But the distinction is a useful one. Apps are intended to be used. Files are intended to be read and often modified.
In the early days of computing the abstraction of files was created to understand what was happening on the computer. Workers were familiar with physical documents that could be placed on a desktop or in a filing cabinet, and so computer programmers established a skeuomorphism. Digital documents were said to be similarly localized to a particular place on the computer, where the user could access them like a physical piece of paper in a file cabinet. Users can move files from one place to another or destroy them, just like they might do with a physical document.
The problem with this is that apps use files, and if a user goes and moves, edits, or deletes a file that an app was relying on, it almost always breaks the app. Even simple app-file relationships, such as when a text-editor is modifying a text-file, result in weird behavior if the user moves or changes the text file while it’s in the process of being edited.
The open-access of files that an app depends on doesn’t just introduce unintuitive behavior for app users, but it adds security vulnerabilities and makes computer systems less stable. But, thankfully, the software industry eventually came to understand that managing files in an extremely unrestricted fashion wasn’t wise. And in the 2000s when the next big jump in operating systems technology happened, the engineers were ready…
Smartphone Sandbox Superiority
Smartphone operating systems, such as those found on iPhones and Android devices, are set up differently than desktop operating systems. Instead of allowing all apps on the device to have access to (roughly) all files on the system, smartphone operating systems implement a sandboxing approach, where each app is responsible for managing its own files within its own designated space. This means that apps generally can’t interfere with each other's files or data, greatly improving stability and security.
The sandboxing approach means that if the user mistakenly installs a malicious app, such as spyware or a virus, that app can’t get access to internal files in other applications, such as photos, tax records, et cetera. It also means that app developers don’t need to spend as much time handling edge-cases like the text file that’s being edited being unexpectedly deleted. But the benefits to sandboxing don’t stop there.
By putting all the files that an app uses in the same place, apps can be much more effectively quarantined and measured. No more hidden files sequestered in dark corners of the machine. No more confusion about how large an application is. No more difficulty in uninstalling a piece of software. Truly, sandboxing is bliss compared to how file management works on desktop operating systems.
Extending Encapsulation
While the smartphone-style sandboxing approach to file management is a major improvement over traditional desktop approaches, it can be taken even further. Both iOS and Android still use file-systems, though they often tuck them away as an awkward basement-realm where browser downloads, photos, and other random files are stored.
The issue here is that sometimes multiple applications want to manage the same file. For instance, we might want to take a photo using a camera app, then edit it in Photoshop, then attach it to an email. Without having an open-access file system, how would that be possible?
Easy! Let apps talk directly with each other to negotiate for files and other data.
To follow-through on satisfying the encapsulation principle, I claim that each file on a computer should be owned by exactly one app. In this paradigm, when one app wants to edit another app’s file, it must make a local copy. To prevent proliferation of files, the editor might request that the source delete the original and cary a read-only pointer to the new file. Having one app read data from another isn’t so bad, as long as it’s clear to everyone (both app programmers and the user) which app is the owner and that the owner app might change or delete the file.
While one might think that tucking each (non-app) file into a private space managed by a single app would ruin things like the ability to organize and search for files, I claim the opposite. As long as the operating system has good protocols for apps to register what files are publicly visible, it should be straightforward to have a search app keep track of all public files on the machine. And there’s no reason there can’t be album apps that allow for clever arrangements of the files they own and manage.
Strongly Typed Data
In a world where files are always owned by an application, the metaphor of “documents” stops pulling nearly as much weight. Sometimes it makes sense to bundle data into a document, but in many cases it makes more sense for software to have a more structured, efficient representation: a database.
Databases allow for fast storage and retrieval of data that’s custom-built for the needs of a particular application. Perhaps a contact-book wants to store phone numbers in a particular format… not a problem! Or maybe a slideshow has an image used in ten different places. If set up correctly, the slideshow’s underlying database will allow the user to avoid duplicating that image, and may even allow for editing the image in all ten locations simultaneously. The checks that databases perform on their data to ensure specific properties are a primitive version of dependently typed data.
As I see it, a next-level operating system, instead of providing easy abstractions for files, should provide easy abstractions for custom databases. Instead of simply allowing documents to be read between apps, with the right protocols it seems feasible to allow for partial reading of foreign databases (i.e. those owned by other apps), even when those databases are structured differently. It seems easy to mess this up, resulting in a scattering of isolated apps that can’t share data, but it also seems possible to reach for utopia and get computer systems that are simultaneously more robust, secure, and intuitive.
Utopian File Management
In my conception of Utopia, computers manage “files” by having a central collection of applications managed by an operating system. Each app has a custom database that can easily expose whatever data it wants, for other apps to read. Strong protocols enforced by the operating system helps apps speak the same language, allowing data to be searched and moved relatively easily.
Whenever two Utopian apps want to communicate, they check with the user for permission. This is usually a case-by-case thing, where the user supervises which data is shared, but in some cases users can issue blanket-permissions that allow for rich communication without needing the user to okay each message.
Apps register an expected memory footprint with the operating system when they’re installed, and must request permission when they extend this footprint. This prevents bloatware, and helps to ensure software doesn’t unexpectedly run out of memory while it’s running in Utopia.
As an example of how these principles improve the user experience, consider how Copy-Paste works in Utopia. Instead of being an operating-system level tool, users install a clipboard app on their computers that listens for various key-commands and/or gestures. When something is copied to the clipboard, the clipboard app gets to read the relevant data from the source app, and create a copy of whatever was selected. The user can then explicitly go to the clipboard app and see what was copied, if they choose to. By splitting the clipboard out from the operating system and having it behave using standard app-to-app communication channels, different users can pick the clipboard software that works best for them, allowing for more customization.