This is a relatively new concept in OLab4, compared to OpenLabyrinth v3. The idea of being able to reuse various objects within a map is not a new one. Even in OpenLabyrinth v3, we were able to reuse a lot of existing objects across multiple maps. (See note below on what worked and what did not). This practice really helped to accelerate the design of some cases.
In the new OLab4 architecture, the concept of reusable Scoped Objects has been greatly extended. We are referring to the following types of objects that can be inserted into a Node page:
- Files & media
- Questions – interactive widgets, like survey questions
- Constants – static elements that always display the same way
- Counters – consider these as variables; used to store scores and other data
In OpenLabyrinth v3, officially, all objects within a map were constrained to the scope of that map. You were supposed to make copies of such objects if they were used in another map. This helped to make the maps easily exportable to another OpenLabyrinth v3 server. But, as noted above, in practice there was a lot of cheating and reuse of objects across maps.
The idea of Scoped Objects is to provide a hierarchy of objects that can be easily reused more broadly across many maps, or even Scenarios or Servers.
At its lowest level or smallest scope, we still have map-level scope. This means that the object has only been used within this particular map — a local copy, as it were. This is what OpenLabyrinth v3 used for everything.
A.k.a. ‘Scenario level’ (Scenarios now renamed to Courses). A Course is a set of maps that are functionally related to each other, often with the same set of users. An object that has Course-level scope can be reused across any of the maps within the Course.
These objects are shared by all maps on that OLab4 server. Typically, only an Administrator can edit server-level objects.
These objects are shared by all OLab4 servers. Typically they are part of the initial distribution of OLab4 code and resources. We have not yet worked out the repository and version-control mechanism. Two possible methods have been suggested: Github or as static objects on a central LRS. Github would provide better version control and distribution.
So, who can access and edit these objects? A map author can create, edit and use a map-level object in their map, much as before. They can also use/insert an object which has broader scope (Course, Server, Global) into their map but they cannot edit it. They can make a copy of a higher level (broader scope) object, edit or customize it, and save that as a map-level object and then insert that into their map.
Further up the tree of objects, an Administrator can edit Server-level and lower level objects. It would be rude to edit another author’s map-level objects without their permission, but the scope permissions would allow it. In such an event, it would be more proper to take a lower level object and save a copy to a higher scope level, and refine it for more broadly scoped use. Thereafter, this object can be reused by others, without fear that another author will edit it. Only Admins can edit objects at higher scope levels.