Transcript Extending IMS Learning Design services using

A problem in IMS Learning
Design
• To promote interoperability, few services
• Local tool frameworks like LAMS have
much richer tool environment
– Easy provisioning
– integration of tools with the runtime
behaviours, and the authoring environment
• Maybe we need a learning activity
management system “inspired by” LAMS?
Widgets
• Desktop
– Apple Dashboard
– Windows Vista Sidebar
• Web
– Yahoo! Widgets http://widgets.yahoo.com/gallery/
– Google Gadgets http://www.google.com/ig/directory?synd=open
– NetVibes http://www.netvibes.com/
Building a Widget
• Easy to create, so many have been
developed
• User interface defined using HTML and
CSS, just like a web page
• Business logic written in JavaScript
• Packaged with a metadata manifest that
describes how they should be instantiated
by the Widget engine
Widget engines
• Widgets can store and retrieve user
preferences, make use of network facilities
• In some cases, also operating system
facilities
• Renders Widgets
• Handles Widget interactions, typically as a
layer associated with the user desktop
Standardisation efforts by the
World Wide Web Consortium
• Employ a similar approach with
– a tool packaging format
– local API
– a deployment environment
• These technologies are the focus of
new standardisation efforts by the
World Wide Web Consortium
Collaboration with Widgets
• Desktop Widgets are for the single-user
– Widget engines are personal not shared
– No mechanisms to share a dashboard
• Web Widgets similar, but context is a
public space
– more scope for collaboration.
– Some collaboration widgets being developed,
e.g. chat tools Gabbly and 3Bubbles
Why Widgets are potentially
valuable with IMS LD
• Large number of existing Widgets
• Ease of development
• Attractive and interactive user interface
could improve engagement with IMS LD
systems
• Integration relatively straightforward,
building on existing tools and conventions
• Here is a mock up...
Proposed architecture
• A Widget engine (the Widget Server) as an
add-on to CopperCore
• Combined with the SleD rendering layer
• The Widget Server
– offers a scripting API for widgets
– instantiates Widgets required by users
• “Late binding” approach used
Builds on other initiatives
• Follows initial work of the W3C Widgets
specification
• Combined with aspects of the Apple
Dashboard Widget API
• ...but is applied within a web context rather
than a desktop context.
Proposed architecture...
• Widget Service API uses only AJAX
• The architecture is entirely asynchronous
• Widget Server installs new Widgets to be
made available for use in learning designs
• Widgets can be locked and unlocked
– teacher needs to be able to freeze the content
of the tool (e.g. Chat, discussion, whiteboard
session) for assessment activities
Implications for the designer
• The designer only indicates types of
Widgets needed
– Uses an extension to the Learning Design
Environment
– Similar to the existing “service” element.
• The actual Widget implementation used is
dynamically determined at run time
Security and privacy
• Opaque hashcode for contextualisation, no
need for transmission of user information
• Locking completed Widgets minimises
brute-force attacks on instance hashes.
• iFrame for placing the Widget within the
browser prevents cross-site scripting
• Widget Proxy Service helps prevent
loading of remote malicious code.
The future...
• We are building a demonstrator
• Complete working system
• Uses single-user widgets developed for
existing widget engines
• Together with new collaborative widgets
within a learning design environment.
• V.1 scheduled for December 2007