Previous blog posts have discussed the issues surrounding the license issues of using Destinations® for the content widget functionalities, and those issues have been solved for usage inside BB – not for general open widget purposes.
I’ve started the technical work on this, and I have created the first B2 that imports content from Destinations® into BB. But there are several technical issues that presents themselves at this stage.
1. The import
The actual code that is imported is an exact copy of the Destinations® website without CSS (look’n’feel code), so it look ugly, to the extend that it is unusable. This is an issue that can be solved. The bigger issue is that all links are relative (normal good practice), but they obviously break once in a B2, because the links will link to pages in BB, which won’t exist.
The easy solution is to create links or buttons that the user interacts with depending on the needed content, and load the pages in the normal way in the iFrames. I’ve already done that at the top level, but it poses one big almost philosophical question: Why are we doing this as a widget/plugin? This is something that anyone can achieve inserting a normal URL/link in a post! Ok, we could aid the lecturer by making it easier to access different parts of the Destinations® website and make embedding simpler in a mashup interface (special feature for importing content into posts in BB). This brings us to the second issue.
2. Structure of Destinations®
To do this we would need an API or a RESTFUL interface to Destinations® as the mashup functionality relies on access to content in a consistent manner (APIs and RESTFUL interfaces do that). Unfortunately Destinations® does not have that. Everything is not lost, as an “dummy” API could be developed by us, and used to access the different parts of Destinations®. For this to work we would need 1 of 2 scenarios to be true:
- Destinations® never changes so that the “dummy” API wouldn’t need changes
- Sustained funding to keep updates every time Destinations® changes
Unfortunately Destinations® does change, or at least it has done in the past. For instance I remember it containing a Computer Science link under subject, and indeed the source code behind Destinations® clearly shows that it once existed, as it has been commented out.
This might not be such a big problem if the names where following a consistent scheme (RESTFUL interface), as we would then always be able to test whether a certain subject existed or not before showing the possibility to the end user.
Unfortunately there are proof that this is not the case. First of all the URLs that are used, although seemingly following a consistent pattern using units of information is not using an easy to follow naming convention. The documentation for staff on the site also shows that in the “Technical documentation”. Here the different topics, subjects etc. are ordered in a spreadsheet with accompanying “Unit” and “Object” filenames, and it is clear that there is no easy connection between the title of a site and the filename, and I suspect the scheme that has been used it the order in which they have been created. This is obviously not helpful when trying to “guess” the filename based, for example, on the name of a subject area.
The clever reader would then, probably, think: Why don’t you just use the spreadsheet to convert between title and filename?
Unfortunately the spreadsheet is either out-of-date or wrong for some of the entries. Take for instance the “Preparation is key!” site, which according the the sheet should be named “unit-af004” is on the live server called “unit-af010”.
So what can we conclude from this?
We could create a simple solution that enable users to insert links to Destinations® inside BB. This I believe is a very simple solution, which does not give any extra benefits to any of the stakeholders – University of Reading, JISC, academic staff, students – none of them! This is because the solution is so simple that it already exist in the normal BB functionality – You just find a link inside Destinations® and import it into BB.
Otherwise we can create some other content widget solution. I’ve already started testing how easy/difficult it would be to do that with APIs available on the web (Guardian OpenContent API in the first instance) – watch this space! The benefit of this approach is that we’ll also be able to test this using IMS Basic LTI, which I believe is something that JISC would like to see.
I’ve also started to investigate the possibility of importing information from RISIS (Tribal’s SITS) to BB. This is something that could potentially be a very powerful combination for staff and students at UoR.