To facilitate sharing of cases between schools, it is helpful if there is an Instructor Guide (not same as the User Guide for OpenLabyrinth) for each case. This gives some tips to teachers about how best to use the case, special features, learning objectives etc.

At the moment, there is not a common repository for these. When cases are fully published, the Instructor Guides will be available via MedEdPortal. (MedEdPortal requires an Instructor Guide as part of the submission.)

Until recently, we had no particular place to put ’em in a case either. So they only were sent along with a case, if the author remembered.

I am now pleased to say that we can now embed them directly into the case:

1. Upload the guide into the Files section for the case.
2. In the case Details, near the bottom, in a poorly named section called ‘Labyrinth verification’, you will see the last button says ‘Instructor guide complete’.
3. When you click on [Yes], it then provides a drop-own list of stuff from that case’s Files section. Simply point to the guide.
4. [Save changes] blue button at bottom.

Now your Instructor Guide can be moved along with the case when you Export it.

Some sites might be concerned that this is ‘giving away the answers’ along with the test. Taking the above approach does not immediately make the Instructor Guide available to learners; only to authors. You have to embed a link to the Instructor Guide in one of the Nodes if you want learners to see it.

Some of our authors have taken a neat approach where they hide the Instructor Guide in a node behind a password. Then they can control who gets to see the Instructor Guide, without providing author access to the case.

We’ll cover how to use password-protected Nodes in another issue in the blog.

There have been so many changes to OLab3. And, as usual, the documentation is woefully behind.

So I am very grateful to some authors from our SharcTOOTH project who have spent many hours in updating and reorganizing the User Guide.

The official guide for v3.1 of OpenLabyrinth is available from

http://openlabyrinth.ca/wp-content/uploads/2014/02/OpenLabyrinth-v3.1User-Guide.docx

This is always a work in progress – we aim to migrate it from its current state as a MS Word docx file to a wiki, using Atlassian Confluence. This will make it much easier to multiple authors to keep the guide updated, without worrying about version control etc.

While the guide is still being actively updated, the best place to grab the most recent (cluttered) version from is my Dropbox account:

https://dl.dropboxusercontent.com/u/3159431/openLabyrinth_UserGuide_v5m.docx

If anybody has expertise with Confluence and would like to help us migrate this behemoth of a document, I’d love to hear from them. Email us at

info AT openlabyrinth DOT ca

The dev team has created a whole bunch of small improvements in v3.1.1

These improvements are particularly useful for advanced developers and teams.

As usual with a new release, there are likely also some glitches, so if you are using OLab in a production environment where stability is paramount, we suggest that you stick to v3.1 for the moment.

For those who want it, v3.1.1 can be downloaded from Github at

https://github.com/olab/Open-Labyrinth/releases/tag/v3.1.1

The dev team have done a wonderful job in placing some safeguards that help prevent team members from overwriting each others’ work.

Increasingly, we find that great cases are a team effort. But not many virtual patient authoring platforms out there support team authoring. The collaborative touches that we mentioned in January have been improved.

But the big thing is that there is now a check-out mechanism in place. When one author starts editing in a case, other authors are prevented from working in conflicting areas. Some of the editing modules like the Visual Editor open the entire labyrinth at once. So, when such a tool is in use, many other dev tools are locked for that case by OLab.

But when an author is working with a tool that is more focused, such as the Node Editor, only that node in that case is locked. So two authors can be working in two separate areas of the case concurrently.

This is not completely bullet-proof. There is only so much that is feasible in a browser environment, given the funds that we have. But it generally works pretty well and has saved my bacon several times now over the past couple of weeks while we had a team working on some competition cases.