Where’s an App for That?
Applying the UNIX philosophy to the modern desktop
The largest interface paradigm shift of the past 10 years was not multitouch or voice control or augmented reality — it was the introduction of the App.
I may have lost some of you already. “Apps have existed as long as personal computers,” you say. I disagree. Applications have existed forever; Apps are new.
Allow me to explain. An App, unlike a traditional application, is independent. It has no knowledge of or access to the general file system. Except for a few well-defined exceptions, it is unable to communicate with other Apps, or even know of their existence. It has no dependencies, and it can be uninstalled at any time without leaving anything behind. It is acquired and managed from a centralized location. All interactions with system processes are done in clearly-defined and limited ways. It does one thing and it does it well.
This is a very good thing. This pattern yields significantly enhanced security, usability, and simplicity for both the user and the developer. Apps that are independent can be reasoned about independently.
This is a new idea when it is applied to GUI software, but it’s actually based on a rather old philosophy.
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
This is considered by many to be the first point of the UNIX philosophy. If you have ever used the Mac command line, you have reaped the benefits of 40 years worth of good UNIX design. This same design should apply to modern App design as well.
The Problem
Apps come with their own usability limitations, especially when it comes to Inter-App Communication. While separate and independent Apps are easy to manage, they do not necessarily map to our mental model. Take these sentences for example:
- “Brighten up the banner image on the website”
- “Create a reminder to book a hotel 2 weeks before the flight”
- “Set my Twitter profile picture to my Facebook profile picture”
- “Post directions to the picnic to Slack”
Each of these examples is a fairly simple thought, but it requires at least two separate Apps or websites and an intermediary tool to accomplish.
- An FTP client, a photo editor, and 2 temporary files
- A calendar App, a reminders App, and some mental date math
- Twitter, Facebook, and a temporary file
- A maps website, Slack, and the clipboard
This App-hopping seems reasonable because we have done to it for so long. But it is actually a very unnatural and inelegant action. Transferring data between Apps is slow, tiresome, and prone to error. This is especially true when transferring complex data types such as rich text.
Because switching between Apps is such a pain, we suddenly find ourselves with bloated Apps that try to do everything. Text editors have built-in FTP clients, document editors get photo editing capabilities, and calendars all have embedded mapping tools. This is why you’ll find 30 different ways to crop an image on your computer, and they all work differently (do you drag the image or the cropping frame?).
However, this too is a problem that was solved a long time ago. The second point of the UNIX philosophy is this:
Expect the output of every program to become the input to another, as yet unknown, program.
From a design perspective, the first point is dependent upon the second. If it’s not trivial to transfer data between programs, then everything, by necessity, becomes bloated.
The Current Solutions
Macs have a few built in tools that try to simplify this sharing. The older, more flexible tool is called Services. The newer, simpler tool is Share Sheets. Unfortunately, they both suffer from the same problem: there are just too many things you can do with one piece of data.
To demonstrate this, imagine we have an image file. Let’s make a list all of the possible things that someone could want to do with it:
View it, share it on social media, set it as a social media profile picture, email it, crop it, resize it, add a filter, edit it with a photo editor, put it into a slideshow, put it into a movie, put it into a document, send it in a chat app, set it as the desktop background, set it as the system profile image, add it to an existing note in a notes app, create a new note in a notes app, move it, copy it to a new location, delete it, zip it, convert it do a different format, check the file size, check the metadata, edit the metadata, rename it, restore it to a previous version, search the internet for it, upload it to a photo sharing site, copy the file to the clipboard, copy the image data to the clipboard, merge it with other files in a PDF, merge it with other files as an animated GIF, split it into separate files if it is an animated GIF, etc…
Right now, all of those tasks are possible. Some of these tasks need to be done from Finder, some need to be done by opening the file in an App, and some require uploading the file to a webpage. Many require either use of the clipboard or drag & drop. I personally prefer to do many of these tasks from the command line. Everything is all over the place. We accept this because that’s how it’s always been, but it’s a terribly inelegant system.
But if we wanted to unify, we couldn’t possibly add all of these things to the unordered lists of the Services menu or the Share Sheet — it would be huge and impossible to navigate. So what can we do?
The Proposed Solution
To solve these design problems, I always ask the same question: How do humans do it when computers aren’t involved? We use language. Simple, unambiguous language.
What if you could select a file in Finder and just type “convert this to JPEG” or “tweet this”. You could use this to combine multiple tasks, such as “crop this, then set it as my Facebook profile picture”. Or you could forget about selecting the file in Finder altogether: how about “set my desktop background to bliss.jpg” or “email my last Instagram photo to Mom”.
A natural language utility like this allows for flexibility that GUI interfaces like the Share Sheet can only dream of, and simplicity that no command line interface could ever achieve. Because Apps can be so easily composed, they can stay small, isolated, specialized, and well-designed. The user will not need to learn any commands, menus, or tools — they can simply type what they need to do. It brings the UNIX philosophy to the modern age.
The Shameless Plug
I have spent the last few years working on a project called Lacona, which I believe takes the first steps toward solving this problem. I imagine a time where, through the power of its custom commands, users can interact with all of their data, Apps, and websites using plain language. Simple, quick, elegant language.
You can demo a small sample of its power in your browser on lacona.io. Lacona is currently seeking funding on Kickstarter.
Even if you don’t want to get involved with Lacona, I would encourage you to take these ideas to heart. Do not be content with the existing solutions to a problem —always strive to seek out better ones.
