Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2011 01-14 (ucm) e madrid griffiths ub oferta de servicios flexibles para ims learning design uso de widgets


Published on

2011 01-14
Dai griffiths
University of Bolton
Oferta de servicios flexibles para IMS Learning Design gracias al uso de widgets: logros, limitaciones y perspectivas

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

2011 01-14 (ucm) e madrid griffiths ub oferta de servicios flexibles para ims learning design uso de widgets

  1. 1. 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
  2. 2. 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
  3. 3. 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”
  4. 4. 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
  5. 5. 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)
  6. 6. 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
  7. 7. 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
  8. 8. 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 Web based  Google widgets  W3C web widgets
  9. 9. Windows and Mac widgets
  10. 10. 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 So how can a widget provide services for LD?
  11. 11. We built Wookie in order to... Support more sophisticated multi-user widgets (chat, vote, wiki...)  Keep track of users and their interactions  Provide server side logic for more sophisticated widgets using JavaScript API  Server-side storage, and push events Manage authentication  Hand off authentication to the containing application  No need to authenticate to use the service  Passes only screen name and hash code Manage the widget store  Unpack and store widgets (HTML, images, Javascript)  Collections of tools and resources can be made available to any platform that integrates Wookie
  12. 12.  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 Integrated with player and bundled with LD Runtime system
  13. 13. C A Wookie forum in the Astro LD Player
  14. 14. A Wookie forum in theSLeD LD Player
  15. 15. Detailed architecture (temporarily) at
  16. 16. 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.
  17. 17. Authoring widget services in Recourse
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. Some examples of Wookie Wookie “Natter” chat widget running in WebCT, Desire to Learn, and Sakai Thaks to Chuck Severance for the screenshots
  23. 23. Slide from Scott Wilson
  24. 24. Slide from Scott Wilson
  25. 25. 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
  26. 26. 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
  27. 27. Mock up of proposed functionalitySlide from Scott Wilson
  28. 28. 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
  29. 29. 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
  30. 30. Apple / Microsoft / Samsung (W3C)The w3c widgets have three states: icon, info icon (like the soccer one here) and full
  31. 31.  IEC is a patner in Omelette, a STREP focused on mobile mashups 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
  32. 32. 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!
  33. 33. Post script...some additional information on Omelette.Slides from Scott Wilson.