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
social pharmacy d-pharm 1st year by Pragati K. Mahajan
2011 01-14 (ucm) e madrid griffiths ub oferta de servicios flexibles para ims learning design uso de widgets
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
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
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.
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
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