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