This document discusses widgets and their use in educational contexts. It covers: 1) The TenCompetence EU project and how it uses IMS learning design specifications to make authoring of learning activities more dynamic and integrated with runtime experiences. 2) The OnlyConnect project which uses widgets to distribute institutional services like timetables and messaging across different platforms. 3) The state of widgets currently, standards like the W3C widget specification, and architectural considerations for widget engines.

1. Widgets Scott Wilson institute for educational cybernetics university of bolton

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

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

4. ReCourse mockup Late binding with runtime integration

5. Runtime experience

6. 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)

9. State of Widgets Today

10. State of Widgets Today - 2

11. State of Widgets Today - 3

12. Unbundled Architecture Yes, its called wookie No, I don’t know why

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

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

15. Architecture

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

17. Example HTTP GET engine/getWidget(user_id, run_id, service_id, ‘chat’) <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <widgetdata> <url>http://localhost:8080/wookie/wservices/www.tencompetence.org/widgets/WP3/natter/chat.htm?idkey=xR8OG1IFX58z/YVvlz910PQVtv8.eq.&amp;url=http://localhost:8080/wookie/dwr/interface/widget.js&amp;proxy=http://localhost:8080/wookie/proxy</url> <height>383</height> <width>255</width> <maximize>false</maximize> </widgetdata>

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

19. Collaborative widget Elgg plugin uses its native widget system Converted Apple widgets

20. Moodle plugin uses “blocks”

21. Wordpress plugin uses its native widget sidebar

22. 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)

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

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

26. 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)

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

28. Thanks for listening - over to you http://www. cetis .ac.uk/members/ scott