We have introduced a simple but flexible online help system for using along with your OpenLabyrinth cases.

Building upon the work that we did before,  we are now delighted to find that the new version is much easier to work with.

Check out this example case, showing all sorts of different ways to provide help and other information within an OpenLabyrinth case: http://vp.openlabyrinth.ca/renderLabyrinth/index/51

In particular, take a look at this page: http://vp.openlabyrinth.ca/renderLabyrinth/go/51/2572

This makes it very easy to incorporate into established OpenLabyrinth servers. But it also means that case authors can easily adapt it to create help files that are specific to their own cases.

The new approach makes it quite easy now to have …

1. authors can easily make custom help pages for their own cases

2. users can now edit the page and download it to save their changes. Note that these user-created annotations are not saved on the original file on the OpenLabyrinth server, so the case author’s carefully crafted help file is not affected.

SharcFM is a collaborative project, supported by the College of Family Physicians of Canada (CFPC), http://cfpc.ca, around shared curriculum and learning objects for Family Medicine.

SharcFM was launched a couple of years ago and is steered by the CUFMED group (family medicine clerkship directors across the country) to bring together a number of shared objects, cases and clinical cards. OpenLabyrinth, as an open-source, open-standards platform, has provided one of the tools by which such content is shared.

We received some funding a few months ago to bring the collection of virtual patient cases up to full speed. Based on the learning objectives specified by the CUFMED group, (https://sites.google.com/site/sharcfm/sharc-fm-home), our small group of clinical authors have been busily assembling cases, instructor guides and ancillary materials to support this project.

Watch this space next month when we announce the full list of SharcFM cases.

We have been asked quite a few times whether we are considering doing an app for OpenLabyrinth. The short answer? Not at the moment.

We have focused on ‘responsive design‘ in our OpenLabyrinth interface when cases are being played. This means that the material on the screen scales quite well to the screen size so it is usable on phones, tablets or big screens. For an example of this, check out the

‘Street Drug Guide‘

that we developed for AFMC and Norlien. This case has been tuned for mobile use but we would love to have suggestions on how to make it more useful and portable.

So why no app? Well, funding is one thing – if there is a group that is keen to fund this or to take it on, OpenLabyrinth is an open-source application so anybody can have a go at this.

But more importantly, we wonder how much benefit there is to doing this. A simple app would lose all the background power (metrics, tracking, conditional logic) that the OpenLabyrinth server provides. You would still get linked pages but is that enough?

There are a number of sites that do offer app conversion and other reasons for/against doing so e.g. http://www.forbes.com/sites/work-in-progress/2013/09/05/how-to-make-your-website-mobile-friendly-on-a-budget/

If you do have ideas on how mobile can be explored further, we would love to hear from you.

You can use simple passwords in your OpenLabyrinth cases to restrict access to parts of your case, using a hidden node.

This is a bit fiddly to do at present, primarily for advanced authors. (To be refined.)

1. In your case map, using Visual Editor, create a new node that is not linked to any other. Once you have updated the master map, make a note of the Node ID number for this hidden node.

2. Create a single-line QUestion in the case, in the usual fashion.

3. Within the Rules for that QUestion, you will use a basic syntax something like this…

The first line says to go to Node 12757 if the answer is blank. The second line says to go to Node 12758 if there is a successful match (but you wouldn’t use something as obvious as “password”, would you? (Yes, I know that millions do!)). The third line tells OLab what to do if there is no match for what has been entered.

Using this approach, the author can control where in the case the User ends up, depending on what they answer. This same approach was originally designed for basic interpretation of free-text entries. But several authors have found this useful for providing password-only access to their Instructor Guides (see previous post).