Writing a branching scenario can be intimidating or overwhelming. I have found that it’s easiest to write the ideal path from start to finish first. I note decision points and sometimes draft bad choices along the way, but I don’t fully write anything else until I finish the ideal path.
This is my process for planning before writing a branching scenario, including creating a summary, outline, and list of mistakes.
In branching scenarios, we can use a combination of immediate and delayed consequences and feedback.
In my previous posts, I shared tips for managing the complexity of branching scenarios and
In a comment to my post on Managing the Complexity in Branching Scenarios, Nicole Legault
The traditional multiple choice questions we use in assessment are often abstract and measure only whether people recall facts they heard in the last 5 minutes. Converting these questions to scenario-based questions can increase the level of difficulty, measure higher level thought, and provide relevant context.
On reddit, someone asked how to manage the complexity of branching scenarios and keep them
My response to three common objections to using stories for learning: “Not everyone can be a storyteller,” “Stories are a waste of learners’ time,” and “Stories don’t work for all kinds of training.”
One of the common objections I hear to using storytelling in training is that “stories don’t work for all kinds of training.” Those who are skeptical of storytelling often claim it doesn’t help software training. However, I think stories can have a place in some software training.
In a recent conversation, a colleague asked, “Once you and your client have agreed on