A to do list app where the behavior of the to dos can be programmed by the user. I built it to demonstrate how it's possible to use the Afterburner rendering: altering an app by hacking its UI to make an app end-user programmable. This technique requires very little customization of the base app and so it is quick and easy to integrate.

https://youtu.be/WI0VBip9ikw

What can an afterburner to do do?

When the user creates a to do, it starts as just a good old to do that has text and can be checked off. However, the user can also attach a script. This script can:

• Generate HTML that is rendered in place of the to do.
• Generate HTML that is rendered in place of another DOM element in the page.
• Perform DOM operations.
• Mutate the data in the to do (and in other to dos).

What can afterburner rendering be used for in a to do app?

• Show a sun if it’s sunny and suggest a walk, or a cloud if it’s cloudy and suggest reading a book. (By doing a fetch to a weather API and adjusting the text on the to do in response.)
• Give all completed to dos a green background. (By using a DOM operation to modify the rendered output of the completed to dos.)
• Render a custom UI to show a button that, when clicked, chooses and displays a random fun activity. (By rendering a UI in HTML in place of the to do.)
• Show a persisted text area for odd notes. (By rendering HTML in place of another part of the page.)

What works well?

It’s very powerful to unite dynamic behavior, an object that lives in user space and a rendering surface. I got this idea from Ink and Switch’s brilliant essay about end-user programming. Putting scripts on to dos gives a tangible, memorable place to store logic. Very often, the logic operates on the to do itself and so lives alongside the data it operates on, making it even clearer. And the object’s visual representation is a perfect piece of UI to alter or replace. The app also gets some Transferrable mechanics in game design and in software design that the user can learn for to dos (re-ordering, naming, deleting) and apply to dynamic behavior. And, though only to dos are programmable in Afterburner To Dos, you could imagine making other types of object programmable - like lists or groups.

Custom rendered output is very low effort. The user can change a color or show some data with very little code, and the addition co-exists peacefully with the base app.

The user can change other parts of the official UI. This, too, is very powerful and surprisingly low effort. It took just a few lines of code to put a persisted notes area at the top of the page. It’s also very easy to layer in embellishments to the base UI. Imagine hacking your calendar app so that the day of a deadline has a red background.

The user gets an intra-api. When the script attached to a to do runs, it gets passed the to do. It’s like the world’s most lightweight API. They get the real data the base app uses in the context in which it’s relevant.

The base app can be almost completely ignorant of the afterburner rendering. There are surprisingly few touch points between the to do code and the code that supports the afterburner rendering.