‘Hybrid Writing for Conversational Interfaces’ workshop

On May 24 of this year, Niels ’t Hooft and myself ran a workshop titled ‘Hybrid Writing for Conversational Interfaces’ at TU Delft. Our aim was twofold: teach students about writing characters and dialog, and teach them how to prototype chat interfaces.

We spent a day with roughly thirty industrial design students alternating between bits of theory, writing exercises, instructions on how to use Twine (our prototyping tool of choice) and closed out with a small project and a show and tell.

I was very pleased to see prototypes with quite a high level of complexity and sophistication at the end of the day. And throughout, I could tell students were enjoying themselves writing and building interactive conversations.

Here’s a rough outline of how the workshop was structured.

  1. After briefly introducing ourselves, Niels presented a mini-lecture on interactive fiction. A highlight for me was a two-by-two of the ways in which fiction and software can intersect.

Four types of software-fiction hybrids

  1. I then took over and did a show and tell of the absolute basics of using Twine. Things like creating passages, linking them, creating branches and testing and publishing your story.
  2. The first exercise after this was for students to take what they just learned about Twine and try to create a very simple interactive story.
  3. After a coffee break, Niels then presented his second mini-lecture on the very basics of writing. With a particular focus on writing characters and dialog. This included a handy cheatsheet for things to consider while writing.

A cheatsheet for writing dialog

  1. In our second exercise students worked in pairs. They first each created a character, which they then described to each other. They then first planned out the structure of an encounter between these two characters. And finally they collaboratively wrote the dialogue for this encounter. They were required to stick to Hollywood formatting. Niels and I then did a reading of a few (to great amusement of all present) to close out the morning section of the workshop.
  2. After lunch Niels presented his third and final mini-lecture of the day, on conversational interfaces, relying heavily on the great work of our friend Alper in his book on the subject.
  3. I then took over for the second show and tell. Here we ramped up the challenge and introduced the Twine Texting Project – a framework for prototyping conversational interfaces in Twine. On GitHub, you can find the starter file I had prepared for this section.
  4. The third and final exercise of the day was for students to take what they learned about writing dialog, and prototyping chat interfaces, and to build an interactive prototype of a conversational interface or interactive fiction in chat format. They could either build off of the dialog they have created in the previous exercise, or start from scratch.
  5. We finished the day with demos, where put the Twine story on the big screen and as a group chose what options to select. After each demo the creator would open up the Twine file and walk us through how they had built it. It was pretty cool to see how many students had put what they had learned to very creative uses.

Reflecting on the workshop afterwards, we felt the structure was nicely balanced between theory and practice. The difficulty level was such that students did learn some new things which they could incorporate into future projects, but still built on skills they had already acquired. The choice for Twine worked out well too since it is highly accessible. Non-technical students managed to create something interactive, and more advanced students could apply what they knew about code to produce more sophisticated prototypes.

For future workshops we did feel we could improve on building a bridge between the writing for interactive fiction and writing for conversational interfaces of software products and services. This would require some adaptation of the mini lectures and a slightly different emphasis in the exercises. The key would be to have students imagine existing products and services as characters, and to then write dialog for interactions and prototype them. For a future iteration of the workshop, this would be worth exploring further.

Many thanks to Ianus Keller for inviting us to teach this workshop at IDE Academy.

Writing for conversational user interfaces

Last year at Hubbub we worked on two projects featuring a conversational user interface. I thought I would share a few notes on how we did the writing for them. Because for conversational user interfaces a large part of the design is in the writing.

At the moment, there aren’t really that many tools well suited for doing this. Twine comes to mind but it is really more focused on publishing as opposed to authoring. So while we were working on these projects we just grabbed whatever we were familiar with and felt would get the job done.

I actually think there is an opportunity here. If this conversational ui thing takes off designers would benefit a lot from better tools to sketch and prototype them. After all this is the only way to figure out if a conversational user interface is suitable for a particular project. In the words of Bill Buxton:

“Everything is best for something and worst for something else.”

Okay so below are my notes. The two projects are KOKORO (a codename) and Free Birds. We have yet to publish extensively on both, so a quick description is in order.

KOKORO is a digital coach for teenagers to help them manage and improve their mental health. It is currently a prototype mobile web app not publicly available. (The engine we built to drive it is available on GitHub, though.)

Free Birds (Vrije Vogels in Dutch) is a game about civil liberties for families visiting a war and resistance museum in the Netherlands. It is a location-based iOS app currently available on the Dutch app store and playable in Airborne Museum Hartenstein in Oosterbeek.

For KOKORO we used Gingko to write the conversation branches. This is good enough for a prototype but it becomes unwieldy at scale. And anyway you don’t want to be limited to a tree structure. You want to at least be able to loop back to a parent branch, something that isn’t supported by Gingko. And maybe you don’t want to use the branching pattern at all.

Free Birds’s story has a very linear structure. So in this case we just wrote our conversations in Quip with some basic rules for formatting, not unlike a screenplay.

In Free Birds player choices ‘colour’ the events that come immediately after, but the path stays the same.

This approach was inspired by the Walking Dead games. Those are super clever at giving players a sense of agency without the need for sprawling story trees. I remember seeing the creators present this strategy at PRACTICE and something clicked for me. The important point is, choices don’t have to branch out to different directions to feel meaningful.

KOKORO’s choices did have to lead to different paths so we had to build a tree structure. But we also kept track of things a user says. This allows the app to “learn” about the user. Subsequent segments of the conversation are adapted based on this learning. This allows for more flexibility and it scales better. A section of a conversation has various states between which we switch depending on what a user has said in the past.

We did something similar in Free Birds but used it to a far more limited degree, really just to once again colour certain pieces of dialogue. This is already enough to give a player a sense of agency.

As you can see, it’s all far from rocket surgery but you can get surprisingly good results just by sticking to these simple patterns. If I were to investigate more advanced strategies I would look into NLP for input and procedural generation for output. Who knows, maybe I will get to work on a project involving those things some time in the future.