Killing Apps
An application program is a computer program designed to perform a group of coordinated functions, tasks, or activities for the benefit of the user.
Recently, I needed to create a presentation for work to introduce a lot of technical material to groups of people as efficiently as possible. Google Slides is the default choice — it’s where all our other presentations are saved. Easy, right? Unfortunately, Slides has some shortcomings. It doesn’t have the same “suggestion” mode that Google Docs has, so I paste long sections into Docs for collaboration. I had fairly complicated network diagrams created with d3’s force directed layout engine. Slides can’t embed HTML objects or even SVG, so I took screenshots which I uploaded. There were code samples to include, but copying and pasting from Atom (which, for various reasons, was my only option) doesn’t copy the highlighting. I converted the grammar file to the Pygments format, ran the code through the Pygments command line, piped into the clipboard, and then pasted.
I’d estimate that of the time spent on the presentation, more than 50% of it was lost to dealing with the friction between applications, and I don’t think this experience is unusual. It seems as though almost all large pieces of work I need to do cut across a number of distinct applications — either graphical or terminal — and a substantial proportion of my time is lost to hacking around deficiencies. It may be a case of missing features, features that are in one app and not another, or poor interoperability between data formats. That said, there are periods when I brace myself for this pain and it never materialises — barriers and limitations just seem to drop away and it feels as though I am in harmony with the computer. Sadly, moments such as this occur infrequently.
If I try and put a finger on what is different during the harmonious periods, I’d say it’s that the machine feels “malleable” — the software is not forcing me to jump through its hoops, it’s bending (or rather, easily being bent) to my will. This has lead me to believe that applications — loosely in the sense of the Wikipedia definition — cannot be a part of humane computing. They simply impede the easy creation of sophisticated content.
To me, the problem in the definition is the word “coordinated” — this is determined by the application author at design-time, rather than the end user at the moment of use. Many tasks require using a small set of functions across a number of applications and we work around this limitation either using “plumbing”, like communicating through the files or sockets, or on demand with drag and drop or copy and paste.
People are often stuck with mundane applications provided by others. This is problematic because they cannot look under the hood to understand how things work, or modify applications to suit their own needs.
— [Towards Making a Computer Tutor for Children of All Ages](— Towards Making a Computer Tutor for Children of All Ages)
Some might say that open-source can help, but I don’t think it’s sufficient in and of itself. Apps can be huge, monolithic bundles, with radically different internal architectures. If modules haven’t been explicitly designed to be reused, in all likelihood in a different language, it can be almost impossible to pull out anything of substance. I can take days or weeks to orient yourself around a large codebase. It’s a large up-front cost that’s rarely worth it.
The recent industry move to mobile and the Web has been a blessing and a curse. Mobile hides many low-level details such as the filesystem, and for a long time, iOS especially didn’t offer a good interoperability story, outside of a few system managed structures. The benefit is that individual apps are now a lot more lightweight, and recent additions like the share pane and iCloud drive mean there’s a backplane to bounce this data around. The Web is now a mature application delivery platform, but each document comes bundled with the entire application around it. In the case of my Google Slides situation, I couldn’t use a different app which had better diagram layout or code highlighting abilities at my base presentation. The upside is that a whole load of Web apps are exposing APIs, which can allow pretty sophisticated interoperability situations (RIP Yahoo Pipes), but it requires the API author to expose the full set of functionality you need (sadly, the Slides API doesn’t offer anything that could have helped with my needs above — it was the first thing I checked).
So what’s the solution? As with most things, Smalltalk was on top of this in the 70s:
Smalltalk has unlimited numbers of "Projects". Each one is a persistent environment that serves both as a place to make things and as a "page" of "desktop media".
There are no apps, only objects and any and all objects can be brought to any project which will preserve them over time. This avoids the stovepiping of apps. Dan Ingalls (in Fabrik) showed one UI and scheme to integrate the objects, and George Bosworth's PARTS system showed a similar but slightly different way. Also there is no "presentation app" in Etoys, just an object that allows projects to be put in any order — and there can many many such orderings all preserved — and there is an object that will move from one project to the next as you give your talk. "Builds", etc., are all done via Etoy scripts. This allows the full power of the system to be used for everything, including presentations. You can imagine how appalled we were by the appearance of Persuasion and PowerPoint, etc..
Smalltalk is, in many ways, the clearest expression of thinking beyond apps. You work with a set of rich, flexible objects which carry a huge amount of composable behaviour with them. In the case of something like my presentation, it would be completely natural in a Smalltalk environment to embed a computed graph or highlighted code, and they’d likely be live-editable and dynamic too.
However, I think some other environments also made fascinating stabs in this direction. One of the boldest efforts that I’m aware of is the Canon Cat — which brought data (predominantly text) front and centre, and task-based commands to operate on selections of that data. Another direction is a lineage through Oberon, through Rob Pike’s Help environment for Plan 9, and into its final form as the Acme editor. Emacs, the “great operating system, lacking only a decent editor”, has a promising approach in its composable modes. More recently, conversational UIs (either message or voice based) are unbundling apps in favour of lightweight, on-demand interactions. I plan to dive into all of those in more depth in future posts.
I believe that it’s possible to break out of the situation that we find ourselves in today, and that computing systems of the future will adapt more fluidly; systems which will enable users, and collaborative teams of users, to create digital material that’s more sophisticated with significantly less effort. However, given the state of the industry I’m not confident it will happen without substantial effort. If an effort is to be made, I think a good start is to take a look at interesting historical systems and imagine what they might look like today; to try and work our way out of a very narrow path that we really stumbled upon by mistake:
We thought we'd done away with both "operating systems" and with "apps" but we'd used the wrong wood in our stakes — the vampires came back in the 80s. One of the interesting misunderstandings was that Apple and then Microsoft didn't really understand the universal viewing mechanism (MVC) so they thought views with borders around them were "windows" and views without borders were part of "desktop publishing", but in fact all were the same. The Xerox Star confounded the problem by reverting to a single desktop and apps and missed the real media possibilities. They divided a unified media world into two regimes, neither of which are very good for end-users.