Using pathway redirection
To best understand this page, you should be familiar with how TTalk sessions work in relation to the use of text-based chat between a moderator and a small group of learners. This generally works well and has evolved nicely over the past few years. A less well explored function that has been part of TTalk for some time is the ability for the moderator to be able to send each learner onwards in the map.
In the earliest guises, this redirection function was simply used to indicate that the moderator was satisfied with the current TTalk chat session, that the learner “got it”, and that the learner could continue with the scenario.
Note that in nearly all our map designs, we have placed a by-pass option, which allows the user to continue with the map, in the event that a moderator is not available.
Also note that we have used Hidden Links in our designs. A Hidden Link is not visible to the user in the usual set of Links displayed by the [[LINKS]] shortcode. But a Hidden Link is still available as a destination Node in the Redirect Target List (the list of Nodes that the moderator can send the learner towards). See below.
Another new function is Role-Based Node Access (RBNA). This is a little bit more finicky to use e.g. there is currently no method within the OLab Designer to indicate that a Node is locked for certain Roles. At present, this has to be manipulated directly in the SQL table security_roles. RBNA is relevant here because it can be used to create pathways and nodes that are only accessible to moderators.
Redirect Target List
The Redirect Target List (RTL) is a fancy name for the Nodes that are accessible via Links from the current Node where the learner is located in the TTalk session. (Remember that the moderator is on a different Node in the map at this point.) In other words, as with other Nodes in the OLab Directed Acyclic Graph (DAG), the Links determine where the player can go to next. In regard to being Redirected or sent by the moderator, the available paths are still determined by this topology.
The chief difference between the RTL and the list of links that is shown to the learner at that point in the map is that the RTL includes Hidden Links. A Link that is marked as Hidden is (obviously) not visible as one of the Nodes that appears in the choices in the standard list of Nodes (when the map author has placed the [[LINKS]] shortcode in the Node. This is often included automatically as part of the Theme for the map so don’t worry if you cannot see the [[LINKS]] shortcode on that particular Node’s text.)
Because Hidden Links are included in the RTL, this provides an easy mechanism for the map author to provide pathways that the moderator can send the learner to, but that the learner cannot choose for themselves. This can be very useful.
Extending the use of Redirection
These changes and extensions in functionality open up a whole new way of designing maps and scenarios.
Initially, our designs tended to be rather like this:
Here you see the basic pathway, including the by-pass node; the direct link onwards is hidden.
As noted above, there is usually a by-pass Node, so that learners can keep going if the moderator is not present.
From this basic model, it is then not difficult to provide a wider range of options in the RTL that the learner can be redirected to.
In the above design, the moderator can choose from a few different options, but these then subsequently converge and continue as a common pathway. Two are hidden (yellow links) and not available to the learner.
These basic tools and map models now open up a whole new set of learning designs that the author can use.
New Learning Designs
The flexibility that is now introduced by these techniques and template designs leads to several new ways in which to interact with your learners.
Send them back for more…
In the basic designs above, we assume that the learner is going to continue. But it is perfectly reasonable to send the learner back: possibly to redo part of the case, try the TTalk chat session again, or tackle some other part of the scenario because the moderator is not yet satisfied that the learner is ready to progress.
You can send them back for more information, more practice or more detailed reflection on the current challenge. Or send them in a new direction entirely.
In the introductory templates, the pathways tend to converge again towards a common point. Having such convergence does make map design easier, but it can also be limiting. Nothing in OLab constrains that. The author is at liberty to create whole new sets of links and pathways.
For example, the author can provide options towards easier or harder pathways: a simple form of adaptive learning, as it were. The moderator could also send the learner onto towards a different moderator, who may have skills in a different area or who may have a different discussion topic on hand.
Example Design Patterns
- Simple branched
- Provide different feedback, counter scores
- Send back to redo a section of the case
- Send for more information – provide them with more textual help in other nodes
- Send for more instruction (possibly from another moderator)
- Send to different track (easier or harder) – adaptive testing etc.
- Send to chatbot for more practice on basic question-response sets
- Hidden vs open options, where some nodes can be selected by either learner or moderator
- Role-changing – some map designs can allow for users to try out different roles e.g. if you both have accounts with moderator roles (or superuser), you can try this map, which allows you to swap roles.
We expect that there are many more patterns – please share …