Tag: Twine

Branching Scenario Prototype in Twine

I built this branching scenario in the open source tool Twine. This scenario is moderately complex, with a total of 17 pages (or passages in Twine terminology) and 8 different endings. The ideal path has 5 decisions to reach the best conclusion.

I generally use Twine as a prototype for review and testing purposes. You can use Twine as the finished product though, especially if you do some formatting to make it look better. This is currently pretty rough (just text on a white background), but that’s OK for a prototype.

If you use Twine as a prototyping tool, you can build the finished version in Captivate, Storyline, or another tool of your choice.

Try the scenario out yourself by clicking below (the scenario will open in a new tab).

Click to open the scenario in a new tab.

This is the map of the entire scenario. You can see how many of the choices are reused.

Twine map of the entire scenario

Want to learn how I created this?

Read the previous posts in the series to see my process for creating this scenario.

 

Can’t get enough? Check out all of my posts on Storytelling and Scenarios.

 

 

Writing Mistakes and Consequences

In my previous post, I explained how I write the ideal path for a branching scenario first. Once that is complete, I write the mistakes or errors and consequences for those choices.

First, Draft One Alternate Path to Its Conclusion

I start writing a single alternate path from beginning to end. This is the easiest way for me to create continuity in the narrative. I have the ideal path already created at this point, but you can see below that some choices are dead ends. Other choices are still marked as TBD for placeholders.

branching-ideal3

In this case, I’ll go back to the very first decision and start writing the mistakes and consequences. When I was drafting the ideal path, I knew the worst choice was to send a price estimate right away. I’ll start there and finish writing that path. In this case, this mistake is a big one that will result in an immediate failure and restart.

Sophie provides a fixed-price quote based on her limited information. Robert immediately accepts without negotiating, making Sophie wonder if her price was too low.

One month into the project, Sophie realizes what a terrible mistake she has made. She severely underestimated the scope of the project and the time required. She’s frustrated, and her client is frustrated at how long everything is taking. Sophie works long hours for weeks–so many hours that her effective hourly rate is much lower than usual.

Once the project is finished, Sophie vows to never give a price estimate again unless she has more information.

Draft Another Alternate Path (and Another, and Another…)

Once the first alternate path is written, go back to the beginning of the scenario. Find the first decision point that isn’t fully fleshed out, and start writing there. As before, try to write one complete path from start to finish.

In this example, I go back to the first choice. In my first pass at drafting the ideal path, I left a placeholder for “Some other OK choice TBD.” Now I need to create a third option and follow through on the consequences.

In this case, a partially correct choice would be to ask specific questions about the project. (The best choice is to ask high level questions about the business goals first, rather than getting into the details of the training too early.)

Sophie realizes she doesn’t have enough information to provide an accurate estimate. She asks Robert to clarify how long the courses actually are.

Robert replies with the details.

  • Course 1 is a half day (3.5 hours).
  • Course 2 is one day (about 6 hours).
  • Course 3 is two days (about 12-13 hours).
  • Course 4 is four days (about 26 hours).

What should Sophie do next?

[[Send Robert a price estimate for the whole project.|Send Robert a price estimate.]]
[[Ask Robert what level of eLearning he wants.]]
[[Ask Robert some high level questions about goals and budget.|Send Robert some client screening questions.]]

I continue like this with each choice until every path reaches its conclusion. I use my notes from my conversations with the SME and other stakeholders, plus any other research, to determine realistic consequences.

Good, Bad, and OK

By default, I usually aim for one choice that is the best (the ideal path), one choice that is clearly bad, and one choice that is OK or partially correct. If you’re stuck on what choices or mistakes to provide, try aiming for that pattern in each choice.

I do vary that, especially later in the scenario. By the time someone has made multiple good choices and is nearing the end of the ideal path, there might not be any terrible choices. It may be Good-OK-OK instead. If someone has made a large mistake, there might not be any good options; maybe the best recovery is an OK choice.

In Twine, I tag my choices as Good, Bad, and OK. In PowerPoint or other tools, I usually color code them in a flow chart as green, yellow/orange, and red. This helps me keep track of the structure. It also helps voice over or actors know the tone if this will be turned into audio or video later.

Let People Recover from Mistakes

Not every mistake should result in immediate failure and a restart. Just like in real life, sometimes people can recover from their mistakes. Branching scenarios can help people practice that skill of moving past an error.

In the example above, I want the learners to have a chance to realize they’re getting into the details too early and to back up. After asking about the length of the training, they can choose to ask high level questions instead. That gets them back to the ideal path.

Screenshot from Twine showing choices reused

Crossing Paths

I usually have some paths that cross, as shown in the screenshot above. This is one reason I really like Twine for drafting branching scenarios, regardless of what tool or format the final version will be.

Often, I create several ways to get to the same path or ending. Reusing some choices or endings helps reduce the complexity of the scenario.

After a Failure

You have several choices of what to do next after you reach a failed ending of a scenario.

  • Ask learners to restart and try the scenario again. This is what I did in the immediate failure of providing a price estimate with woefully inadequate information above.
  • Let learners back up one step so they can make a better choice.
  • Let learners go back to a milestone or checkpoint so they don’t have to redo the entire scenario. This is especially helpful in longer scenarios with many decision points.

I explain the pros and cons of these restart or retry options in detail in a previous post.

Testing and Revising

Once I have a complete draft of everything, I test the options, reading through each path and revising to fix anything broken. I prefer to do this testing at least a day after I finish the initial draft. It’s easier to see my mistakes when I have time to set it aside for a while and come back later.

I also review my notes. Did I include all of the mistakes that were critical to include? Does the flow make sense? Is there anything too repetitive that should be collapsed into a single path or rewritten?

After that, it’s ready for me to send for review by the SME and other stakeholders. I post the Twine version as an interactive prototype so they can test it themselves. I also export to Word so it’s easier to track changes in wording (especially with multiple reviewers).

Looking for more?

Check out my previous posts on branching scenarios:

 

Managing the Complexity of Branching Scenarios

On reddit, someone asked how to manage the complexity of branching scenarios and keep them from growing out of control. One of the issues with branching scenarios is that you can get exponential growth. If each choice has 3 options, you end up with 9 slides after just 2 choices, and 27 after 3 choices. This is 40 pages total with only 3 decisions per path. For most projects, that’s more complexity than you want or need.

Branching scenario with exponential growth

So how do you manage this complexity?

Use Twine

One way to make this branching easier to manage is by creating your scenarios in Twine. Twine makes it very easy to draft scenarios and check how all the connections flow together. No matter how complex your scenario is, Twine makes it easier to create it. Cathy Moore has an example of a scenario she built in Twine. This scenario has 57 total decision points, but it only took her 8 hours to create.

You can use Twine as your initial prototype, or you can use it as your final product. I have used Twine as my initial draft and prototype, then exported everything to Word as a storyboard for developers to build the final version in Storyline.

Planning a Scenario

Before I sit down to write a scenario, I always know my objectives. What are you teaching or assessing?

I usually have an idea of how long the ideal or perfect path will be. If you have a multi-step process, that’s your ideal path. If there’s going to be 4 decision points on the shortest path, I know what those are before I start writing.

I also usually know at least some of the decision points based on errors or mistakes I need to address.

There’s a limit to how much you can plan before you just start writing it out though. I find it’s easier to just open up Twine and figure it out within that system.

Allow Opportunities to Fix Mistakes

One trick for managing the potentially exponential growth is by giving learners a chance to get back on the right path if they make a minor error. If they make 2 or 3 errors in a row, they get to an ending and have to restart the whole thing.

For example, maybe you’re teaching a communication skill where they should start with an open-ended question before launching into a sales pitch. Choice A is the open-ended question (the best choice). Choice B is a closed question (an OK choice). Choice C is jumping right into the sales pitch without asking (bad choice). After the customer response for choice B, I’d give them an opportunity to use the open-ended question (A) as their follow up. Reusing some choices helps keep it from growing out of control. In this image, reusing choices cuts the total number of pages from 40 to 20.

Flowchart for branching scenario with 20 pages Make Some Paths Shorter

Not every path needs to be the same length. In the above image, one branch from choice C is shorter. It ends after 2 choices instead of 3. You might make a short path if people make several major errors in a row. Past a certain point, it makes sense to  ask people to reset the scenario from the beginning or backtrack to a previous decision.

Good, OK, and Bad

In branching scenarios, not everything is as black and white as a clear-cut right or wrong answer. You can have good, OK, and bad choices and endings. In this example from my portfolio, green is good choices/endings, orange is OK choices/endings, and red is bad choices/endings. In this scenario, if you choose 39 (bad), you have 3 options: 40 (back on the good path, recovering from the mistake), 41 (OK), and 42 (a bad choice leading to a restart). This example has 15 endings, which is still more than I would like; if I was redoing it now I would probably collapse a few more of those endings together.

Branching scenario flowchart with good, OK, and bad choices and endings

Your Ideas?

Do you have any suggestions or tips for managing and reducing the complexity of branching scenarios? Please share in the comments.

ID and E-Learning Links (2/8/15)

Posted from Diigo. The rest of my favorite links are here.