Courses, Groups, Sets and Scenarios

In OLab2 , this was handled quite crudely. There were 4 types of “security level” for a map:

There were also 4 types of user (also confusingly called “security level”):

This worked sufficiently well internally but was not oriented towards using more sophisticated tools for Identity & Access Management Systems (IAMS).

In OLab3, the same approach was carried over but increasingly, we found the need to connect OLab to other systems. At the prompting of Matt Simpson and the Entrada group at Queens, we adopted the use of IMS-LTI or Learning Tools Interoperability.

For many of our purposes, LTI solved a lot of issues. Authentication is generally handled by an underlying OAuth2 layer which passes simple tokens between systems. OAuth2 was being widely adopted and it allowed us to provide OLab3 logins using other credentials such as Google, Facebook, Twitter identities. This worked well for a while.

LTI asserts that there are two classes of learning tools:

We applied LTI functionality to OLab3 so that it could act as both the LTI Consumer and LTI Provider, depending on the context and needs of the organization.

For example, when we developed our CURIOS mashup tool, we did not want to bother with the user management aspects of the tool. Since the tool was primarily designed for use by OLab authors, we made CURIOS assume the function of an LTI Provider. We then used OLab3 to provide the function of LTI Consumer, which would call the CURIOS editing interface. This combination meant that we could use OLab3 to decide who would be able to create and edit CURIOS snippets i.e. the OLab authors.

But this also left open that anyone could then play a CURIOS snippet, without the need for authentication, login etc. This helped ensure that CURIOS snippets could be used widely across many other tools and platforms, such as WordPress, Moodle, Drupal, OLab, without having to worry about logins, credentials, authentication etc.

Because OLab3 could act as an LTI Consumer, we were also able to include resources from other tools such as WordPress, H5P, without having to bother the user with new logins. When we eventually implemented xAPI and reporting to the LRS, we used LTI for the handshaking between systems.

In making OLab3 adopt the function of the LTI Producer, this meant that cases and resources from OLab3 could be called from other learning tools. The obvious use case here was in using the Learning Management System (LMS) to provide the IAMS functions that OLab3 was weak at, and that is core functionality for an LMS.

We were successful in setting up LTI authentication between OLab3 and Moodle, Desire2Learn (D2L), WordPress, LearnDash, Drupal and a few other test systems. This worked well.

The problem came when dealing with authorization. Authentication is the process of telling a system that this user is a good guy and we vouch for him, that he is who he says he is. Authorization is the process of telling a system what the user is allowed to do, their role, capabilities, skills etc.

Roles are a core concept in authorization. They are hierarchical and faceted (can overlap). At the bottom of the pile in education, there is the learner role. They don’t get to do much except read stuff, maybe play some cases etc. But they can’t create or make changes to LMS resources. At the other end of the scale is the superuser role (not always called that) who can pretty much do anything: create, edit, delete functions for documents, courses, even other users. OLab3 had both these roles of learner and superuser, with these same capabilities.

The problem in authorization lies in between those bottom and top levels. For OLab3, it was simple: we had authors and reviewers. But this was too simple and limited and, more importantly, did not correspond with the roles used by the LMS. We thought that this would be easy to accommodate.

We thought wrong. As we explored authorization issues in LTI, we found that there was no agreement between learning tools about what other roles could or should do. You would think that there would be common agreement on basic roles like ‘teacher’. Nope, this varies widely from system to system. There was no agreement at all on how these roles and functions should be applied. It was a mess. There are standards of course, but then who determines what is standard.

Partly, we attributed the problem to OLab3 not really supporting Roles. We tried to do some role matching but it proved frustrating. In retrospect, we underestimated the problem and we now note that there are specialty tools and platforms out there whose sole function is role-negotiation.i.e. handling the agreement between tools and platforms as to what the various Roles should be able to do and defining what is intended in role, function etc. Not surprisingly, these role-negotiation platforms are aimed at wealthy enterprises, not small educational tool designers.

Around this time, we were encouraged to explore the use of the Entrada curriculum management system to help with our IAMS issues.

This had many potential advantages: Entrada had full IAMS functions and its needs for roles were very similar to ours. It already used IMS-LTI and it was easy to get authentication established with Entrada as the LTI Consumer, and OLab as the LTI Producer.

However, we still ran into problems with authorization and role definitions. We would have explored this further but other factors forced us to abandon our planned close integration with the Entrada platform.

Another approach that we explored was the use of JSON Web Tokens. Similar to OAuth2, these are a mechanism in which platforms can pass each other user information after satisfactory authentication.

While similar to LTI, using JWT would be simpler and give us, as a small tool developer, much more flexibility in defining needs, functions and capabilities for the authorization process.

This was part of the OLabERATE project. Our team was successful in getting basic authentication and authorization between OLab4 and Moodle established using JWTs. We chose Moodle because it is open-source and open-standard; it is nice and generic in how it handles IAMS functions and has a reputation for being easy to work with at a technical level.

This integration with Moodle solved a lot of IAMS problems for us at a time when we faced increasing demands for integration with corporate and enterprise platforms. The problem came with our user groups: while Moodle is widely used, and is supported by our home university, it is not the primary LMS.

Additionally, as noted in ([cite article by Wirun and Topps about the LMS](Why do medical schools use learning management systems so little?)), medical schools largely eschew the use of an LMS. Students who are enrolled in an LMS are assumed to take courses. But medical schools do not use courses as one of their atomic units in learning management, hence the development of platforms like Entrada.

Our main user groups wanted to use D2L, our institution’s primary LMS, and not Moodle, which is perfectly reasonable. However, the institutional restrictions on integrating with D2L were too onerous for us to support. A classic standoff.

We had hoped not to have to deal with IAMS functions as we moved forwards with OLab 4.5 onwards. Sadly, between the enterprise-level inertia and other pressing demands from small groups who do not care about IAMS issues, we felt we had to improve OLab4’s own handling of IAMS functions. In this, we have made significant progress.

Corey, our senior system architect, has completely revised how OLab 4.7 handles Roles. We have also changed Groups, which were initially a tangential and simplified collection of Users. In principle, this is all now table-driven which means that we can modify how we want to define our groups and roles to function, without having to repeatedly alter our codebase. We can also define what a Role can do differently for different Groups.

While this has the potential for IAMS anarchy and confusion, at this time, it does at least give us maximum flexibility in how we define these functions for various sets of collaborating teachers, researchers and students.

Groups are essentially collections or sets of Users. This is faceted, meaning that a User can belong to multiple groups.

Maps can be assigned to Groups. This is also faceted, meaning that a Map can be accessed by multiple groups.

Users can be assigned to many different Roles. They can have more than one Role within a Group. They can have different Roles in different Groups. And what their Role can do within one Group can be different in another Group.

This is powerful and flexible. It allows us to define Roles quite differently for different groups. And Role flexibility is very useful when testing how different user types (roles) will interact with OLab materials.

At present, our main challenge is in making the administration of this into a simple task. Our System Management Tool, https://smt.olab4.net, is capable but still rather lacking in finesse. It requires a deeper understanding of the underlying principles, which few end-users possess. A work in progress.

While the above describes where we have gotten to and how we got there, there have been other sidebars and parallel attempts to provide similar functionality. Much of this has been project driven, which has also given rise to some naming quirks in the OLab database schema.

During the DynIA project, we had the need to make certain maps available to groups of Users but only at certain predetermined times. We also needed them to work synchronously and asynchronously. During the synchronous sessions, we wanted to provide aggregate reporting on some of the decisions and pathways taken. (This was the genesis of 4R: Rapid Real-time Response Reporting.)

We also planned to use Script Concordance Testing (SCT) in assessing their decision-making. SCT uses near-peer reference groups to determine the amount of agreement or concordance with the “correct” answer.

So for this, we need to define collections or set of Users, along with sets of maps — a container holding both, if you will. We also wanted to define when the maps would be made available to those Users. Sometimes, this would be a small subset of 2-3 maps that could be played together. Sometimes, this would be more rigidly defined and the maps had to be completed in a certain order before they could progress to the next step or map.

This was starting to sound like SCORM and we did not want to get into the complexity, rigidity and overhead of full SCORM compliance for this project.

Because our educational research team at the time was strongly vested in the concept of Scenario-Based Learning (cite Ruth Colvin Clark), we decided to call these collections Scenarios. So a Scenario defined a set of Maps that could be played by a set of Users in a set of Steps (which might or might not dictate the playing sequence, timing, completeness).

Unfortunately, at the time, the European WAVES project was using the term “Scenario” as a synonym for a case or virtual patient map. So, the name ‘Scenario’ is now rather ambiguous. Additionally, the DynIA project which funded our development of Scenarios, was very focused on the use of online webinars for content delivery and group discussions. Independently, the development team ITRex decided to call these collections ‘webinars’. So in the OLab3 database schema, we now have tables named webinars, webinar_maps, webinar_groups, webinar_steps etc.

This table naming is hidden from users playing the maps and Scenarios. By the time we discovered it, the development of this functional area was nearly complete so we decided to leave the misnamed tables as they were. But for analysts who are dealing directly with SQL queries, it does take some explaining as to why this naming structure exists.

The development of the Scenarios container for maps and users in the DynIA project proved to be a useful feature that afforded a number of learning design patterns. Always good to see an innovation thrive beyond the funding period.

The Scenario container firstly defined a set of Users who would all have the same access to the maps of the Scenario. Because we were typically dealing with larger numbers of Users, we also created a container for a set of Users called a Group. This was a simple one->many table and was convenience for adding those Users to a Scenario more quickly. Groups in OLab3 were simple and do not have the more complex relationship to users and maps and roles that you see in OLab 4.7. OLab3’s groups were more similar to the OLab3 Collections which were just a one->many table for maps, again with no deeper relation. Both of these relationships have been deprecated in OLab4.

The Scenario container also defined a set of Maps that these Users could play. Additionally, within each Scenario, we had subsets that we called Steps. This allowed us to partition the Scenario and control when a Step was switched on (made active) or off. Each Step could contain one or more Maps. If you placed multiple Maps into a Step, the user could play these Maps in any order but they were all switched on/off at once.

As well as being able to switch the Steps on/off, we could also make a Step available at a preset date/time (monitored by a cron service), or we could make it conditionally available: this meant that the User had to achieve a specified Counter score on one Step for the next Step to be opened. This led in turn to the development of ‘Conditions’, which were essentially scenario-level Counters, with values that could be altered by any Map in that Step.

In principle, this sophistication of the pattern design was quite powerful and we tried to use it in subsequent projects. However, it remained glitchy and unreliable. This approach has now been deprecated in OLab4. Because we now have scope levels of server and map, we can use server-level Counters instead of Conditions. This is both more flexible and more reliable.

The step-wise approach of OLab3 Scenarios allowed us to explore different learning designs in how we grouped our activities. In the Canuc-PEDS project, we created longitudinal sets of cases where they were to be played in a certain sequence. Additionally, performance in one Step made a difference to how subsequent maps were portrayed. For example, we had a case where the patient had Trisomy 21 (Down Syndrome) and we wanted to convey to the students how dealing some factors in the patient’s early life would have an effect on their wellbeing in later subsequent cases. A different approach to adaptive learning cases.

We also had cases that were aggregated in Steps. This was a simpler relationship and performance in one map did not affect how other maps in that step were portrayed. However, their availability was connected and we did try to use the Conditions in the Scenario to provide basic inter-map communications. Play of these aggregated maps was asynchronous and the use case for them was not strong.

We also attempted to create Scenarios where maps were supposed to be played in parallel or synchronously. While we had lots of good ideas on how this could be made useful, we were not able to make Conditions into a reliable data transport mechanism between maps. In OLab4, this is now strongly supported: as noted above, Conditions in a Scenario have been replaced by server-level Counters and this mechanism has proven reliable at inter-map communications. While designed for synchronous use, we note that OLab 4.7’s architecture does not insist on this and server-level Counter values are preserved between sessions.

Parallel sets of maps are now very feasible. Performance in one map can directly affect another map through these server-level Counters. As described in Ch 16 of our OLab book (UofT Press, 2026), this whole approach now affords lots of different design patterns. For example, you can have players of two parallel maps competing for the same set of shared resources. In our Lifeboat cases, there are two patients alongside each other, both severely injured. You only have enough IV saline for one patient. Do you compete or cooperate? Will you be able to save both (unlikely), just one (probable), or neither (failed). Or you can design case scenarios where the two have to cooperate, that resolution is not possible without each side contributing something to a common knowledge pool (like the design of some murder mysteries).

Over the two decades of OLab’s development, the central database schema has remained remarkably stable and consistent. However, this is less true of the various assemblies of components (maps, users etc). As well as the above structures and containers, we will also mention a few that have gone by the wayside. We do so in order to avoid lost “corporate memory” about certain features and functions that appeared in earlier version of OLab and then dwindled away.

As noted above, these were simple containers of maps, with a simple one->many relationship. This simple group was mostly for convenience. For example, we would group all the maps from one project into a Collection because it made it easier to show the funders what they had supported.

There was no other functional relation between maps in a Collection. Their play did not affect each other. Access to them was not controlled by the Collection. It was effectively just a plain list of maps. But they still proved useful. Gone now and replaced in OLab4 by Groups.

At one stage when we were more closely allied with the LMS for IAMS functions, we started on the use of Courses. These would be similar to OLab3’s Scenarios but the access control would be provided by the host LMS, along with access to ancillary materials.

Because the LMS controls the access control lists for a Course, and indeed, a course is a common atomic unit in the LMS, the OLab4 Course container could be made quite lightweight. This still might be explored but at this point in our OLab4 roadmap, we are not finding a strong enough use case for them.

One of the downsides of development teams acting somewhat independently is that we have seen the genesis of some oddly named assemblies or containers. For example, for a project that was trying to explore longitudinal sets of maps/cases, the dev team decided that we needed a container that they named “Patients”. We mention it now because you still might come across their dessicated remains in older OLab versions.

We dropped this term quite quickly for a number of reasons: at the time, we were already in cheerful academic debate with the WAVES about the term ‘Scenario’. Primarily, they wanted to demedicalize our maps/cases and convey that they did not have to be about medicine or patients at all. Another group pointed out that in some disciplines like family medicine, episodes and events are not the same: that you can have acute on chronic disease, where long term factors interact with short term factors, and that within the same patient, you will have many different but often overlapping conditions cropping up in their lifetime. Another group pointed out that family medicine is about families and that different family members often interact in ways that affect the family’s health. So, as a container for maps/cases, it did not make sense to call it a ‘Patient’.

Another inconveniently named container was ‘Sets’. This was dropped, partly because we were (yes, the mathematicians would roll their eyes) using the term ‘sets’ as a catch-all (as it usually is) and so we would then have ‘Sets’ and ‘sets’, which is about as bad as being “small-c conservative”.

Keeping the nomenclature straight and consistent over two decades has often been challenging. Look at our primary atomic unit: maps/cases/patients/scenarios/labyrinths. Just one example of confusing names for the same thing. We try to keep our Glossary up to date as a reference, which might help some things: Glossary | OLab4 Help — while this is embedded in a Help system with full version control (Gitbooks), we still mount the actual glossary table in a Google Drive worksheet for easier external maintenance, shared editing and publications.