A Philosophy of Tools For Novices

I have just released a tool for making Twitterbots, called Cheap Bots, Done Quick. I feel pretty pleased with it, and it provides a good context for talking about my approach for making tools for novices (a disclaimer - most of the heavy lifting was done by Kate Compton, in developing the Tracery syntax and library. I don't speak for her, though). First up, I should say that this doesn't apply to all tools, but I do think it's useful if you're making a tool that aims to democratize some aspect of creation. Please don't remake Unity along these principles.

The main principle is that the tool should be as simple as possible when first approached. This means, of course, removing all unnecessary options and making as many decisions as you can for the user. But it goes deeper - it also means giving them a simple, consistent (but still powerful) conceptual metaphor to bind everything to. Take the example of Twine - the conceptual stuff you need to onboard is the concept of nodes, the concept of links, and a few details like stories always starting at Start. These are reified visually, making these organizing concepts the most prominent things - this helps immensely in making these concepts comprehensible quickly to naive users. With CBDQ, the important concepts are that of random selection from a list, and #hash markers# expanding out to the matching symbols. There's no nice visual representation, but I do the next best thing by having a simple example to start from that implicitly explains these two rules (plus the fiddly one about starting from origin).

There's more advanced functionality in both of these tools. Tracery has modifiers and variables, Twine has macros. But in both cases (less so with Twine 2 than Twine 1) these extensions are awkward and kinda hidden away. More advanced users will use them and find them, but by that point they're committed to this tool, and they can endure awkwardness and unintuitive logic. This obviously connects to Worse Is Better, but I think an even more powerful perspective is Olia Lialina's Turing Complete User. People will always find their own uses for things if you give them sufficiently powerful tools, and they will apply ingenuity to that purpose. Simplify the tools too radically, bury them in slick UI that doesn't interoperate with anything else - and there's no purchase for them to dig into. I've made a series of scripts that take Twine source files and mangles them and produces C# equivalents that can run in Unity. I've used Sublime Text's extensive Find and Replace features to take corpuses and convert them to JSON representation for feeding into CBDQ. Users find their own way of working with things, if you just give them enough points of friction to attach to.

There's a way of looking at this that considers this game design - designing the learning curve that users of a tool can go on. It should start out as accessible as possible - you should be able to dive in immediately and start seeing results. But the ideal learning curve is not necessarily low and shallow - there's satisfaction to be found progressing up, learning how to manipulate probabilities first one way, then another. Refining your results, learning the grain of the material - and then discovering the advanced features like complicated variable tracking macros or symbol expansion or automatic pluralizing. None of which is hidden, per se - in CBDQ's case, it's clearly linked from the introductory text on the same page you're working in. But reading the instructions is high-level play, if the example is enough to get you working. Unnecessary complication is bad - but given a tradeoff of a slight increase in complexity at the start, or a large increase in awkwardness for a pro feature, the answer is obvious for me.

And then there's always the escape valve that's also linked up there at the top. If you want to self-host, if you want to take the bot you've worked on and add features the tool doesn't support - then you can, and you can start from where you were at with CBDQ (uh, once you get everything working reliably, which is a non-trivial feat of sys-adminning. Which is why CBDQ exists at all). Ultimately the aim of CBDQ is to make bot-making accessible for everyone - for people who just want to quickly tinker and will only make a single thing, for people who will stay with the tool and start to learn all it's quirks and corners, for people who will soon outgrow it and start out on their own path of making beautiful generative art and poetry.