Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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