Widgets - the Wookie project

institute for educational cybernetics

QuickTime™ and aTIFF (LZW) decompressor

are needed to see this picture.

Widgets

Scott Wilsoninstitute for educational cybernetics university of

bolton




A Bit Of Background

• Direction One:– IMS learning design and “services”– TenCompetence EU Project and the

“Connection Protocol”

• Direction Two:– Connecting PLEs and institutions– Ubolton’s OnlyConnect project




TenCompetence & IMS LD

• Make LD less like programming• Move from early to late binding model -

more outlining than authoring• Better integration of authoring and

runtime - make the whole thing less abstract, and more like LAMS

• Support dynamic editing from activities by users (including learners) - a.k.a. the widget widget




ReCourse mockup

• Late binding with runtime integration




Runtime experience




OnlyConnect

• Use Widgets to enable core institutional services to be distributed in both institutional, departmental, workplace, and personal platforms

• Focus on timetable information and messaging; may in future extend to library and other services

• A lot of backend work needed to funnel down to a few syllables of useful information

• A lot of potential target platforms: WebCT, Moodle, Sharepoint, Wordpress, Elgg (etc)




State of Widgets Today




State of Widgets Today - 2




State of Widgets Today - 3




Unbundled Architecture

Yes, its called wookie

No, I don’t know why




Standards

• W3C Widget Specification 1.0– Derived from Apple Dashboard, Windows

Sidebar, Opera Widgets, Nokia Widgets vendor specifications

• Proprietary vendor specs– Google Gadgets & OpenSocial– Netvibes Universal Widget Spec– Apple iPhone SDK– Lots and lots more…

• IMS LTI




Adapting/Extending W3C spec

• Widget instantiation service– Way for engine to manage instances in a multi-

container, multi-user (web) environment and use opaque api key to keep user states separate

• Proxying– Avoid AJAX security issues without killing

functionality

• Shared states– Widgets with shared state between multiple

users, for collaborative tools, games, etc.




Architecture




Widget Config API

• Offers containers controls for instantiating and controlling widgets from engine

• Invoked from container plugin (e.g. Elgg plugin, Moodle plugin)

• Methods: getWidget, stopWidget, resumeWidget, setProperty




Example

HTTP GET engine/getWidget(user_id, run_id, service_id, ‘chat’)

<?xml version="1.0" encoding="UTF-8"?><widgetdata><url>http://localhost:8080/wookie/wservices/www.tencompetence.org/

widgets/WP3/natter/chat.htm?idkey=xR8OG1IFX58z/YVvlz910PQVtv8.eq.&url=http://localhost:8080/wookie/dwr/interface/widget.js&proxy=http://localhost:8080/wookie/proxy</url>

<height>383</height><width>255</width><maximize>false</maximize></widgetdata>




Widget API

• Extensions to W3C Widget 1.0, itself based on Apple Dashboard

• New methods and events:– sharedDataForKey(key)– appendSharedDataForKey(key)– setSharedDataForKey(key,value)– Lock– Unlock

• Enables synchronous collaboration in widgets using reverse AJAX/comet




Collaborative widget

Elgg plugin uses its native widget system

Converted Apple widgets




Moodle plugin uses “blocks”




Wordpress plugin uses its native widget sidebar




Widget management

• Basic admin interface for uploading new widgets as W3C widget packages

• Whitelist proxy for enabling remote service access by widgets

• Tagging to enable instantiation of widgets by type rather than id (esp. for portable learning designs)




Access and security

• Widget engine deliberately uses NO authentication (except for its admin webapp)

• User relationship managed by container only. Engine generates opaque non-guessable keys for each widget instance

• Container can push properties to a widget it instantiates (e.g. display name, moderator status)

• Widgets can send things like completion state data back to container, but not implemented in current version as it requires more work for containers




Implementation

• Engine– Java Web App (tomcat or Jboss)– MySQL– DWR (Direct Web Remoting) library– Pretty small (about 1mb WAR plus 11mb of common libs)– One engine can serve multiple containers

• Widgets– Chat, Voting, Forum– Converted Apple widgets (add W3C manifest, remove/re-

route apple dependencies)

• Plugins– Wordpress, Moodle, Elgg. All PHP using platform API




For the future

• Grabbable widgets - dragging the whole thing off into your own personal containers straight out of another container such as VLE. Can do it now… but want to check more security angles!

• oAuth - put the user in control of how widgets gain access to remote services

• Widget state coupling using events and listeners (already prototyped by Palette project at Lausanne)




Next steps

• Package and document all our stuff so others can use it more easily

• Work with other OSS projects, particularly Elgg and Moodle, possibly Apache Shindig

• Publish extensions/profile of W3C spec for W3C or other spec bodies to take forwards

• Make more cool widgets




Thanks for listening - over to you

http://www.cetis.ac.uk/members/scott

QuickTime™ and aTIFF (Uncompressed) decompressor


Widgets - the Wookie project

Technology

Transcript of Widgets - the Wookie project