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

1. Oferta de servicios flexibles para IMS Learning Design
gracias al uso de widgets: logros, limitaciones y perspectivas
Providing flexible services for IMS Learning Design using
widgets: achievements, limitations and opportunities
Professor David (Dai) Griffiths
The Institute for Educational Cybernetics
The University of Bolton
D.E.Griffiths@bolton.ac.uk

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. 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. 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. How could we make IMS LD work at
runtime?
Two principal options were seen at the time
a) Use services which are local to the LD server
b) Use remote Web services
(Now this is rather more nuanced)

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. 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. That's 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

9. Windows and Mac widgets

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
http://techcrunch.com/2010/12/07/google-chrome-apps-the-widget-economy-is-back/
 So how can a widget provide services for LD?

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.  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

13. C
A Wookie forum in the
Astro LD Player

14. A Wookie forum in the
SLeD LD Player

15. Detailed architecture (temporarily) at http://dl.dropbox.com/u/4684994/7_architecture.pdf

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. Authoring widget services in Recourse

18. Is this approach successful?
 It works!
 Only supports services delivered through widgets.
 Users can't 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 I'll discuss later
 Inter-widget communication (under development)
 This approach can co-exist with other service integrations, so it doesn't have to
cover ALL use cases

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. 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. 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. Some examples of Wookie
Wookie “Natter” chat widget running in WebCT,
Desire to Learn, and Sakai
Thaks to Chuck Severance for the screenshots

23. Slide from Scott Wilson

24. Slide from Scott Wilson

26. 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

27. 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

28. Mock up of proposed functionality
Slide from Scott Wilson

29. 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

30. 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

31. 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/

32.  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

33. 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!
d.e.griffiths@bolton.ac.uk

34. Post script
...some additional information on Omelette.
Slides from Scott Wilson.