Last thing on Friday last week, I received the first update to the CopperCore engine from Hubert and Harrie at OUNL. This extends the coppercore engine to be level B compliant and they given a couple more examples.
I’ve spent the last day or so getting this up and running – the installation is almost identical to the previous version, so not too complicated. Once I had it up and running I found that I needed to make a couple of minor changes/additions to the code tht I’d written for the LD Player. This was because my player was connecting directly via internal java calls and eventually there will be a web services wrapper around coppercore, so this would not be too much of a problem.
Was on a UML training course yesterday, quite interesting, though it was fairly rushed, so should probably spend a bit of time going through the slides again and make some effort to use it in the near future, before I forget it all!
Spent most of the day today getting some of the Player and authoring tool bits and pieces written up. I’ve now made the very first version of the player and authoring tools available for people to download (see links on left). The instrcutions probably leave a little to be desired but I can work on those. Probably the best plan for that is just to get someone else to have a go and see when they end up having problems.
Have now got simple search and forum applications set up the LD player can connect to using web services. There’s only a fairly basic set of functionality available at the moment for these, but I think thats probably all that’s needs as a proof of concept, it should be easy enough to see how this could be extended.
So far I;ve tested the search tool with the Knowledge Network search and a Google search, it’s quite straighforward to swap the tools over. I’ve only tried interacting with one forum application, that’s the one on the knowledge network, but I’m hoping to be able to get access to the web services (and a test user id) for the FirstClass conferencing system, used here at the OU
I now need to spend a bit of time doing some writing up – so I don;t leave it all till the last minute ;-). Also Patrick mentioned that the authoring tool download doesn’t give the user the generated xml LD file, so I’ll need to check up on getting that fixed. I think this is because the javazoom upload bean library needs to be included – this is the code that handles the upload of the resource files.
Right… I think we’ve got it sorted out now! I can create some java code which will act as the interface between the LD Player and the actual tools. The player will then just have a predefined set of methods that can be applied for each tool (search, forum etc). The interface will then be the ‘local environment description’ (LED for short!). That way, if the tool thats needed to provide the service needs to be changed, all that needs updating is the code for the LED, not the whole code for the player… if that makes sense. The tools can then appear to be ‘part of’ the LD Player, ie have the same design/header etc, and the tools can be switched without the user noticing any difference.
On the downside of this, the player will only have a preset number of methods and to take advantage of some whizzy thing that one of the tools does (which isn’t a generic function of the other tools in that category), then both the LD Player and the LED will need updating. However, I think that the ease at which tools can be switched in and out, along with the fact that end users only have one interface whatever the actual tool they’re using behind the scenes, outweighs this disadvantage.
Anyone who knows anything about the OKI OSIDs will probably be thinking – that’s just what OSIDs do, so why aren’t you using that method? Yes, what I’ve descibed is based on the ideas used in OSIDs, but the reason that I haven’t actually used the OSID definitions is mainly because I don’t understand enough about them (!) and for the scope of this project I don’t think I’ll have time to get fully up to speed on it. Also the OKI OSIDs are still in their initial phases and there aren’t many tools around yet compatible with them. However, there should be no reason why a future development of this LD Player shouldn’t be to change to using OSIDs.
Here’s the ‘conceptual’ problem I’m having, which may help to explain my options mentioned yesterday:
The problem I’m having is that I can quite see how the user interactions with the services would get passed back and forth to the player. I know that we can use web services, but I’m getting confused as to what the user would actually see on screen when they go off to a forum service for example, and also how I could actually code this. I wonder if someone can help me sort out where I may be getting confused!…
If I take the forum as an example?. If the learning design says that someone needs to post a message to a forum before they can proceed to the next activity, the user will see a link to the forum, but what happens when they click on this link – do they go directly to the tool (eg firstclass) – in which case how does the tool inform the LD player that the user has posted a comment in the relevant forum? Or, when the user clicks on the link to the tool, are they shown an ‘LD player’ version of the tool – in this example the user would see a form to post a message, then when the user clicks submit the message is posted to the firstclass conference via a web service and the LD player would know that the user has posted a message. In this case the tools that are connected to would need to have web service interfaces to them – so doesn?t this limit the tools that can be used with the learning design?
Was at the JISC Joint Programmes meeting the past couple of days, with the other projects in the eLearning Frameworks program and giving an update as to how far we’ve come.
This week, I’ve mainly been looking at how to interface the player with the environment tools. I’m still not totally sure of the best way to go about it. I’ve got a couple of options (I think!), each of which have their own +ves and -ves:
use the OKI OSID method. This could be the best way to go, though I think that it may be a bit too heavyweight for what we actually need. Although I’ve been on an OKI workshop, I’m not sure I understand it sufficiently well to write the interfaces required.
The other option is it just to directly write a .jar file which the player can connect to. This can then use web services to connect to the various tools and act as the interface between the player and the environment. The good thing about this is that I already know what I need to do and so should be relatively straightforward for me to implement. The downside to this method is that to change any of the tools used could require some changes to the code. However it would only be the .jar that needed updating rather than the whole player code.
I’ve got the authoring tool packaged up and the instructions written (see the links on the left). But I still need to get the templates sorted out so that people can select which tools/services they’d like to use for each activity. This shouldn’t be too hard to do though once I’ve decided how I’m going to do it.
Authoring tool is coming on very well now. Have got a system in place so that new templates can be added without amending the java code. I’ve learnt a few new bits of java this week too, namely, uploading a file to the server and creating a zip of these files to download back to the user.
I’ve now got to write up a short presentation on how things are progressing ready for the JISC meeting in Brighton next week.