Today’s software apps are like appliances: we can only use the capabilities exactly as programmed by the developer. What if we, and all computer users, could reach in and modify our favorite apps? Or even create new apps on the fly according to our needs in the moment?
This is end-user programming, a vision for empowered computing pursued by bright-eyed computer science visionaries. Its rich history reaches back to the 1960s with programming environments like Smalltalk and Logo. Notable successes since then include Unix, the spreadsheet, Hypercard, and HTML. And today, newcomers like Zapier, Coda, and Siri Shortcuts are trying their own approaches to automation and dynamic modeling.
But despite forty years of commercial products, open source, and deep academic work, we have yet to reach an end-user programming utopia. In fact, the opposite: today our computing devices are less programmable and less customizable than ever before.
This article tackles the question of why this is so. We'll start by describing three qualities we think are important for end-user programming: embodiment, living systems, and in-place toolchains. We’ll survey the prior art and try to illuminate what has made this problem so immensely difficult. Then we will document the experiments we’ve done at the Ink & Switch research lab in adding automation and customization capabilities to a digital sketchbook application.
We believe in a computing future where programming is within the grasp of everyone and hope this article can inspire and challenge our industry. We welcome your feedback: @inkandswitch or hello@inkandswitch.com
In their computing lives, power users often want simple extensibility. For example: adding download capability to Instagram, setting up windows for a live-stream session, generating recipes and shopping lists for a home kitchen inventory, or automatically keeping timestamp-named backups of Illustrator documents.
Desktop programs, web apps, and smartphone apps are to various degrees like appliances with a hermetic seal to keep users out of their interior. If there is not already a button for a given function, the only option for users is to petition the developer.
Some tools have a history of extensibility, such as vim and emacs which allow the user to record and replay macros, configure keybindings, and write plugins that run within the editor context. But most apps offer no such capabilities — and if they do, it’s usually by exposing programmatic API made for developers.
Modifying your own software is part of the rallying cry of FOSS. We love open source and everything it stands for. But in practice, the effort needed to rebuild an application from source doesn’t lend itself to the casual access we’re seeking here.
There’s an abyss to cross between using an app and modifying it with code by calling APIs. The user has to switch to a whole other paradigm including setting up a development environment. Consequently, few users take the step from using a tool to customizing or making their own tools.
At Ink & Switch, we believe that software should be extensible in an easy, everyday manner. We believe users want to automate, customize, or even make their own tools without much ceremony. History offers us some great examples.
Unix pipes allows the user to chain together simple commands to make an ad-hoc program.