Case Related User Details (CRUD)

Authors

David Topps

Corey Wirun

Michelle Cullen

Proposal

That we seek a small amount of funding, as part of a future project, to include this functionality to make it easier for case authors to provide user guides and instructional materials to accompany the case or scenario.

Problem

Several projects have requested that we help authors to create context-specific documents to accompany the cases that are to be loaded into their repositories. https://openlabyrinth.ca/instructor-guides-for-cases/ We have encountered this with the following projects so far: TIDE/Norlien, WAVES, DynIA, SHARC-FM and Virtu-WIL.

It would be good if we could come up with a way to generate case-specific instructore guides. This would also help with things like the metadata for cases stored in OERs. Maybe this should be part of the OPENERS and PORTERS services. See OLab extensions, plugins and external services.docx (sharepoint.com) and olabrats. https://olabrats.atlassian.net/browse/REP-23

Functional Requirements

A simple to use mechanism where you can generate a PDF document, that automatically includes case-specific metadata.

This would also help if you have a situation where the user is making a duplicate or importing a map. If the external guide can still reference the correct node locations within the map, you have a much greater degree of cross-referencing power. The concept of Embedded Relative Links (which needs a better name and was first raised in OLab3) is relevant here:

In OLab4, this could be made more generic by using Scoped Objects.

In principle, this can be achieved by using the Session Report tool in OLab3. In OLab4, we would extend this concept and use the same approach as we have taken in generating other session reports, based on the use of the Player’s rendering engine.

If the user prints it as a PDF, the metadata details would be included. You could use the rendering engine in the player to convert the Scoped Objects into their relevant content, just as we planned to do with the Session Reports in OLab4.

Items to make case-specific

Patient – use map-level Constants for firstname, lastname, age, gender, pronouns

Case:

For OLab3, many of these will be difficult
Starting URL – can you grab this from the [reset] button?

See sidebar Comments – complicated to do
Might be easier to do it by grabbing the URL of the current page and then doing some string extraction, especially since the start point is usually the mapID followed by zero IIRC.
Or one of the internal Scope Object Constants

Particular Nodes of interest – a milestone or bookmark where the user is advised to check the User Guide or Instructor Guide. It would also be helpful to have anchors/bookmarks within the larger help text: this can be done with TiddlyWiki and GitBooks and Google Docs and Google Slides

System Constants

In OLab4 session reports, we are able to report this information’s current state prior to case completion. These could be extended by System Constants and System Counters, such as we have for things like the NodeID, MapID – there is a little info in this: Shortcodes in OLab4 – Google Sheets

which provides the current list of System Constants and Counters that are currently available.

We propose that some other values would be helpful:

```
ServerName 
```
```
ServerURL  
```
```
PlayerURL 
```
```
DesignerURL 
```
```
MapKeywords  
```
```
MapAbstract 
```
```
MapFeedback 
```
```
MapDevNotes 
```

MapVerification – not yet developed in OLab4 but there is some case production metadata in OLab3 that may need to be included.

```
MapCreatedAt 
```
```
MapUpdatedAt 
```
```
MapReportNodeID 
```

MapDocumentNodeID – see above comments about the plans of IEH to use maps.report_node_id and the question as to whether we need a new column in the maps table to cover this?

We should consider, especially for URLs, whether we make these Constants absolute or relative/concatenable? I.e. an absolute referencing style would contain the whole string needed e.g. ‘https://player.olab4.net/1401/28025’ ; whereas a relative reference would do it like this? ‘[[CONST:ServerURL]]/[[CONST:PlayerURL]]/[[CONST:”MapId”]]/[[CONST:”NodeId”]]’ — there are pros and cons to each approach that would need to be considered and investigated. For example, with the relative reference example given, we are assuming that the Player uses a domain sub-string (e.g. ‘ThisServerName/player’), whereas in practice, we are generally using sub-domains (‘player.ThisServerName’). It may be that we have to use absolute references if we want to make the URL Constants into live hyperlinks.

We put a few short notes into https://player.olab4.net/1401/36386 – the Help and Infobuttons map, as a bookmark for future.

See also case example on Tech Support: Tech support case.docx (sharepoint.com)

Absolute vs Relative references

In some ways, you now create the issue where you need relative references, vs absolute references. We had that a wee bit with Embeddable Relative Links in OLab3 (and discussed but not properly implemented in OLab4.0). See https://demo.openlabyrinth.ca/labyrinthManager/global/463 which illustrates this concept.

It is not so hard to create a CRUD hyperlink that points back to the current Node in the Map. We did that already to a small extent when working on the Feedbacck in map 350 and a couple of others for the Virtu-WIL Project for CICan. But what about if the Node is offset from the current Node? Can we navigate by named Nodes, vs Node ID numbers? We have named Counters, Constants etc. But do we have the ability to [[LINK:namedNode]] or [[JUMP:namedNode]] – maybe. I can’t remember. That would solve the problem to some degree. See https://olabrats.atlassian.net/browse/OL-56

Controlling who can see this information

In some cases, you will not want to make the instructor guide widely available.

For this we could use Role-Based Node Access (RBNA) to control access to some of the more sensitive areas of the case, or content details. See https://olab.ca/role-based-node-access-in-olab4/