OLab4 Help
Search…
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.

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. The description allows the author to describe the purpose of this question -- this can help with reusability. The stem is like the label for the question.
**insert img of Question List and the first page of the Question Editor
Most of the attributes that you set 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.

Pick 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.

Pick Choice options

  • Response
  • Correct
  • Feedback
  • Score

Multiple Choice

Also known as check boxes, the user can select as many of the choices as they wish. Othewise, these are identical to Pick Choice questions, with the same options.

Script Concordance

These are really a special type of Pick Choice question. Typically they have 5 choices but this is not mandatory. Their design is largely the same as a Pick Choice question and they appear similar to the user during player mode.
They are scored differently during session reporting.

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.

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

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 may get unreliable 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.
Node Editor showing a single Counter shortcode
See the Counter value displayed in the middle of the Node
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.
Counter Grid which shows how values change as you move from Node to Node
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 and how browser loads
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 and maybe an image into a Node. 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 can be simple text or HTML. It can include an internal image.

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.