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.

My main interest lays in the space of no/low/future-of coding tools, and end-user programming. I believe that there's a ton of untapped potential in computing, and that a lot of it is limited by (broadly understood) interfaces.

  • 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 in the Programmable Ink thread together with Marcel Goethals and Ivan Reese. It is a spiritual continuation of our work on End-User Programming (with an essay here), and the Inkbase project.