Mobile Widgets Camp - W3C Track @ WWW2009

Context

The Mobile Widgets Camp, organized by W3C, was held during the 18th International World Wide Web Conference in Madrid, 23 April 2009. See W3C Track @ WWW2009 for a more detailed agenda.

The event featured a mix of structured content (talks and tutorials) and unstructured content. Topics of discussion for the afternoon session were selected at the camp. This Wiki page is intended to collect reports from that event, after having served to collect suggestions of topics.

Topics discussed at the Camp

Mobile Widget and User Experience

(notes from dom)

Alternative input method: single-key navigation, voice, Gestures, movements.

Will widgets allow for more type of input/output due to platform APIs access? how does that relate to accessibility API in phones?

Design pattern for widgets taking into account other methods of input (speech), and output (haptic, audio)?

Convergence of UI patterns between widgets and web applications?

Well-know UI patterns / templates ? Relationships to accessibility considerations?

Applicability of ARIA for transcoding systems (marking up navbar)

Toolkit to wrap this around

XForms / Javascript Declarative vs CPU intensive

WebForms vs XForms, limitations of runtime Adapting existing toolkits to mobile devices

Building different versions of widgets through compiling for each and every device, adapated to device capabilities - what about testing?

Defining UI in the abstract (DIAL, ...)

Device APIs and UI considerations

Writing your first widget

(notes from dom)

We ran a quick session where a few us wrote our first widget, based on the betavine tutorial; we noted a few discrepancies between the tutorial and the current specification, and noted some interop difficulties (e.g. Zip in some version of MacOS).

Most of us managed to get our first widget up and running in the Opera widget engine.

We also noted the value that a potential Widget validator would bring to detect silly little mistakes...

user-generated widgets

(notes from diego)

Templates
- UI templates (~patterns)
- Whole widget templates -> widgetize RSS feed already available
- Use a working widget as starting point
Question-based
Block-based (very tightly tied to code)
Workflow-like (for the logic): very programming oriented. Diego: problem with workflow-based logic creation. Users don’t see workflows.
Let users create the GUI, use lego-like blocks for the logic
What would be your preferred option? Spoken natural language widget creation.

 Jon: mentions related work by Orange (SPICE). 
 Benoit confirms, matches are made with an ontology. 
 Charles: natural language is very different from restricted natural language. Visual metaphors are generally better for people

Features:

Guillermo: maybe easier if you don’t have to deal with the UI? Event -> action -> decision… They did a prototype. Similar to mobots.

Diego: we had always thought users would visualize the UI first and easiest

Key issue: users must be able to test run their widgets in a safe environment

Benoit: importance of proactivity from the tool to allow you to create your widget. Charles: importance of having attractive example services to make users curious about how to make their own. Also figuring out what are the best blocks to address user needs.

Guillermo: reverse engineering is needed; although people can do that as well Make it good at reading your mind. -> Component suggestion (semantics can help here)

Examples Charles: scratch programming language, for logic. Each logic block looks like a lego block. Mobots SPICE

Jon: mentions SAP’s Rooftop. You can connect widgets using inputs and outputs.

Guillermo: Piet, programming language based in colours

Charles: go talk to people who make programming tools for kids.

Widget Discoverability / Inter-Widget Discoverability

(notes from DKA)

How could widgets access ZeroConf stuff in the same lan? – Bonjour –

Network device-to-device communication. DLNA. Widgets would need an API that can discover devices over ZeroConf .

You need an advertising protocol?

Wide area is a much more difficult problem.

What about Bluetooth?

Shouldn’t the OS do this – a print button?

In the Web Services land – you write WSDL file for the service and you place it in a UDDI registry. These UDDI registries are well-known. That’s one way of advertising your service interface. It could be applied to widgets.

You have to define the list of origins that are allowed in a widget.

In the world where phones have IPv6 addresses.

Scenario – I have an EPG widget on the phone and I want to be able to control my TV (or my friend’s TV) from my phone. I want it to discover the TV automatically and just start working (or maybe go through a pass-key process). Straw-man mechanisms: Jabber accounts. If I’m already connected to my friend via jabber then these devices can connect via jabber (XMPP). Jabber is federated. Bonjour is ZeroConf which is an IETF standard.

Web Services on widgets.

Is there an opportunity to have the runtime engine talk to another runtime engine? Have P2P built into the web runtime engine. Every web runtime to include a secure P2P overlay. There would still need to be discoverability – a tracker.

Are widgets restful? Once you have a URI you have discoverability. How do widgets fit in the architecture? A widget is like a JAR. Issues about URLs in WAR files – how do you name the things in a WAR file? In JAR you can say JAR:/ . People wanted to put RDF in a JAR – you can use relative URLs in a JAR to point to other things in the JAR and point to external stuff but if you want your openoffice document to be GRIDDLable to extract data then it causes problems? Same problem might come up if you put RDF into your widget. (important if you use RDF to describe things.) (Can a GRDDL transform be written for widget manifest files?)

Discoverability of services over a WAN – you can have it centralized or you can have it discoverable. Someone needs to run the centralized service of the mobile widget discoverability.

SIP detour: RFC-2608 – service location protocol – SLP – though not much the Web. Part of the SIP stack. You could create a javascript method that gives you access to SIP – encapsulate SLP messages in a javascript API. Every so often SIP clients re-register with SIP server. Firewall issues is solved by STUN protocol.

Trust and security with widgets packaging – you discover something then you are now allowed to connect to it because of security restrictions… You need to define the security characteristics of the widget environment in such a way. In a widget configuration file you specify which features you want the widget to be able to access.

On the p2p topic – you have a server on your phone. So what if you have a print service with an identifier- you want to give it access to your pictures on your phone for a limited amount of time. You add that service as a friend to your phone for a limited amount of time.

Discoverability of Widgets themselves by users

You need an arbitrator? Crowd-sourced trust? On the web you don’t have an arbitrator.

Link rel=widget – if you happen to visit a web page you can discover that there is a web widget available that corresponds to that page. [Mozilla ubiquity provides this – also a crowd-sourced trust model…]

Description for widgets – describe widgets in RDF – you could have the widget point to the RDF description. By crawling web pages you crawl data and therefore descriptions… Writing the ontology might be the tricky part. What is the base ontology for widget description? What does a query log of a widget app store look lke?

Interoperability and cross-platform widgets

(notes from DKA)

How can you get the widget to work with all the devices – you need to rewrite it several times. What developers want is to be able to write it once and have it work across all devices. This is a big problem with mobile apps – e.g. Java applications. Interoperability of widgets – also a UI design issue. E.g. button size, no mouse-over in touch screen vs. other modalities… Screen size…

How can you know the screen size? The browser knows the current size. Network services like device atlas know the notional size / resolution of the screen. How consistent is getting the screen size? window.screen.size

Even if you do an html page that follows the standard, that doesn’t guarantee it will work for every browser on the phone. If you assume a certain level of standards support- targeting modern browsers. You still need manufacturers / operators to enforce standards support / pre-install modern browsers.

Some needs to be solved at the server end.

Grade-A browsers: Opera, Safari (Webkit), Fennec Grade-B browsers: everyone else..?

If you have a device that is the minimum – you have to build 2 applications – one for modern browsers, one for non-browsers. You could do this with one application and package it appropriately.

Not all widgets will be cross-platform. Some will be built for a specific device that want to use features that only certain devices support – e.g. the camera.

Some developers are using Flash Lite which minimizes interoperability issues [ how? ]

Different web runtimes – Opera – different versions, Nokia, Reference Implementation. Even if Opera and Nokia both support the widget packaging, how can you ensure rendering. Best practice that you recommend them to follow…

Operators have some influence on the design on the phone and the software – operators can have some influence over the quality of implementation. This is one of the problems in the mobile web.

What is a difference between a widget and a bookmarked?

Quirks mode blog entry

Different from “add to homescreen” on iPhone because that doesn’t work off-line at all.

Business question: why should I develop a W3C widget? What are the business advantages? What are the advantages over a web site / web application? What is the potential? In a widget context, you can launch the widget more quickly, if you can store your login credentials as well then this could be even faster. The widget can store some configuration information. Starts faster. But what is the difference in the business opportunity? You can build one widget and it works everywhere. Lowers your cost. Operators are also putting widgets in widget catalogs – this makes your content more findable / discoverable across multiple devices – access to a wider group of users.

What’s the simple way? Zip the content, give it the right extension, give it a config.xml file, etc…

Flash lite allows a business model that web applications don’t allow.

Reduces the information that has to be passed.

Also – App stores are hot.

One of the problems widgets help with – memory limitations and garbage collection in comparison to flash lite [and Java] environments. Regarding animation – javascript supports it bit not every browser supports.

Tools issues – you don’t have as good tools for HTML/mobile Ajax apps as for e.g. Flash Lite.

If there is no standard limit to the size of the widget and there is a limit in a specific platform then that is an interop problem in itself.

HP – they have a browser / widget web runtime.

How to create scalable UI? On iPhone, you can use a hack to detect change in screen orientation (an event loop). There is a need to detect orientation change on the device in a standard way. There is also a need to be able to produce scalable UI but the UI also needs to be usable. SVG can be used to help create scalable UI on at least Opera and Nokia. HTML5 will integrate SVG into HTML.

There is a big interop problem - CDF wicd can play a role here… HTML5.

Conceptual question – if you have a widget that runs on small and big screens you need to have features that only are visible on certain. You can use media properties in the CSS to help solve this problem. You need a CSS file for each mobile screen size (or type of device)? Question about the maintainability of this…

W3C Web Compatibility test for Mobile Browsers could play an important role in ensuring device standards support on browsers and web runtime. [Maybe we need a widget version of this test?]: http://snurl.com/25n2s

Device APIs and security

(notes from francois)

BONDI presentation

Guillermo introduced OMTP BONDI.

OMTP BONDI created to reduce mobile fragmentation, and allow for Web applications to become the enabler framework. Solutions: - native apps, specific to a platform. - java apps, supposed to be run once, deploy everywhere, but interoperability problems and updates not easy. - widgets and webapps are easy to develop, deploy, and manage, but lack access to many features of the devices.

BONDI focusing on architecture and security, in interfaces, and then, as a third goal, BONDI has been focusing on developing a reference implementation, targeted at Windows Mobile devices.

Up to 14 APIs: messaging, application invocation, communication, contacts, UI (minimize, send to background), location, camera, gallery.

Discussion

The discussion mostly focused on security/privacy that are triggered by the availability of new APIs that give access to sensitive information.

Thomas: what documents are you planning to submit to W3C?
Guillermo: the requirements, the specifications.
Phil: Javascript calls look like: "takePicture()"?
Guillermo: yes.
Phil: What prevents me from cheating and asking girls under 14 to go to a page, and take pictures of them?
Guillermo: security policy, signatures.
Thomas: how do you plan to control things when web applications start using these APIs?
Guillermo: widgets will announce the accesses they need.
Henry: that's a bit like the Java security policy. I never understood why it's never used properly in practice. You can download something and say: "yes, I give you access to this part of the filesystem, and up to 200MB".
Thomas: Suppose a Web application wants to access the camera, then the geolocation, then save the file, how many alerts am I going to see?
Phil: the scary part is how you're going to manage that if you say "I agree for a picture to be taken anytime" and then you forget.
Thomas: [mentioning some scary scenario involving data that shouldn't be shared but that get shared about highly sensitive piece of information]
Thomas: one way is to never ever take a permission as eternal. The best precaution is expiration.
Henry: it could be couple with location by the way.
Thomas: that's an interesting suggestion, actually. The other way is to make conspicuous when things get done, such as: "press that button to activate the camera". Location is more sensitive. How to know when my mobile phone is actually sharing my location? Physical control.
Diego: These APIs will be opened in the future. So we can't just say "thow away BONDI", and so on.
Phil: [mentioning P3P and the fact that it failed]
Francois: Couldn't widgets be regarding as a solution? APIs forbidden for Web apps, allowed for widgets, because there would have been a clear user assertion that he wants to use the service.
Thomas: in some ways, it works, in others, it doesn't, I don't think it will fly in the end.
Henry: wondering about FOAF+SSL, and whether it could be of some use. There should be some login/logout visual thing everywhere.
Phil: the funny thing about widgets is that there's no chrome, and things need to be visual.
Diego: You want to know when information is shared
Henry: same thing with SSL certificates that appear in green. There should be something in blue that says who you are and propose to change your identity.
Thomas: we need ways to revoke permissions granted. There are some interesting interaction designs. But there are no ubiquitous ways to do that.
Phil: back to APIs!
Guillermo: wondering whether you think these APIs need to be standardized within W3C.
Thomas: there was this workshop in London on security and APIs, that I co-chaired with Nick Allot. There seems to be interest. There's at least one WG where this work would fit. WebApps. WebApps is a bit overloaded with deliverables. A Member submission could be the way to go. On the Security stuff, there seems to be agreement that a WG is needed, but that's not given for now, and I do not know whether the final result would be what BONDI proposes or not. Members need to be interested, and prepared to give resources to work on that.
Francois: chaals said this morning that, in his view, APIs were half-baked. To your knowledge, is there something missing?
Guillermo: consistency could be one of the things he might have been referring to. There were several companies, and small task forces created different things. We made a lot of progress on that front, and merged most of the works though.
Diego: wondering how this could apply to our use cases in m:Ciudad. Suppose I propose a service that shares my location. I need my friends to be able to access my location as well.
Henry: you have a peer to peer friends authentication problem here, so FOAF+SSL would be perfect! Another thing I was wondering about in your case is: do you need IPv6, so that mobile phones can be given IP addresses?
Diego: the problem didn't come up in the tests.

Pre-camp Topic suggestions

Feel free to edit this section and append your own suggestion to the list or refine an already suggested topic! Also, if you are willing to lead a discussion, please add your name to a topic.

What should the Web runtime become?

Where does the Web runtime fit among native, Java applications? Should it be extended? Where's the limit between Web and Widgets?

Open Plaftorm and/or/vs. Application Stores

Are application stores replaying the walled gardens era?

More Device APIs

Access to the camera. Access to the list of contacts. Access to the file system. How many more device APIs are needed??

Security/Privacy

Should widgets be run in the same sandbox as regular Web applications? Can the user's privacy be preserved without impacting the user experience?

User generated widgets

Can we envision users to create their own mobile widgets/services? How? Can we envision widgets that are front ends for services that are not on the web, but rather are provided by users from their mobile phones?

Who's coming?

If you're planning to participate in the camp, please add yourself to the list:

Thomas Roessler, W3C (tlr at w3.org)
Dominique Hazael-Massieux, W3C (dom at w3.org)
Diego Urdiales (diegou at tid.es)
Samuel Santos, Present Technologies