Apps & Widgets Scott Wilson [1] CETIS [2] Apache Wookie (incubating) [3] W3C Webapps WG

Widgets HTML &| SVG JavaScript CSS config.xml mywidget.wgt Icon.png

W3C Widgets: for Web, Mobile, or Desktop? Apple Dashboard Windows Sidebar Google Desktop Konfabulator Opera Widgets OpenSocial Google Gadgets Google Wave Gadgets WidgetBox SpringWidgets Nokia Widgets iPhone Apps Android Apps Samsung Bada

How about, “yes”?

Basic Widget Authoring Process Make a webapp (HTML5, JS, CSS) Make a basic config.xml with name, author Give it an icon (icon.png) Zip it up Change extension from.zip to.wgt

Device APIs: Adding Extra Capabilities to Widget JavaScript W3C Widget API BONDI (WAC) W3 DAP W3 Geo Address Book Calendar Files Media capture (camera) Messaging System Policy Media Gallery Tasks Comms Log JavaScript

function takePicture(){ var camera = bondi.camera.getCameras()[0]; camera.takePicture(function(pic){document.getElementById("picture").src =pic;},function(){alert("nope");}); } Take Picture

Feature mapping <feature name=“ required=“true” /> JavaScript

Feature mixing! You can connect all kinds of functionality to widgets by injecting a JS API for it at runtime - and not just device APIs either JavaScript Did you know that Opera Unite services were W3C Widgets?

“W3C Widgets are better than websites because they download only the data; and not the core files.” “Widgets are better than app systems because you don't have to write 4, 5, or 10 of them. Just the one is enough.” “And hundreds of thousands of web developers already know how to create widgets.It's just HTML/CSS/JavaScript, after all.” - Peter Paul Koch

W3C Widget App Stores & Implementations

“A fundamental part of WAC is to ensure that developers have the simplest method by which they can create applications for the long tail. A key part of this is to endorse and encourage the use of technologies which are based around open standards. WAC plans to initially use both the JIL and OMTP BONDI requirements, evolving these into a common specification within the next 12 months. The long term goal will be to collectively work with the W3C for a common standard based on our converged solution.”

Aplix WRT for Android

Ripple - Emulator for JIL/BONDI widget dev.

BlackBerry Widgets is a platform to allow developers to leverage their existing web knowledge to build compelling mobile applications. A BlackBerry Widget combines standard web technologies with local device functionality in a familiar fashion while still providing industry leading security. Based off of the W3C Widget specification, a BlackBerry Widget is an alternative approach to building a mobile application in a native SDK yet still provides the same power and functionality. By using standard web technologies, the barrier for building compelling BlackBerry applications has been significantly lowered.

* “Wookie” is not a clever acronym. so if you spell it WOOKIE you’re shouting! A Java server application in the Apache Incubator. Includes a W3C Widget parser library.

How Wookie Works (pretty much* like shindig/opensocial)

Integrating Wookie Connector Framework –Java, PHP, Python, C#, Flex… Plugins –Elgg, Wordpress, Jetspeed, Drupal, Moodle, LAMS… IMS BasicLTI adapter –Blackboard, D2L, Sakai … – Backend: –JPA, JCR –Shindig adapter/deployment config*

API Participants: –Userid, display name, profile image Instances –Shared id (e.g. for courses) Properties –Key, value Widgets –Gallery-type metadata

Basic LTI parameterWookie usage lti_message_typeNot used Lti_versionNot used Resource_link_idMapped to shareddatakey User_idMapped to userid RolesCan be mapped onto “moderator” preference setting, or “isOwner” participant property Lis_person_name_givenNot used Lis_person_name_familyNot used Lis_person_name_fullMapped to participant.displayname Lis_person_contact_ _primaryNot used Context_idNot used Context_typeNot used Context_titleNot used Context_labelNot used Launch_presentation_localeMapped to locale. Launch_presentation_document_targetCould be mapped to Widget View Modes but is currently not compatible. Launch_presentation_widthNot used Launch_presentation_return_urlUsed for redirecting to an error page if a request doesn’t work Tool_consumer_instance_guidNot used Tool_consumer_instance_nameNot used Tool_consumer_instance_descriptionNot used Tool_consumer_instance_contact_ Not used

Moodle… Basic profile info from platform is shared with widgets through plugin

LAMS…

WebCT, Blackboard, D2L, Sakai…

Elgg… etc* (*Wordpress, Apache Wicket, Jetspeed, Simal…)

A few widget best practices

Build widgets to W3C, not for Wookie alone –Don’t rely on special internal Wookie features (e.g. DWR) if it can be avoided –Try to provide fallbacks for installed features which may not be available for other widget containers (e.g. Wave)

Consider mobile users too W3C Widgets can also run in MS Windows Mobile, Opera, Aplix and other platforms - if you design them with mobile use in mind Don’t navigate or use popups - always use widget.openUrl() –Will use device native best practice and user prefs (e.g. switch to mobile browser app, open new tab, prompt user etc) Don’t rely on cookies - use widget.preferences –User may access from different devices; use preferences instead to store user personalisation or tracking info. Do keep your widgets as small as possible Do follow the W3C mobile web guidelines where it makes sense

Security and privacy While you can store user credentials in widget.preferences, this is not necessarily a very secure place to put them In future oAuth may be added to Widgets and Wookie, which will make life a lot easier (see also Apache Amber) Widgets are bound by same-origin policy; until CORS is implemented, you need to use the server-side proxy offered by wookie for AJAX calls. You can use WARP to indicate access is needed in config.xml, e.g.