Choose Your Own Adventure: E-Learning Edition #325
I have a back catalogue of small instructional design challenges and charrettes that I’ve been meaning to build into something bigger one day. That is obviously taking too long, so here’s a new idea. The Articulate E-Learning Heroes Community runs a weekly eLearning Challenge. I’ve mentioned before that often different IDs in different contexts will use different tools, and while I’ve used some of Articulate’s products, I’m primarily a Mac user. This means that a number of their products are not available to me. So instead, I thought, rather than being an Articulate eLearning Hero, that I could be an InArticulate eLearning Hero. So here it goes.
This week, your challenge is to share a branching example designed around the popular Choose Your Own Adventure stories. Please include a story map of your project so we can see your branching paths.
You don’t need to build a massive, story-based scenario. Just build out enough content to show how such a model could be used in e-learning.
Prototypes and placeholder content are your friends this week. Use them to build out scenario templates.
Open Labyrinth: Sara-Jane Pritchard (272)
So the first thing you’ll notice after trying it a few times is that this was unfinished. Here’s the whole story. I have though about the branching scenario in H5P since it was initially released, after all, branching scenarios that such an amazing learning tool. The big problem is that for a sample or demo, I couldn’t really come up with anything myself. After reading this challenge from the elearning hero community, I was thinking about where I might be able to get a CC licensed branching scenario I could grab content from and bring it into H5P. Thankfully, I recalled Open Labyrinth from my days working in medical education. Virtual patients are a great example of branching scenario based learning, where the choices you make move time forward and impact the patient (through the story). eViP from the UK and Open Labyrinth from Canada provide a whole bunch of virtual patient cases that are largely created using hypertext only (check out more examples from Open Labyrinth).
So with the content available and H5P infront of me I proceeded to try this out doing exactly what I normally would NOT recommend, just start building. I’m still happy to have learned a bit. Early on it looked like I could drop content in (like text, video, etc) and then add a branching question that would split the pathway based on the answers.
You can see that almost right away there is a custom ending for the “you made a really bad choice right off the bat” option. At this stage it seemed like a really straight forward build, anything you want the learner to see you just put in as text, an image, a video, a course presentation, etc. Then drop in a question and include a few decisions they could make. After each decision include either more content to go through or create a custom ending. Easy peasy.Well what about when you have pathways that end up presenting an option again, after all, life isn’t linear.
As you assign decisions to jump branches some of your elements, either text or questions, will move. As you can see, any decision icon that has those red arrows indicating a track jump does not have any item below it, nor does it have a line that shows where it goes. It might create a lot of visual clutter in super complex branching scenarios, but even a lightly hashed line showing where those decisions jump to would be helpful. Thankfully, I’ve finally started listening to a certain K9’s advice about making use of the metadata fields in the activity. Hovering your mouse over elements gives you some of that information so as long as you name things in a consistent way you can still find your way around.
As I went through the eViP, there were a few decisions that you could make that would lead to a page that only had one more option before presenting a multiple decision page. For these cases, I followed one text element by another. What that did was place a proceed button in the top right, an action similar to “there is only one thing to do here for now” type interaction. In the picture above, you can see one of these text stacks leads to a branching question (left), and the other leads to a branch jump (more on the right). For now, this is how the building is going and it’s pretty smooth. at this point what I’m doing is hitting a page with decisions, building the decisions in H5P, clicking on each one in the eViP, creating the each text element in H5P, adding a branching question with the choices listed in the eViP and carrying on. It started to be a pretty smooth workflow.
One of the first hurdles I really encountered was a spot where you could choose different agents to administer to the patient. Now I could have continued building as I had, adding text, creating a whole bunch of branching questions, and creating a lengthy tree. But What I noticed in this section was that you could “choose to have done something else”, kind of like a take back action. At first I thought decisions would be the way to do this, but what I ended up doing was adding a text element after each decision item, and having it branch back to the original question “the agent you choose is:”. I then added “review in the morning” which in the original eViP appeared in each subpage to the agent choice. You can see here that the agent choices allow you to remake your decision, but the “review in the morning” option takes another path (not a great one mind you).
So the previous problem and solution are shown in the middle of the above screenshot; the next problem I encountered is on the far left (turns out I somehow ended up building this right to left which I think was a decent systematic approach). For the items on the left where you’re treating the patient, I decided to try out the feedback function. Notice that there are not text blocks, but instead there are branching questions that lead directly to branching questions. The content that normally would have gone into the text element I instead placed in the feedback which becomes available when you choose a branch to send the user to. At first this seemed like an efficient way to build the pathways, and I still think in some cases you may want to do it this way. However, the big caveat here is that if those branches present many of the same options over and over again, you end up filling in more fields by hand than you would by doing the original process of creating text elements followed by branching questions. Going from branching to branching, there was no easy way to copy and paste content. For an element you can copy and paste a whole element, but for the way the eViP had some circular decisions in the section on the left it wouldn’t work. Not only that, but it turns out when choosing a branch to jump to, H5P lists the description, not the title on each element. So in my case I ended up with a list that looked like this:
This, as it turned out, was the thing that broke me. I didn’t want to undo all I’d done, but I also found myself confused between the eViP content – which started going to unique pages under the same decision title depending on the pathway you took – and this list. I thought the metadata was going to save me, but it didn’t quite make it to where I would find it very useful. So I halted development of this activity. In the end I’m glad it was just a text-based case so that I could focus on the mechanics of the branching rather than dealing with a crazy amount of media.
I still learned a tonne, and in a scenario where I’m not just prototyping an activity, I now feel I know the H5P branching scenario well enough to adequately create a game plan to tackle the build. One thing I didn’t venture into for this demo was the points system. I remember one eViP I saw years ago actually gamified the scenario where each decision you made either cost money, drew blood from the patient, or both! You were presented with a score at the end of that activity and students ended up competing to see who could complete the case spending the least, and drawing the least amount of blood. It was pretty cool. I might tackle another eViP in the future and see if I can get it to make a similar mechanic.