As I’ve already publically declared my love for widgets, I was delighted to co-chair the “planning and designing learning in a world of widgets and web 2.0″ with Wilbert Kraan at this years CETIS conference.
Wilbert started the session with an overview of his experiences of building an assessment widget using google docs and sprout builder and integrating it into moodle. The gory details are available from his blog.
One of the many appealing traits of widgets is that they are relatively simple to create and integrate into websites (particularly using wysiswyg builders such as sproutbuilder). However integrating widgets into closed systems such as VLEs can be problematic and generally would require a level of admin rights which most teachers (and learners) are unlikely to have.
This is one area that the TenCompetence project team at the University of Bolton has been investigating. Scott Wilson demoed the Wookie widget server they have built. By adding the wookie plug-in to moodle it is possible to seemlesly integrate widgets to the learning environment. Scott explained how they have been using the W3C widget guidelines to build widgets and also to convert widgets/gadgets from the Apple apps collection to put into wookie and therefore into moodle. This potentially gives teachers (and students) a whole range of additional tools/activities in addition to the standard features that most VLEs come with. A USP of the Bolton project is that they are the first to build collaborative widgets (chat, forums etc) using the W3C guidelines.
Scott made a very salient point when he reminded us that VLEs are very good at allowing us to group people. Most web2.0 tools don’t provide the same ability to group/distinguish between groups of people – there are few distinctions between “friends” if you like. So by creating and/or converting widgets and integrating them with VLEs we can potentially extend functionality at relatively low cost (no system upgrade needed – just add the plug-in) whilst retaining the key elements that VLEs are actually good at e.g. grouping, tracking etc. This is where the learning design element comes into play.
Dai Griffiths, University of Bolton, outlined how the IMS LD specification can provide a way to orchestrate widgets with a set of rules and roles. He showed examples of UoLs (units of learning) which use the chat widget in the wookie server. This is one of the most exciting developments for IMS LD (imho) as it is starting to show how the authoring process can become much easier for the average teacher. You just choose what widget you want to use, decided which students can use it, and when, add other content – widgets -whatever and you have your runnable learning design. I know it’s not quite that simple, but I do think this goes along way to address some of the “lack of easy to use tools” barriers that the learning design community have been facing.
There was a lot of discussion about students creating widgets. Tony Toole told us of one of his projects where they are trying to get students to build widgets. At the moment they don’t seem that keen as they (probably quite rightly) see it as secondary to their “real” learning tasks. However they do like and make use of more informational type widgets which utilise RSS feeds to push out content such as reading lists, course announcements etc. Ross McLarnon from Youthwire showed us the desktop widget application they have just started to roll out to over 130 Universities. Interestingly the university news widget is the most popular so far.
As ever it is practically impossible to summarize the discussions from the session, but some other key issues that arose were authorization. There was a discussion around the emerging oAuth specification which is based on a ticketing system so users don’t have to give username/password details to 3rd parties. It was also agreed that some kind of national educational widget server based on the wookie system would be useful. As well as storing relevant, safe, widgets it could have information/examples of widgets being used in practice and relevant system plug-ins etc.
As a follow on from this session we would like form a working group to explore all these issues in more detail and provide feedback to JISC for potential funding opportunities. If you would like to be involved please let me know either by leaving a comment or by sending me an email (firstname.lastname@example.org)
More details of the session can be found on the wiki.