See also the previous swap.
- Gordon Brander works on a tool for imagination, and recently wrote about composability with other tools.
- Rosano works on various Zero Data apps like Hyperdraft and Launchlet.
With one-off API integrations, every app must be connected with every other app in both directions. The number of integrations required for interoperability is equal to the maximal number of edges in a directed graph, or n * (n-1). Adding one more app, for a total of 6, means going from 20 to 30 integrations. 10 apps is 90 integrations! […] Imagine any of these apps needs to change its API. Now every single other app in the network needs to change its integration code. Everyone in the network has to coordinate, because everyone in the network has to implement everything.
The protocol acts as a hub in the network, cutting the number of connections necessary for full interoperability from n * (n - 1), to just n. The number of integrations scales 1:1 with the number of apps. […] none of these apps have to know anything about each other. All they need to know is the protocol. This makes the set of possible workflows between apps an open set. […] Files make interoperability the default […] Files allow interoperability to emerge retroactively. New apps can come along and implement the file formats of other popular apps, uplifting their file format into a de facto protocol. This has happened many times, from .doc, to .rtf, to .psd. Competing products are able to get off the ground by interoperating with incumbents. New workflows can be created permissionlessly.
Protocols produce creative combinatorial explosions […] When you have a universal API for composition each additional tool increases the number of possible workflow combinations by n * (n - 1). […] That’s our directional graph equation again, but this time the network effect is on our side. The more tools, the more possibilities. […] If a tool supports composition with other tools, it supports open-ended evolution. At that point, all of the other ways in which it might be terrible become incidental, because an evolutionary system will always be more expressive than one that isn’t. Nothing else can widen the potential of creative tools as rapidly as composability with other tools. It’s not even close.
The power of files comes from them being powerful nouns. They are temporary holding blocks that are used as a form of exchange between applications. A range of apps can edit a single file in a single location. On mobile, the primary way to really use files is to “Share” between apps. This demotes files from a powerful abstract noun into a lackluster narrow verb. […] For example, I can import a text file into the Notes app but it’s really nothing more than a glorified copy/paste, not an editing of an object in place. This makes a cloud storage service like DropBox nearly useless as I’m not editing “the thing” but a copy of the thing. I need to save it back out to Dropbox if I want anyone else to see my changes. That’s vastly underutilizing the power of the abstraction that comes from files.
This isn’t some feeble political statement to liberate my data from a company. I want files to liberate my data from my own apps and create an ML explosion of activity! Files are at some level a hack, I get that, there are limits but they are an extremely useful and flexible hack. Like the QWERTY keyboard, they are “good enough” for most tasks. Files encapsulate a ‘chunk’ of your work and allow that chunk to be seen, moved, acted on, and accessed by multiple people and more importantly external 3rd party processes.
What if you could move data items, with views provided by their hosting applications, around system and application views? What if we could bring together a series of things that all relate, even if they are of different types, and are from different apps or windows? What if you could browse your things in one fluid interface, without regard for their differing data types?
When you pull an item into some other place, it is still rendered by its hosting application. Hosting applications provide the view components for rendering data items in different situations or sizes. It can be thought of much like a widget in today’s operating systems: the system defines what the data item is and what size it should take up, then it relies on the data item’s hosting application to provide the view component that renders it.
To receive updates, watch this space or subscribe to the mailing list: