A problem in IMS Learning Design

1
(No Transcript)
2
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?

3
Widgets

• Desktop
• Apple Dashboard
• Windows Vista Sidebar
• Web
• Yahoo! Widgets http//widgets.yahoo.com/gallery/
• Google Gadgets http//www.google.com/ig/directory?
  syndopen
• NetVibes http//www.netvibes.com/

4
(No Transcript)
5
(No Transcript)
6
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

7
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

8
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

9
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

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

11
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

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

13
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

14
(No Transcript)
15
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

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

17
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