Transcript of "2011 01-14 (ucm) e madrid griffiths ub oferta de servicios flexibles para ims learning design uso de widgets"
Oferta de servicios flexibles para IMS Learning Designgracias al uso de widgets: logros, limitaciones y perspectivasProviding flexible services for IMS Learning Design usingwidgets: achievements, limitations and opportunitiesProfessor David (Dai) GriffithsThe Institute for Educational CyberneticsThe University of BoltonD.E.Griffiths@bolton.ac.uk
IEC, CETIS and IMS LD IEC: – The Institute for Educational Cybernetics – a research institute at The University of Bolton CETIS – Centre for Educational Technology and Interoperability Standards – JISC-CETIS is a service which we have run from the IEC for many years We have been involved in IMS LD since its inception
IMS LD has a weak description of services IMS-LD does not define actual services, e.g. a wiki or forum. It specifies four generic service types Conference Monitor Send Mail Index Search Not clear how are these to be instantiated at runtime What is a “conference”? Any kind of chat/wiki/forum? What if I want to use service “X”
A wider problem, not simply a weakness in IMS LD Runnable pedagogic models aspire to being both abstract and specific Abstract models of educational processes, not tied to particular classes Instantiated at runtime in specific systems with specific users This is not a problem for resources, which are packaged as a file or have a specific URL But services have to be provisioned when the run is set up, at a URL which is not known in advance Consequently we are invited to choose: – Clearly defined services, but not interoperable – Interoperable but with poorly defined services
How could we make IMS LD work at runtime?Two principal options were seen at the timea) Use services which are local to the LD serverb) Use remote Web services(Now this is rather more nuanced)
Using local services Defining the run-time environment in advance Potential advantage: excellent integration of services Potential disadvantage: poor cross platform compatibility This is the starting point for approach used by LAMS (inspired by IMS LD) Can be combined with an API for adding external tools
Using remote services Coppercore assumes the use of external services Integrated through the Coppercore Service Integration layer (CCSI) This was the approach taken by the SleD player Moodle forum used in player, but broken when Moodle changed Integration of Reload SCORM player It works, but... Each service integrated individually: hard work! Needs continual updating Consequently, not many services available
Thats where we were around 2005 Then we saw that widgets were emerging and could be interesting Desktop Apple and Microsoft have their desktop versions http://vista.gallery.microsoft.com/vista/SideBar.aspx?mkt=en-us http://www.apple.com/downloads/dashboard/top50/ Web based Google widgets W3C web widgets
What can widgets do for LD? We wanted to provide a wide range of Web based services which were Interoperable Easily integrated in any LD Player Easy to author It is easy to integrate widgets across wide range of platforms, including different LD runtime systems... But a common view of widgets is this recent random example from the Web A widget is a way to view information... a view or a form in a database – the data is there and the widget can show the data and do very little else with it. An app is a formal system with a process, a way to modify data http://techcrunch.com/2010/12/07/google-chrome-apps-the-widget-economy-is-back/ So how can a widget provide services for LD?
Wookie is a widget server for W3C widgets (reference implementation) Built by IEC by my colleagues: Architect: Scott Wilson Lead developer Paul Sharples Developer: Kris Popat Now in the Apache incubator, and building a wider developer community Developed in the first instance to meet the needs of LD services in the TENCompetence project Wookie home is at http://incubator.apache.org/wookie/ Integrated with player and bundled with LD Runtime system http://tencompetence-project.bolton.ac.uk/ldruntime/index.html
Detailed architecture (temporarily) at http://dl.dropbox.com/u/4684994/7_architecture.pdf
Specifying widgets in a UOL Each IMS-LD service has a parameter value (usually a name-value- pair) In an environment the parameter must be added to an existing conference service element widget=<type of widget> widget=chat widget=forum This must specify a widget available at a specific widget server, as maintained by an institution or service provider Set of default services available in Wookie, with default names Wookie advertises the services available Recourse LD editor represents the services for authoring.
Is this approach successful? It works! Only supports services delivered through widgets. Users cant use their preferred services (though this is also the case for any VLE) This already supports a great deal of functionality, and the range is increasing as new services are provided Can wrap complex functionality and games The widget services tend to be simpler than some of the equivalent VLE services, with less options, but... Not yet clear how far we can push the widget approach Widgets can be a front end to more complex services Widgets have other advantages, which Ill discuss later Inter-widget communication (under development) This approach can co-exist with other service integrations, so it doesnt have to cover ALL use cases
A changing context When IMS LD appeared VLEs had their own set of services bundled with them. The only external services they used were Web servers providing plain HTML In this context IMS LD was special: it wanted to work with a wide range of possible services, which could be hosted anywhere But many teachers now work with a wide range of online services, many of them served from outside their institution
Scope of the Wookie work This work started as a specific implementation problem for IMS LD But we have found that the problems and solutions have much wider application There is much in common between integration of services for IMS LD use of distributed services for VLEs and other applications used in learning delivery of interoperable services to a range of platforms, including mobile The problem of providing services for IMS LD has become a special case of the wider issue of flexible service provision
Wookie across eLearning platforms Wookie has been integrated with a number of applications Moodle Wordpress Elgg Wookie supports IMS Basic LTI. This can be used to integrate Wookie with Blackboard Desire2Learn WebCT Vista Sakai
Some examples of Wookie Wookie “Natter” chat widget running in WebCT, Desire to Learn, and Sakai Thaks to Chuck Severance for the screenshots
Shared instances Wookie can provide the same instance to a number of different platforms So you can have the same chat with the same participants taking place in WordPress and Moodle This breaks the strangle hold of the VLE over access to services The VLE becomes shell whose main function is to manage cohorts Institutions can give learners more control over their learning environment
iTEC European Integrated Project aiming to promote adoption of ICT in secondary schools Large scale pilots Uses Wookie to deliver collections of resources and services to classrooms to support pedagogic scenarios Wookie can collect and categorise these services and make them available as an App Library, like an App Store for mobiles An App Library of this sort could be provided by institutions or agencies Opportunity to explore the continuing relevance of IMS LD, when orchestration is required
Mock up of proposed functionalitySlide from Scott Wilson
Areas we are thinking about to make iTEC work What are the implications of an App library for education Inter-widget communication Configuring groups of widgets (environment?) How do we explain the activity? Configuring groups of widgets from a widget When and how do we need to orchestrate widgets Back to where we started with LD? Less prescriptive than current LD approaches
Mobile learning Open Mobile Alliance Includes Ericson, Nokia, Samsung, Telefonica, Vodafone, T-Mobile, Orange, Microsoft, Sun.. Making use of W3C widget specification in their efforts to counter Apple and Google No reason in principal why W3C widgets should not also run on Apple and Google Potentially makes it easy to provide the same services to VLEs and mobile platforms
Apple / Microsoft / Samsung (W3C)The w3c widgets have three states: icon, info icon (like the soccer one here) and full http://mortenjust.com/2010/03/20/how-lethal-is-vodafones-iphone-killer/
IEC is a patner in Omelette, a STREP focused on mobile mashups http://www.ict-omelette.eu/ Omelette will define and provide an open interoperable service platform for converged mashup services Wookie is the delivery mechanism Not an educational project, but provides toolkit that could be used to create mobile educational applications, e.g. Student project spaces with embedded video conferences Presence and ad-hoc messaging with campus SMS gateways Submission to course spaces from mobile devices Collaborative games Tracking visualizations of student activity for teachers
Thankyou All IEC produced software is Open Source: Wookie Coppercore LD Engine Astro LD Player SLeD LD Player Recourse If you work with it, please feel free to let us know! firstname.lastname@example.org
Post script...some additional information on Omelette.Slides from Scott Wilson.