End-User Programming

We also had fun in the space itself, one of the experiments with biggest impact-to-implementation-difficulty ratio was a styling block, echoing how customisation was done in the MySpace times by injecting snippets of global CSS. Task-Oriented End-User Programming at its finest. Since MakeSpace is built on top of CRDT, these changes propagate to all users in a given space, which allowed us to live-code the UI from within MakeSpace itself, or have each users' notes styled differently (by adding a .user-${username} CSS class so it can be targeted with a custom selector).

We also started ramping up to another project in the End-User Programming track; there even was a job posting, which you could see, if you follow me on Twitter.

As a small aside (slash ramble), "programming" is in quotes, because I really don't like that word for describing this sort of work. I have some early illegible thoughts about this in End-User Programming vs Programming note, but the gist of it is that what I've been after in this research track is "programming" as a tool for understanding, and working with, dynamic systems same way as a numerals and mathematical notation are tools for working with mathematical ideas. It now seems to me that a lot of Future of Coding work (including most of my own!), is about making lives of "expert symbol manipulators" easier which is definitely worthwhile but this year I started to understand that there's a lot of value in making "working with dynamic systems" accessible to everyone, and that might need another approach than iterating from where we are right now.

  • block-based End-User Programming systems often feel this way, they often remove possibility for any syntax errors, by imposing strict rigidity on how the program is created
  • direct manipulation usually involves a lot of complex code - usually in forms of two-directional bindings, translating between different data representations, etc. - this makes End-User Programming in a self-hosted system much harder - even if the user can "pop up the hood", the machinery inside will be very complex
  • I'm curious if one solution would be that combination of End-User Programming and self-hosted system doesn't point at indirect manipulation - if the user can "speak" closer to the "machine", to the internal language in which the software is made, then maybe sacrificing direct manipulation for easier moldability makes sense?
  • one take at this is programming as a profession vs end-user programming as moldability of existing systems, with this lens:
    • not everyone should be able to make a living from programming, but:
    • everyone should be able to nudge their tools into the right direction if needed though
  • gradual enhancement seems like important idea for End-User Programming - allowing users to change small pieces of functionality without feeling overwhelmed, and slowly "luring them in"
  • programming is often introduced to beginners (and end-users in End-User Programming) as "creating a recipe for something" - what is hard about programming is that computers can't figure stuff out on their own - you have to specify every single step, every possible failure mode, and what to do then - which makes the metaphor break apart because if you give someone a recipe for a cake, you don't have to specify what to do if they have no sugar in the house

Crosscut is a research project developed at Ink&Switch together with Marcel Goethals and Ivan Reese a spiritual continuation of our work on End-User Programming (with an essay here), and the Inkbase project.

Szymon Kaliski © 2022