Objects
All about Scoped Objects
Overview
In OLab4, we have introduced the concept of Scoped Objects, with the idea of making the authoring process more efficient. By making Objects reusable and shareable across Maps, the author has to spend less time reinventing the wheel or making multiple copies of the same item. See below for more information about Scope.
Questions
The commonest object that the author will use in their map designs is the Question. OLab4 supports many different Question types, some of which are interchangeable. The author can create or edit Questions using the Question Editor. In the Designer top menu, Objects, you can select Questions from the drop-down menu.
The list of Questions can be searched, just like you can for the list of Maps.
In this screenshot, we can see that the author is searching for the word 'test'. You can cslect a Question to edit it. Or you can create a new Question using the big blue button in the top right corner.
Most of the things that you edit in the Question Editor are fairly self-explanatory, so we have focused here on describing the notable items for each question type.
Single-line Text
The validator helps to make sure that the data entered conforms to a specific format, such as email address or phone number.
When the user presses Enter, the contents for that field are stored.
Multi-line Text
This allows the user to enter much more text. While the size of the input box can be edited by the author, the user can stretch this box during player mode.
Single Choice
Also known as ‘radio buttons’, the user can only pick one of the choices. The author can create as many choices as they wish. A Counter can be attached to the Question.
Single Choice options
Response - the text that indicates how you are responding with that choice
Correct - whether the user should see a clue about if the response is true
Feedback - a small popup text box with more clues
Score - apply a positive or negative score to a Counter. (Remember to select the Counter)
Multiple Choice
Also known as check boxes, the user can select as many of the choices as they wish. Otherwise, these are identical to Single Choice questions, with the same options.
Script Concordance
These are really a special type of Single Choice question. Typically they have 5 choices but this is not mandatory. Their design is largely the same as a Single Choice question and they appear similar to the user during player mode.
They are scored differently during session reporting. This is seeing little use and may be deprecated from future versions.
Slider
There are various styles of sliders. A Counter can be attached to the question. Counter scores and slider numbers are not identical.
Drag & Drop
This is a vertical array of responses that can be dragged into a new order by the user, using the mouse. There is not a standard method for scoring the correctness of the responses.
Situational Judgement
This is really a special type of Drag & Drop question. Typically they have 5 choices but this is not mandatory. Their design is largely the same as a Drag & Drop question and they appear similar to the user during player mode.
They are scored differently during session reporting. This is seeing little use and may be deprecated from future versions.
Rich Text
This is a special type of multi-line text question, which allows the user to include rich text formatting in the response. They can make the text bold, underlined, italic etc.
Cumulative
This question type will be deprecated. It was used very little
Chat
This question type will be deprecated. It was used very little. It may be revamped as a Clue-type question.
Grids
This question type has been deferred at present, pending further funding
Counters
These can be thought of as variables, in programming terms. They are typically used to track user progress or performance but can also be used to control the flow of a scenario or map.
The value of a Counter can be set in several different ways and can be one of three types:
Integer
String
Floating point value
OLab4 does not care what type you use but you will get unpredictable behaviour if you flip between types within any single Counter.
You can display all the Counter values for a Node by inserting the shortcode [[COUNTERS]] into the Node’s text or into the Theme for that Map.
You can display a single Counter’s value anywhere on a Node by inserting the shortcode [[CR:name]] or [[CR:nnn]] (where name is the Counter name or nnn is the Counter’s ID number).
Counter Grid
This is the simplest method for altering a Counter’s value. During player mode, when the user visits the Node, the Counter’s value is altered according to the grid.
This was lost in the transition from OLab 4.0 to 4.5 -- we will bring this back when we get a chance.
You can set a value, using the ‘=’ sign.
You can increment an integer or float value, using the ‘+’ sign.
You can decrement an integer or float value, using the ‘-’ sign.
You can set whether a Counter is displayed in the [[COUNTERS]] area when that Node is played.
Counters and Questions
You can attach a Counter to a Question. The Counter’s value is altered when the user responds to the question during player mode. The Response Score sets how the Counter is altered.
You can only use integer values at present in system_question_responses.score
Counters and Scripts
The value of a Counter can also be altered by a Script Object. A Script can also monitor the value of a Counter and act upon it.
Scripts have replaced the Rules that we used in OLab3.
Media Files
You can attach files and media to a map and display them in any Node. Of course, you can also insert a reference to an external file on another server. The advantage of using internal files is that you have more control over their availability and format but there are also downsides such as copyright, large file sizes and display times.
Media and files can be displayed or downloaded by the user during player mode. Usually a media file will simply be displayed if the shortcode [[MR:name]] or [[MR:nnn]] is placed into the text of a Node (where name is the object name or nnn is the object’s ID number).
We have decided to deprecate the use of the DL:nn shortcode, that is discussed below
For some file or media types, this can cause some issues and the author may wish to give the user the choice of whether to download the object, rather than simply playing it. In this case, the author should use the shortcode [[DL:name]] or [[DL:nnn]] is placed into the text of a Node (where name is the object name or nnn is the object’s ID number).
Media File attributes
Name -- this is the identifier known as a ‘friendly name’. It should allude to its purpose
ID -- this is the internal ID number (‘nnn’ in the above shortcodes)
Description -- a slightly longer note about the intended purpose or contents
Copyright -- usually © or Creative Commons
Source -- the URL of where the file was found
Width & height -- dimensions when displayed
Size -- not editable. The filesize in kB etc
Embedded -- toggle for which filestore to use (to be deprecated)
Note that you cannot edit images within OLab4. While this was previously feasible in OLab3, we found that there are many excellent tools out there already that you can use to alter images. To keep OLab4 simple, we left out this functionality.
Constants
These can be used to insert a chunk of text, using the shortcode [[CONST:name]]. You can also add a simple image along with this text, such as an icon. For bigger images, use the Files option above.
They are like a macro or shortcut or boilerplate text -- the author assigns a value to the Constant during design mode. The value does not change in player mode.
Constant attributes
Name -- this is the identifier known as a ‘friendly name’. It should allude to its purpose
ID -- this is the internal ID number (‘nnn’ in the above shortcodes)
Description -- a slightly longer note about the intended purpose or contents
Value -- this should be HTML formatted. It can include an internal image. It cannot contain shortcodes to other OLab Objects.
Note that you may need to manually insert correct HTML markup here. This is not yet handled automatically.
Scope for Objects
All of the above object types (and some others) can be assigned to a scope. The purpose of this is to promote the concept of reusable objects. You could do this to some extent in OLab3 but it was a bit of a kludge. In OLab4, this is now quite powerful.
There has been some discussion about having Node-level scope. At present, this is undecided.
Map-level scope
An object that is attached to a Map as its scope can only be used within that Map. It can be reused many times within that Map, across many different Nodes. If an object is used more than once in the same Node, the behaviour may be unpredictable.
Course-level scope
A Course is a set of Maps that is connected, both logically and to a defined set of users. An object that is attached to a Course as its scope can only be used within that Course. It can be reused many times within that Course, across many different Maps and Nodes.
Server-level scope
An object that is attached to a Server as its scope can only be used within that Server. It can be reused many times within that Server, across many different Maps and Courses.
For really popular objects, a lot of time can be saved by creating a library of such objects that authors can reuse over and over again.
Server-level Counters are not necessarily reset for each map. Their values can also be altered by more than one map at the same time. This allows the author to create Maps that interact with each other using a common Counter. See example at https://olab.ca/olab4-maps-interact-through-server-level-counters/
Global scope
An object that is set to be Global in scope is shared by all OLab4 servers. This sounds like it would be the commonest, most powerful and most reusable of the scopes. But it also has lots of limitations.
We will use a GitHub repository to manage version control of objects with Global Scope. We may also implement a central LRS to manage Global Counters, if a good use case is made for them.
Generally, we anticipate that there will be a few Media files (such as help files) that have Global scope and possibly a very few Questions. Server-level scope will be much more commonly used.
Roles and Scope
There is an authoring hierarchy as to who can create and edit objects at various scope levels.
Map-level objects can be edited by an author who has access to that Map
Course-level objects can be edited by a director who has access to that Course
Server-level objects can only be edited by an admin who has access to that Server
Global-level objects can only be edited by a dev with global permissions
Local copies can be made of higher level scoped objects. For example, a map author may make a copy of a server-level object and then modify it for use within that map-level scope. Such edits do not propagate back to the parent object, or down from the parent to the child object after it has been created.
Naming of Objects
In OLab4, we introduced names for Objects, instead of the numbering system used by OLab3. Objects that are imported from OLab3 maps will still have numbers for names -- we encourage authors to change these meaningful names.
There are a few things to be aware of when naming your Objects:
OLab does not check for duplicate Object names - it is up to the author to resolve this. Using map-level scope will help to some degree so that you do not have to check for all possible duplicate names. We ask authors to be particularly careful when they are creating server-level Scoped Objects.
Avoid the use of these characters in an Object's name: &#$%_@!*
Spaces are allowed
Note that the underscore is not allowed
This list is not fully tested. For example, there may also be problems with the colon
Last updated
