Sorry for the pun inserted. The joke would be better if it did not need to be explained. IAM = Identity-Access Management, the system that determines who you are and what you are allowed to do in an online platform. Those annoying passwords etc.
Despite the title, this piece is not much about role play itself. We just published an article last month, OLab and Virtual Roles, about role play in its less technical sense and how we have been experimenting with virtual roles, role-switching during a scenario and stuff like that. The full formal version of the article can be found here: Topps, David; Cullen, Michelle; Wirun Corey, 2021, “OLab and Virtual Roles”, https://doi.org/10.5683/SP2/Q4EGTI, Scholars Portal Dataverse.
No, this post is more about the IAM side of things and the technical aspects that we have been working on. Sadly, this reminds me of another terrible joke. An army corporal is pissed off about the new posting he just received and decides to complain to the Sergeant Major. He quickly looks up the number in the fort’s phone directory (yes, the army is not so technical and still believes in paper for such things… those fickle computers would be wiped out by an EM pulse if we had a war, don’t you know!), rapidly dials and brusquely gives the recipient an earful of barrack room language on what he thinks of his latest posting.
“Do you know who you’re talking to?” thunders the irascible Major, spluttering through his gin and tonic.
“No. Do you know who you’re talking to?” replies the corporal. When the Major grunts a negative, he says, “Well, thank gawd fer that. I ain’t telling ya,” and hangs up right quick.
Ok, enough torture. Back to the main point. Over the years and through many projects, we have found how important it is to combine a variety of tools and applications in our learning designs. Even though OLab and OpenLabyrinth are very powerful tools, thinking that one tool can do it all makes every problem appear to be a nail. You should find the best tool for each purpose and link them together.
In OLab3, we tried to make it do too much. In OLab4, we are moving more towards a services-based approach, which will allow us to integrate OLab more smoothly with other tools like Moodle, WordPress and the whole gamut of educational software applications.
We did make some of our previous functions, like video curation, into separately callable services e.g. CURIOS. But some other functions like Turk Talk were tightly built into the core of OLab3, which creates all sorts of problems. In OLab4, this will be simplified as another callable service, which opens up a lot of possibilities.
Even the IAM aspects were rather crudely managed in OLab3. There are lots of better ways out there of managing who can do what in our platform so why try to replicate the functions of Moodle etc? One of the ways we have tried to tackle this in the past was with IMS-LTI (Learning Tools Interoperability).
LTI is an excellent system, secure and not difficult to code into software. However, for program directors and scenario authors, it poses a problem when defining roles: the specification of what a certain level of agent/actor can do within a system. In OLab3, the roles (or security levels) were crudely limited to four: learner, author, reviewer and super-user. LTI has a much wider variety of roles.
But there is a problem when getting two systems to play nice with each other using LTI. Across the many systems out there who do implement LTI, there is very little common agreement in the number and definition of these roles. About the only constant is ‘student’, who is at the bottom of the heap and can’t do much.
You also have the functional problem: what if the learning designer wants to test how her new module works from the perspective of the learner? She certainly does not want to take the clunky old approach taken by OLab3 where she has to logout, login again using a student account and then play the module until it breaks, have to logoff, login again as an author in order to fix things: a very crude, inefficient debugging cycle.
So, just to confuse you a little more, we are working on virtual roles: not the same as the Virtual Roles article mentioned at the top of this post, but virtualized IAM roles, which will allow us to change the IAM role of that user on-the-fly. This could also be done programmatically, which opens up some interesting possibilities.
We are also exploring the use of Conditional Rendering of Scoped Objects. This means that, depending on the context and the IAM role of the user, certain objects like teacher directions in a text panel, will only be shown to teachers, not to students. We had this in a crude form in the Annotation pane in OLab3 Nodes. This new system will be much more flexible.