By Cathy Moore
Branching scenarios can be a pain to design. Happily, you can use a simple tool called Twine to easily draft the scenario and produce it. In this post we’ll look at an example branching scenario that I wrote to demonstrate Twine’s basic features and to make a point about scenario-based training.
In the scenario, you’re a journalist in a hurry to get to a hot story in Zekostan, and your “guide” can’t speak English or drive. You have to quickly learn the necessary Zeko terms to navigate the roads and respond to events along the way. The scenario was inspired by a language-learning activity designed by Kinection.
Try the activity, keeping in mind that it’s a casual, unfinished experiment. Then come back here for more about Twine and my design decisions.
Each scene in a scenario is really a small record in a wiki database. The links you create determine the path that the learner takes through the records. Thanks, Steve Flowers, for pointing out Twine in the Articulate forum.
Here’s the flowchart view, which Twine automatically creates as you link your scenes (click for a bigger image):
Twine offers some advantages over other ways to write branching scenarios. You can:
- Quickly switch between flowchart view and story-editing mode
- Link scenes using simple text
- Add images and sound files and otherwise use HTML
- Export the story in text format for review and proofing
- Publish the finished story in HTML
- Use simple codes to keep track of variables or limit learners’ choices (not shown in the sample scenario)
Here’s the editing window for a scene. The “bookmark” tag means that this scene will appear as an option when users click the “Rewind” link to the left of the story.
The default publishing styles might not work well for corporate audiences. For example, the default version of the sample scenario had white text on a black background. However, you can quickly change the style by creating a special passage in the story that contains CSS. You can then copy that passage into future stories.
With four lines of CSS, I changed the background, text, and link colors. Here’s how one much more customized Twine story looks:
A few drawbacks
I was very happy with how easy it was to write in Twine, especially compared to my usual approach involving a separate flowchart and script. There were just a few things that didn’t work super well:
- I put a few bookmarks in so you could see how the “rewind” function works. However, the feature displays the first few words of a scene instead of its (guaranteed unique) link text. In the sample story, the first few words are usually Ludo confirming or correcting your previous choice, so the feature doesn’t exactly shine this time.
- Your browser’s back button should take you to the previous scene, but in my tests it occasionally went back one scene further.
- The flowchart layout got bizarrely spread out about halfway through the story, and I had to manually drag scenes closer together. This might be related to the fact that Twine requires a more recent version of the Mac operating system than I have installed.
- If you want to track learners’ performance in the scenario, you could use variables, but I’m not sure how that would interface with an LMS.
I didn’t track my development time because it wouldn’t have been realistic — I was learning to use Twine while I wrote the scenario and was writing this blog post at the same time. I can say that the “production” phase takes literally 2 seconds: you click “Build Story” and an HTML file immediately appears.
So you might assume that producing a scenario in Twine takes this long:
- However long it takes you to write the story in text
- + Some time for creating any images and sound files and embedding them using HTML
- + Some time for tweaking the CSS to avoid the white-on-black theme (took me 20 minutes because I’m not fluent in CSS)
- + About 2 seconds to click “Build story”
- + Some time for quality checks (this goes quickly because it’s easy to find a particular scene in Twine’s flowchart view)
Teaching through a branching scenario
The example scenario is an attempt to show that we don’t have to front-load learners’ brains with vocabulary or other facts before the “practice activity.” Instead, we can plunge them, clueless, directly into an activity that exposes them to the new information in a way that helps them figure it out.
A traditional approach to this type of language activity would be to first tell learners how to say “left,” “right,” and similar words in Zeko. We might have a little drill or game to get them to recognize the words quickly, with “correct” and “incorrect” feedback. Then we’d use the journalist’s story as a practice activity.
What I’m suggesting instead is to skip the information and go straight to the story. Design the story so the learners can discover meanings on their own. Then provide a natural pause to review what they’ve learned and make sure they got it right. Read more about this in Throw them in the deep end (but keep a life preserver handy).
But you can’t teach everything through a scenario!
Of course, it would be tedious to teach all the vocabulary of a language through scenarios.
In the Zeko sample, I’d pause the action where the story currently stops and include an optional game to reinforce the new words.
I’d then finish the story, probably including a scene in which you win an exclusive interview with the Minister of Science by correctly using Zeko to warn her away from some sort of danger.
Then I’d revert to “normal” instruction to more efficiently cover additional vocabulary and grammar for awhile. Another branching story would appear later, to both reinforce what has been covered so far and to introduce a handful of new terms or concepts. Maybe it would require learners to recognize the grammatical pattern of a phrase and build new phrases using the same pattern.
But it’s just text!
Yeah, it’s just text. I wanted to show you Twine’s default behavior. The sample scenario is an example of the quickest and cheapest way to generate scenarios with Twine.
While some designers shun text because they (incorrectly, in my view) think it’s boring, I think its greatest weakness in the sample scenario is that it teaches people to read Zeko, not to speak it or understand it when it’s spoken.
If I were serious about teaching language this way, I’d produce the dialog in audio only. It would probably be simplest to produce the narrative as audio as well and make each scene’s audio file play automatically when you land on the scene. Instead of displaying redundant text, I’d need to come up with visuals that support the story. That’s way more work than I wanted to do for a quick sample.
Soft skills might work better
I wrote a fake language story because that was the only way I could guarantee that none of you knew the answers and you would therefore experience being clueless in a scenario.
However, scenarios might be more suitable for teaching soft skills, such as having difficult conversations, overcoming buyers’ objections, and leading a team through change. Soft-skill materials don’t have as much information that requires memorization, and they have more grey areas to give the stories depth.
For a much deeper, more polished scenario that also plunges learners directly into a situation, see the Haji Kamal piece for soldiers in Afghanistan.
Possible advantages of this approach
By skipping the formal teaching and going straight to the story, we:
- Let learners who already know some Zeko skip explanations that they don’t need
- Encourage learners to build meaning from (somewhat) realistic experience and mistakes, mirroring how we learn in the real world
- Give learners a more challenging puzzle to solve than rote memorization
- Possibly improve recall by connecting facts to a story
Basically, we avoid making the material too easy and therefore forgettable.
But it’s not fair!
Some people argue against this approach because it increases the likelihood that learners will make an incorrect choice: “You’re setting them up for failure!”
But we’re not just throwing learners into the deep end. We’ve given them a life preserver by designing the story in a way that introduces new information a bit at a time.
The harshest choice in the story is the first choice between “left” and “right.” You have a 50% chance of getting it right. If you get it wrong, you learn “no” and you immediately get back on track. It isn’t likely to be a catastrophic experience.
The sample story is just a lightweight tale that I outlined in five minutes. But it does include the characteristics that I recommend be included in real branching scenarios:
- A big goal with emotionally compelling consequences: you have to be first on site because you screwed up your previous assignment
- Minimal setup: four sentences establish the back story and the challenge
- Suffering: your guide doesn’t speak English; your competitor might be close behind
- Time pressure
- An increase in tension partway through the story: is that the Agence France-Presse car behind you?
P.S. I have nothing against Agence France-Presse.