TTalk map design tips

In OLab4, we have used a slightly different design pattern in TTalk cases. Most of the teacher and learner experience is much as before: a teacher or moderator (or Turker in the old terminology) can use text-based chats with up to 8 learners. The moderator can also redirect or jump the learner to a new Node in the map. 

In OLab3, the moderator could pick any currently logged-in learner to chat with. In OLab4, we have provided a bit more structure, with predefined Rooms. 

Design Notes

Because the pathway through the map that is followed by the moderator and the learner are slightly different, it can be a little confusing to new map authors. We suggest that you focus on the pathway and choices available for the learner to start with, and then add in the nodes and pathways for the moderator afterwards. 

  1. You should nearly always include a pathway that does not depend on the moderator being present.
    • We usually call this the by-pass Node
    • The learner can select this at any time, even when a moderator is present
    • This allows for easier testing of the map design
    • It allows the learner to move onwards in the map even when the moderator is absent. 
    • It is important to make clear to the learner the consequences of choosing this by-pass link if the moderator is present. E.g. they may miss out on important interactive information from the moderator or they may lose points in an exam situation. 
  2. When the learner reaches a Node with a TTalk question, they can only interact with the moderator when the moderator admits them from the ‘waiting room’. 
    • This can sometimes take a minute or two if the moderator is busy with other learners
    • The learner can choose to by-pass this TTalk session – see above
  3. When the moderator is chatting to the learner in a TTalk session, the moderator can Redirect or move the learner onwards in the map. 
    • The list of Nodes that the moderator can send them to is the same as the Links available from the learner’s current Node.
    • This is why we suggest that authors first focus on the choices available to the learner, and not the moderator’s pathway choices.  
    • There are two exceptions in this Redirect Target List:
      1. Hidden Links – will show up for the moderator
      2. RBNA-locked Nodes – will show up and so should not be included in the design. If the moderator redirects the learner to a locked Node, it will generate an error.  
  4. During a session, a moderator can only be in one Room at a time. 
    • Up to 8 learners can be in a Room
    • You can reuse Rooms if you think that learners are likely to get out of sync, some being faster, and others slower, to progress through the map. The Room name is defined as part of the TTalk question. Make sure that the Room name is the same at each TTalk chat for both moderator and learner side. 
    • If the Room is used multiple times in a map, it is better for the moderator to stay in that room and wait for the learners to return to the room. This way, learners can be automatically reassigned to the room and enter immediately when they return to the same Room in a subsequent Node. 
    • If the moderator leaves a Room, any learners who are still in there will be disconnected. 
  5. As in any other Node, the current text displayed on the screen for the learner and the moderator will be different, and simply as written in that Node’s text. In this way, you can provide different directions for the learner and the moderator. 

Use of Hidden Links

As in OLab3, we sometimes want to provide a Link between two Nodes that is not visible to the learner. This does not stop them from reaching the destination Node e.g. if they type in the node ID number into the browser URL, or if they are sent there by a Script Object or other [[LINK:nnn]]. 

The hidden Link simply does not appear in the normal list of Links exiting a node. 

In the Designer, simply click on a Link arrow and then select ‘Hidden’ as the attribute. Remember to [Save] the changes to the Link. It will not appear differently in the Designer canvas. (We sometimes use another color for hidden Links,  just to remind ourselves that the Link is hidden.) 

One of the main purposes for Hidden Links is when working with a moderator in a TTalk session. Hidden Links will appear in the Redirect Target List for the moderator and the moderator can send the learner down a hidden Link. This allows case authors to provide choices that are not directly available to the learner but that the moderator can still send them to. 

Authors should avoid including RBNA-locked Nodes as potential destinations in the Redirect Target List.

Use of RBNA-locked Nodes

See https://olab.ca/role-based-node-access-in-olab4/ for more info about RBNA. 

As a separate design feature in OLab4, we introduced Role-Based Node Access (RBNA) in late 2022, in OLab 4.6. This has proven to be a very useful feature, especially in TTalk-oriented maps. 

Just as you can specify whether certain maps can be played by certain user-roles e.g. learner or moderator, you can also specify when certain Nodes within a map are accessible, depending on the user’s Role. 

Note that this is defined in the security_roles table and is not an attribute of the map or node. At present, there is not a direct way for the author to specify this in the OLab Designer. You must use a SQL editing tool to do this. 

If a Node has been specified as only accessible to certain user roles, then it is quite securely locked and cannot be viewed by other user roles, even if they know the direct URL and node ID. This can be quite a useful way to protect sensitive information such as notes for teachers or information for moderators. 

Because the TTalk moderator sometimes needs to scoot around the map more quickly than the learner, we have made use of RBNA-locks to create Nodes that only moderators can get to, or to have shortcuts between multiple TTalk sessions so that the moderator does not have to slog through all the same nodes as the learner. 

However, it is not a good idea for the map author to place a RBNA-locked Node in a location where it will be included in the Redirect Target List. See above.

Note that there is some potential terminology confusion: the table map_nodes has a column or attribute named ‘locked’. If this is set, it refers only to the current xy coordinate of that Node on the Designer canvas. It was intended for use as a concept-mapping or drawing feature. It has nothing to do with Role-Based Node Access.

Example maps

We have created an example map at https://everest.cardinalcreek.ca/player/1711/0 for testing and illustrating how this works. We will move this to a more complete Demo example soon. We gave up on excluding RBNA-locked nodes from the Redirect Target List because we had spent too much time on OL-129 at this point.  

We have also created an example map at https://everest.cardinalcreek.ca/designer/1728, which is slightly simpler and may be better for basic illustration purposes.