Alex Little

I was at the UNFOLD meeting last week – a way of catching up on what everyone else is up to in the field of learning design. I came away with some more ideas about what to do with the development of the player. One of the key aspects that seemed to come out of the meeting – especially from people new-ish to LD – was the lack of sample LD packages to look at, something that the UNFOLD team are going to try and resolve!

I guess the main thing for me was that no-one was particularly sure what an LD player should actually look like – so this is good news for me! as it means that people won’t have too high expectations of what I come up with Also, once the player is ready at least it will be a starting point, from which people will be able to say whether or not they like it and whether it’s heading in the right direction.

The next step for me, now that I’ve created some sample content, is to look at how to display the global properties (in LD level B spec) and also allow users to be able to edit these properties (where necessary).

Have been spending most of the day trying to create some new LD content, based on an existing internal staff development course. Fortunately the material is already well seperated into learning objects, activities and the services (forums/discussion areas) are easy to spot to.

I am however finding it very slow going actually creating the XML for the LD – which I’m doing in ‘raw’ xml format, using an existing simple LD as a starting template. The three main problems I’m coming across are:…. 1. the ‘titles’ for the learning objects, environment activites etc all seem to need to be repeated, eg for the actual node title and then for the item node title. 2. I’m getting a bit mixed up with the identifiers and identifier-refs and where each of them should be pointing to. 3. the final problem is that although I can successfully upload any changes I make to test and it all gets validated fine, coppercore (or the player) is caching the previous results, making it hard for me to see whether or not my changes have been successful.

Have now done quite a lot to catch up on where I left off in July – well at least I’ve now remembered what I was actually doing!

Have spent some time today trying to exlain to people some of the conceptual issues/problems I’ve been having. For example, trying to work out what the player should _actually_ look like to users, without using lots of frames or iframes to display the content to the user. Because the LD spec is designed to be generic (in that the content of the activities/environments etc can be any file type) this can create problems in creating a generic player to show any of this back to the user in a single web page – hence the suggestion of using frames, or breaking out into new windows. The problem with breaking into new windows is that the player could just end up looking like a whole list of links for the user to follow, which may not be very engaging!

Also trying to encourage people to put some more content together, which will help me loads in seeing how the player should look.

This is all before (of course) I get on to looking at how the services should be interoperating with the player and how the conditions/properties should be incorporated when we get on to looking at level B and C content

Haven’t been any updates to tell anyone about for a little while as I’ve been away on holiday for the past month and am trying to get back into ‘work mode’ again

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.