W3C/OpenAjax Workshop on Mobile Ajax — 28 Sep 2007




  1. Welcome and Introduction
  2. One Web - DA Chairs
  3. Access to Device Capabilities
  4. Widgets
  5. Role of server-side adaptation
  6. What new standards efforts do we need?
  7. Education and evangelism
  8. Wrap-up comments

Scratchpad for the workshop: http://docs.google.com/Doc?id=dd3jk8v_68gmmnpx

Welcome and Introduction

JF: Welcomes everyone to the workshop on mobile ajax. Introduces himself as from IBM and manager of operations for OpenAjax Alliance

JF: Introduces Dan Appelquist, chair of MWI Best Practices WG and Mike Smith of W3C. Thanks the program committee. Explains sessions in the workshop each based on a particular topic.

JF: Lightning presentations on each topic, followed by discussion.

JF: Presenters will remain at the front for discussion session

DA: We're going to have the traditional W3C mechanism of IRC based minutes. Explains W3C IRC mechanism

<matt> Google Doc scratch pad: http://docs.google.com/View?docid=dd3jk8v_68gmmnpx

DA: But also we'll use this Google document that I've created as a scratch pad area. If we find that there are discussions that are going down rat holes, we can park those in this area so we don't loose them

JF: Same for issues that may require oceans to be boiled.

JF: Requests participants to introduce themselves

<Rhys> Participants introduce themselves

DA: Presents introductory slides

DA: Vodafone believes that mobile access to the web will be the dominant method in 5 years time

DA: Mobile is different, restricted resources, but also additional capabilities like cameras, PIM etc.

DA: Shows demonstration of the SoonR product. Shows a cool use of Ajax on mobile devices. Runs inside Opera browser on the device

DA: Things like transitions are somewhat unexpected on mobile devices. Good example of the kind of look and feel that can be achieved without having to write a custom application. All done in the browser.

DA: Shows Vodafone application written inside the Ikivo player to provide an on-device portal relating to the German football league.

DA: includes video. Example of a full screen, interactive application basically exploiting Ajax technologies

DA: These both illustrate fully immersive interactive user experience using Ajax

DA: Vodafone just joined OpenAjax. Mobile Ajax important. Best practices important

DA: Avoiding fragmentation in Ajax important. Has been a problem in other areas. We need to try and avoid it.

JF: IBM Position. Mobile Web will launch big time when mobile devices support the same browser capabiliites as desktop browsers

JF: Assume One Web as the foundation. Same sites, same content, though of course there will be variations.

JF: You'll be writing applications that will go to the whole Web, inclulding mobile.

JF: OpenAjax Alliance Position

JF: Started about a year ago. Trying to make Ajax successful.

JF: One Web vision, Web developer posts a single universal version of an application that runs on any Web device.

JF: Dan's wording of One Web is slightly different but equally valid.

JF: OpenAjax folks are interested in things that are solved in Ajax.

MS: W3C and Mobile Ajax

<GuidoGrassel> Suggestion to help people following remotely to the organizers: Would it be possible to put presentations on the Web before they are shown?

MS: MWI Best Practices just been rechartered. Part of the new work is focusing on Advanced Delivery Context. This includes feature rich browsers.

MS: Other groups, including HTML, Web APIs, Web Application Formats, SVG and Ubiquitous Web WG are all involved in Ajax-related work.

MS: HTML WG is looking at cross document messaging, local storage, etc.

MS: describes work in WAF and Web APIs

MS: describes work in UWA

MS: describes work of SVG WG. Notes that navigation and mapping applications have been written using SVG and asynchronous scripting. And Mashups of course.

One Web - DA Chairs

<matt> AOL Position Paper: http://www.w3.org/2007/06/mobile-ajax/papers/aol.tai.html

<matt> Google Position Paper: http://www.w3.org/2007/06/mobile-ajax/papers/google.burke.MobileAjaxGoogle.txt

<matt> Paving Ways Position Paper: http://www.w3.org/2007/06/mobile-ajax/papers/pavingways.georgi.positionpaper_moa_workshop.pdf

<matt> NTT DoCoMo Position Paper: http://www.w3.org/2007/06/mobile-ajax/papers/docomo.goro.pdf

DA: My definition of One Web is that from user's perspective there should be one information space that is accessible in a very seamless fashion.

DA: Don't think this conflicts with Jon's definition given earlier.

JF: The two definitions are related. From a developer perspective, you can write for lots of different devices. If you use a server-side technology you can achieve writing once and letting the server software adapt

AT: Alan Tai - DHTML and Ajax in Mobile Search

AT: Mobile search is very action oriented. Find 'X' in fewest keystrokes

AT: All mobile search engines tend to give you an aggregated search across many categories. Results are very large. Finding what you want involves a lot of scrolling.

AT: Frustrating. How can we make mobile search better.

<GuidoGrassel> thinks that the future is in browsers for mobile devices that preserve the layout intended by the Web author.

AT: What about high end devices. Can they use the desktop search engines

AT: Doesn't work well because of physical limitations. Also, scripting tends to be limited.

AT: Shows multi tab view used in the AOL search engine.

AT: Was difficult to implement because of limitations in devices. Have versions for windows, S60 and iPhone.

AT: Also have a simpler user experience on mobile phones

<GuidoGrassel> thinks that narrow layout is not feasible whenever AJAX features are used.

AT: One Web not there yet, but scripting is good enough to enable mobile apps to be developed now.

DA: Some people's definition of One Web means that it will never work because, for example, screens on mobile will always be small. So some kind of adaptation will always be needed.

GK: Goro Kinito - NTT Docomo

GK: Shows charts of Japanese phone market. 98 M subscribers, mobile internet 85 M users (Aug 2007) Nearly twice as many as fixed internet

GK: Smart phones not popular in Japan. iPhone may change that

GK: Messaging services send e-mail rather than SMS. Most done use SMS at all. Pictograms very popular.

GK: Nearly all mobile phones have multi meagpixel cameras.

GK: DecoMail, HTML-based mail, popular among young users

GK: Japanese mobile Internet has been the most popular in the world. Key was use of compact HTML rather than WAP

GK: Capablity of most browsers low. XHR not yet supported widely.

GK: Wireless communication involves unpredictable loss of connectivity. Need off-line mode

GK: Need a programming model (e.g. DojoOffline). Detect connectivity state

GK: Adapt to frequent disconnection

DB: Dave Burke, Google - Web as the platform for Mobile Applications

DB: Too many different application environments. Needs specialist skills

DB: Mobile Ajax is better. Browsers are getting better.

DB: Ajax is a powerful paradigm. But there are some issues compared with dedicated UI

DB: Pixel level control could be possible via SVG. Canvas is elegant approach, for example

DB: Offline operation For example, Google Gears has a non-evicting cache.

DB: Access to low level functions. Location, contacts, messaging, camera etc.

DB: Javascript is not a bad programming approach if you have well designed APIs

DB: Security is obviously an issue.

DB: Also need to standardise Javascript APIs

DA: Good summary of the challenges we face.

RG: Rocco Georgi, PavingWays - Frost Ajax Library

RG: Working on Ajax library for constrained browsers

RG: Ajax works in many mobile browsers but JavaScript/DOM implementations vary. Existing libraries don't work in many cases

RG: Needed a library for work on our own mobile web applications

RG: Approach is cross browser Ajax for mobile web apps. Support the weakest browser that is capable of Ajax.

RG: Keep it small (<3k at the moment)

RG: Limited function. can be extended, but only basic JS, no prototyping for example. Can't use sophisticated JS

RG: Fall back mechanisms in JS and in how JS goes into the markup so that the app will work in all browsers, but without Ajax in more limited browsers

RG: Produces browser dependent output based on UA.

RG: Debut output, basic Ajax requests, callbacks to handle returned data, timeouts if offline, putting data somewhere, basic page maniputations

RG: Support all browsers that know the XHR object or an ActiveX

RG: Do a lot of testing that leads to a browser capabilities database. Detects the browser and outputs based on it. Server is in PHP right now, and there is a Rails version under development

RG: Main issues - first release, building demos, building a community

RG: Open source project under MIT license. Looking for cooperation.

DA: Summarises the session and the notes he has made in the scratchpad

DA: Notes the issue of offline operations and access to low level functions and security.

DA: Asks if we have One Web from a user point of view, what does it mean from the perspective of access to functions on the device?

DB: It's interesting. When iPhone came out, there was an issue that Google apps didn't work right on it. Had to create mobile versions. Needs to be designed for mobile. Two areas are different, because the capabilties are different

AS: Designers need to think about One Web. there will be some cases where One Web can be effective and some where it's not possible, because the capability isn't there.

DA: Sounds like Frost takes an approach that includes a server and client component. How can that scale.

RG: Reason we do this browser detection is to allow small size of output file. It only gets the stuff it knows how to handle. Detecting the browser within the script can lead to issues

RG: Idea was to have different versions of output on mobile. May use redirection to get to a mobile version.

RG: Markup is output in a form adapted to the device. In terms of One Web, will have different output - same data, but different look and feel.

DA: Consistent with MWI BP that you need some kind of adaptation and hence device descriptions

JF: So there is a big cluster of people who put material on the Web in the long tail. They are able to adapt and do special versions. Then there are people who can't afford to do special versions, but can do some adaptation. The real long tail just want to put stuff up that just works everywhere without any work.

JF: There are devices out there that can give a version of the existing web although the user experience is less than optimal

AS: Most of what is in the input presentations is also in the papers

VH: Agree with Jon, on the long tail and the various solutions. One Web uses one technology. Reuse and don't have to learn additional technologies for different environments

VH: One web important to avoid need to learn new technologies. Also need to worry about accessiblity of content. Can get to it even if not perfect

<GuidoGrassel> agrees the distinction between support for full Web technologies and support for full Web content is important. Only the latter needs to cope with real-world document complexity on the Web.

DA: View that in two ways. One is state of things today. The other is what would we like the world to look like.

DA: One set might not be possible now, but might be in future.

James Pratt: The iPhone is a pretty unusual device. We'll always have the problem of small screens

<Rhys> Rhys +1 to that

<GuidoGrassel> pls fix the telco , it is impossible to hear the discussion.

AT: We saw this problem, and it took lots of work to do the rendering for all the different browsers

JF: My position was largely from the perspective of the people developing for the web. Most people so far have been paralysed. There are now devices driving this that can access the existing web. But it might not be usable on mobile devices

JF: Two phases, where can get to whole web, but it's not necessarily good. Then as the providers realise that mobile is important, the content gets better.

DA: Question about the Japanese market. Users are using e-mail and pictograms. Are users starting to want access to the same sites that the access to the existing desktop web

GK: Japanese users started to use the Web because it was there. Also had phones before PC. Youngsters better at using phones than parents. Content providers built mobile sites before PC sites. Also easy to do in c-html.

GK: Also, Mike talked about motion sensor in phones. Games support these kinds of functions. Not all terminals have same sensors. Some accelerometers, some by camera. Necessary to have abstractions from the device itself to allow different sensors that can deliver the same data

GK: Should ask device vendors to make good abstractions.

<Rotan> GK is pointing out the general problem of reacting to client-side events, many of which come from mobile-specific capabilities (or limitations, in the case of network connectivity).

KH: Long tail is a bit confusing. Most pages don't have mobile versions. If people want to get to these new devices, can do it just by making smaller pages.

KH: Keep it simple.

AS: Doesn't include Ajax. So it has a long way to go.

Igor: Latest phones do support Ajax. Situation is changing fast. Lots of pages do actually work. Richest applications are issues

KH: Mobile user agents are getting better

SM: The reality is that there is a wide variety of agents. Diversity pushes us further away from the one web vision. Common point is the server and that's where we need to look. Not adopted well in the Ajax community.

DA: Is fragmentation getting better or worse?

[Break until 10:45]

Access to Device Capabilities

JF: Let's get started now!
... This topic has come up many times. Pretty universal. When Ajax on device, want to leverage features and capabilities.
... This session is about that subject.
... We will have some lightning presentations.
... Will show you what has been discussed recently.
... Applix first.

[Introductions, starting with Kai H.]

KH: Mobile device APIs. Example, getting location.
... getting access to address book, file store (for offline).
... There are problem there.
... We are working on these problems, using our existing Java implementation.
... Let's talk about JSRs.
... They are specs, standards.
... Am writing plug-in to allow reference to JavaScript library to access this stuff.
... We are here to promote this idea, and work with standards bodies to agree APIs.

[Shows slide]

KH: Leveraging Java security features. Carriers love these.
... Use these to help things happen on the Web.


KH: Just a code name.
... More important idea here is leveraging standards.

<matt> http://wiki.webvm.net/

KH: All this is on the wiki page. Doing all in open.

Sun presentation.

AA: Question we asked: what can we do to bring Ajax to people on mobile today?
... Don't want to just target expensive phones.
... Many today barely have a browser.
... Just taking a desktop app to mobile just not enough.

<GuidoGrassel> has a comment on the presentation: We are saying the mobiles are constraint devices, some can not support full Web technologies? The spaker suggests to use Java in addition to Web. Hence, the two larges run-times on a phone should be running at the same time?! I do not think this is realistic on other than really high end phones.

AA: Mash-up of data is important.
... Broaden defn of Ajax.
... to include things like SVG.

VH: We're trying to simplify developers life.
... First available is SVG.

[Shows screenshots]

[and emulator]

[technical trouble with web connection]

VH: Have animations, graphics.
... Using SVG. Simple animation.
... Retrieving XML data.

[more tech problems with demo]

VH: This is showing that we're reusing UI presentation through code.
... Easy for developers.
... Familiary technology.
... We have nice web engine with SVG support.
... JSR 226
... In the future we will also have JSR 290.
... Go full way to adopting all Ajax technologies. Scripts, XML, SVG etc.
... resident apps can address offline issues.
... Secure environment.
... That's what we've beem emphasising: leverage existing/familiar technologies.


DA: Is JSR 290 related to WICD?

VH: Yes. Highly related.
... 290 is providing API for WICD format.
... Combination of XHTML and SVG.

<GuidoGrassel> has a comment on two presentation: Many speakers were arguing that man of today's mobile devices can not support full Web technologies. The speakers suggests to use Java in addition to Web. Hence, the two larges run-times on a phone should be running at the same time?! I do not think this is realistic on other than really high end phones.

KH: Want to say that Aplix not giving you a new way to use Java. Just put script thing in place to use Open Hub etc.

JF: Will give summary of SAP paper.

[See position paper http://www.w3.org/2007/06/mobile-ajax/papers/sap.hamdi.pdf ]

JF: Local file system, PIM and GPS access are high on their list.
... Yesterday we had OAA meeting.
... Summarised much of what we've done to date. Looked at JSRs, MSA and other things.
... Windows Mobile, Opera etc represented.
... Fragmentation: Java initiatives, Opera APIs, and more.
... Talked about standardisations. Unification. Could take a long time.

DA: And we have our own: VodaScript!

JF: How to deal with this.
... Have an idea, one day old.
... Maybe we could define messages and payloads to access device capabilities.
... Vendors provide whatever bridges they want.
... Gets around fragmentation.
... Leverage Java, WM etc.
... Lightweight, short-term. Avoid long standards process.
... Lightweight Web Services on the phone.

<MikeSmith> OpenAjax Hub: http://www.openajax.org/OpenAjax%20Hub.html

JF: Uses JSON perhaps.
... Only discussed it for half an hour or so.
... We're open for discussion.

KH: I thought of it as wrappers.

[JF may have disconnected the phone!]

[We're working on it!!]

We're asking Guido's question.

<MikeSmith> [Rotan reads Guido's question aloud now]

<GuidoGrassel> thinks that Java and JavaScript neither work together nor is JavaScript replaceable by Java in any sensible way.

KH: Java already running on millions of phones.
... Coming up with a way to make it quick and fast.

VH: Timeline issues.

<GuidoGrassel> my point tis that both run-times would need to run in parallel.

VH: SVG Tiny on phone.
... Is why I was talking about core technologies.
... XHTML-Basic also appropriate.
... We see doing strict browser is good.
... But street HTML and tag soup is too much.

AA: There is class of apps you want running on the phone all the time, like GPS.

JF: And SAP had their 3 categories of these.

AA: Was thinking of future when one Web happens.

MS: Guido considering S60, Access etc running, and Java running at same time, which is a lot for a small device.

BLR: Solved problem by using Ajax hub.
... Some ops should not be async, right.
... How is it easier ro standardise message names/payloads, than just standardising APIs?

JF: Good question.
... Dynamics of industry groups is that some things can be done in certain groups.
... If industry came together, what options would be have. Would MS work with JCP for example?
... How much on vendors plates, processes in place, bandwidth available to them etc.

VH: I think there is advantage to having generic API.
... Today people do a lot with XML and a handful of methods. Very extensible.

<GuidoGrassel> Message passing between what? - I do not think the overhead of message passing makes sense for things like phone book access.

VH: Difficult to align APIs.

BLR: Dut you still have to standardise on the payload.

JF: But as Vincent says, you start with something basic.

BLR: It need extensibility.

Alex: I do a lot of Java library work. Don't have a lot of leverage here.
... No preference for exposing as API or as tags in markup.
... If we can't get consensus to get done, and have to do in JS, then we can do this.,

AB: Thought UWA would solve this.

RL: Whether you put in markup, languages, procedural route... if you don't get these in place then you end up making plug-ins.

LL: As far as browser is concerned,
... may have same browser on many devices,
... not sure the browser addresses diversity in devices.

<GuidoGrassel> interfaces to the platform should be JavaScript , no messages, no "markup" whatever the last should be. But I question the need for standardization.

LL: You need to address the device diversity issue.
... Looks like something the DDWG could address.

Alex: Java, SVG, XML are brittle. HTML is designed not to be.
... Makes it a preferable environment to get this done.

JF: It's an issue I worry about.
... Need a success plan.
... Get it done in W3C? And when?
... Lots of stuff going on in different orgs. Which has best chance of success?

DA: When we get into diversity, we start going on about fragmentation etc.
... There are a small number of capabilities that we could be thinking about first and foremost.
... These are candidates for standardisation.
... Don't want to get down the road of millions of properties.

KH: Agree with Alex that browser is a good environment for this.

YT: To address Alex point re XHTML or JS tag.
... In browser can extend to use either.
... How to standardise?
... To represent device capability in HTML, JS.
... How to map these to Brew, WinMobile etc.
... How to represent this in tag or JS?

KH: The APIs they come up with will need wrappers. Go from there.

DA: Security.
... So when accessing user's location, I come back to security.
... Accessing address book, camera...
... invasion of privacy.
... Cannot expect user to answer many questions on browsers.
... Many dialog boxes.
... Users just click "Yes".

Alex: Auto-complete has exactly the same problem.

<GuidoGrassel> thinks secure platform access is far more relevant for standardization than specification of platform access APIs.

Alex: You train users, and users train you.
... At first you have to prompt them.
... But over time they adjust.

KH: Carriers are specific about what users can/cannot access.

DA: Early days to talk about carriers.
... Will want to have some control over what app providers and apps themselves can access.
... Esp if they point back to network features. E.g. assisted GPS where app points back to cell info.

Alex: suggest we not pay attention to carrier needs.

LL: Not reality of mobile space.
... Number of interested parties.
... Make solution that shows we address their needs.

YT: From Sun's impl, you're converting Web page into J2ME app.

VH: Not trying to replicate browser. Using core technologies for different purposes.
... Layout, scripting, animation, VG, MM etc.

YT: Essentially J2ME apps.

VH: Yes. Midlets.

<GuidoGrassel> notes that browsers have a tight sandbox for very good reason. Most of the browser security issues that are reported are cases of a Web Appl managing to break out of this sand box. -- What makes us believe we could open this sand box without causing damage.

YT: You guys (Aplix) use JSR functionality. How do you do security.

KH: We haven't figured it out yet. Sandbox. Mediation.
... Might want to sign what object can work in what domains.

VH: Spent long time in JSR 290 on those problems.
... Secure app, and secure demployment, a lot to take on.

SK: +1 to Aplix, to not having too heavyweight a runtime.
... Keep lightweight enough while still being secure.

DA: Joost doing TV app.
... They working on widget.
... Perception that widget with security framework for anyone to build. Restrict a little bit.
... Simple signing mechanism. Register, sign code with key.
... Just register as a developer.
... Not sign each app.
... Can revoke developer's cert.
... All apps will then be revoked.
... Lightweight model that could work in Ajax space.
... [Points to Al

<GuidoGrassel> signing does not solve anything. the infrastructure for getting signed determines if signing can delivery increased security. No good solutions for infra that I would know.

[Points to Alex] You sceptical?


[end of session]


[Just setting up the podium]

DA: Have touched on mobile widgets. Many definitions. Widgets. Gadgets. etc.

DA: When I think of widget, think of all Web technologies, resident on phone, easier to install than current install process for Java and native apps.
... That's what I think is a mobile widget.
... Has to do with Web technologies.

Igor presents.

IN: Widgets use technologies. Including Ajax.

[See presentation at http://www.w3.org/2007/06/mobile-ajax/papers/access.sasaki.PositionPaper_EmbeddedAjax_ACCESS.pdf ]

[Igor is going through the slides.]

JF: Has this material been proposed to any standards group?

IN: Going out on market right now. Proposed at 3GSM this year.

scribe: Intend to submit for consideration as a spec.

<GuidoGrassel> My presentation is at http://www.grassel.net/transfer/W3CAjax-Grassel.html. I appreciate people typing their comments into IRC because I can not hear the audience , I can just hear people on the podium. Thank you!

[See presentation at http://www.w3.org/2007/06/mobile-ajax/papers/nokia.grassel.pdf ]

GG: Widgets well developed.
... Integration with Web-based services on UI level very straightforward.
... For end user, they appear more app like, more efficient.
... Hopefully UI is more like an app.
... And hopefully browser chrome is gone too, as this is confusing.
... Support for full desktop technologies may not imply support for full Web content.
... HTML5 WG has good principle.
... "Pave the cow path."
... Only do what is necessary.
... Advocate open source to avoid fragmentation.
... Layout issues re small screens is rather over-rated.
... Existing technologies already address this.
... Navigation is a bigger problem.
... Joystick, touch etc.
... Good example of Apply generating mouse events.
... Any kind of best practices doc will have to be written many times for different interaction methods.
... Have doubts over value of such BP docs.
... Offline work is well on the way.
... Security model is an open issue.
... Protection of user data.
... Different widgets working on device at same time, mash-up, with different security constraints for each. This is a challnge.
... We're talking about megabytes of JS in some cases,
... How do we improve JS performance.
... Looked at ECMAScript 4.
... Can't see how Java would replace JS.

DA: That's a lot of topics.

Brian: (Sprint)

[See position at http://www.w3.org/2007/06/mobile-ajax/papers/sprint.coughlin.posiiton-paper-mobile-ajax-workshop-2007.xhtml ]

<artb> Brian's PP: http://www.w3.org/2007/06/mobile-ajax/papers/sprint.coughlin.posiiton-paper-mobile-ajax-workshop-2007.xhtml

Brian: Will be new wave of devices coming out.
... More like PC devices we're familiar with.
... Much more compact.
... For WiMax network we're building (open IP, end-to-end), devices certified by WiMax-F
... Will get logo.
... Get on network, ad-hoc. No walled gardens.
... Encouraging an open environment.
... See lot of Web standards as great.
... Hope those things can be re-applied to this new ecosystem.
... See opportunity for existing Web to migrate.
... Re widgets, think there should be a standard packaging, file format.
... W3C has outlined what this could be.
... Great if this were standardised.
... Meta-information, security, code signing, to be part of the file structure.
... Chromeless widget, could be small like a sprite, or take over screen, or go from widget to widget.
... Or control rendering of page.
... Definitely expect this to happen.
... Offline important.
... No network is pervasive.
... Need to have graceful way to move to different network states.
... Some really good standards work going on.
... Needs to be more open source implementations.
... Especially widgets.
... For example, a FF plug-in for widgets.
... Seen Google, but not in line with what we see in WHAT-WG.

DB: Think we share confusion of what a widget is.

DB: On desktop, shares space with other things.
... On mobile, it takes the whose screen.
... Problem with widget download is that you don't get instant update. You need to download the whole app.
... Codesigning doesn't buy you much.
... Sign a widget package, download it, and then it could download more code.
... Unlike Java app.
... So signing of widget more complex issue.

AB: Let me overview WAF.
... Focus on packaging format.
... What goes in the Zip. The manefest.
... How do you do auto update?
... Non trivial.
... Within scope.
... How far we get, don't know.
... Started one year ago.
... First draft in November 06.
... 20% complete.
... Many empty/open issues.
... Now gone to 30% complete.
... Lot of work to do.
... Working on public mailing list. Invite people here to participate.
... Want to make these interesting widgets more usable.

DA: Wondering if WAF was looking at updates. (You answered my question.)
... The way it gets on to the device is more seamless from user's perspective, than you see with other app installation processes.

[Dan rants about recent horrible installation experience.]

DA: Install process for widget is a hook "Do you want to install? Yes/No" and that's it.

GG: We all know how to find RSS. You see the icon on the Web page. You click it. Ask if you want to subscribe.
... Similar approach for widgets.
... Browser can indicate widget related to what's on browser page.
... This is how I think users will find widgets.
... Browse, find, decide to install.
... Also, any widget is free to emply XHR.
... Combined with storage on device, can become very powerful.

LL: Getting overloaded with term "widget".
... Is there something specific about widgets, as opposed to applications? Or is there a real distinction?

DA: Issues could relate to any apps on mobile.
... But focus on apps that use Web technology.

[Dan displays definition]

LL: Point I want to make is that Web as an app platform can address many shortcomings of apps on mobile.
... The term "widget" as opposed to Web apps is potentially narrowing.

JF: Some mechanisms growing on some platforms where there are containers (Yahoo, WinVista, etc.)
... 1000s of gadgets, just for Google.
... There's a cow path forming around this.

DA: UPS launched huge ad campaign around "widget".
... There is a groundswell in industry around the "widget" concept.

Igor: Web widgets are a way to respond to fragmentation on mobile devices.
... To launch killer app on multiple devices, you'll waste 90% time doing porting to multiple platforms.
... Widgets provides common baseline.

DA: Though now I notice we also have widget fragmentation.
... Need standardisation now.
... Otherwise we'll have fragmentation over fragmentation.

Alex: difference between fragmentation, and things that fail fast.
... Doesn't work at all scenario.
... People getting used to that.
... Have a better shot now of getting it right.

DB: Let's call them "weblets".
... WE lose half our users in the download/install process.

JF: If we have Ajax as runtime for browsing, widgets etc.
... Widget provides framework for how this gets installed.
... A simgle deployment path.
... Would work if people supported this one thing very well.
... Widgets spec could be a way to successful installation.

DA: Spec remains silent on installation.

AB: Corrent. Right thing to do.

VH; Think this orthogonal.

AS: Or is it? It may be the solution.

JF: For long tail of Web, might be good solution for presentation.
... Also good for apps, as we've been discussing.
... Solving unification problem.

DA: Look at current situation, apps written across many many platforms.

<GuidoGrassel> thinks that providing multiple run-times on a device is motivated to address the use cases and preferences of different developer communities.

<GuidoGrassel> The community of Web developers is particular large.

KH: Agree with Larry.
... HTML5 used to be called Web Applications.
... Encourage people to join.

YT: In terms of Google widgets, residing on server. Need to make distinctions.

DB: Yes. There are different types.

IN: Don't think we need to make such distinctions.

scribe: For example, on limited device, move CPU load to server.
... Not black/white. Shades of grey.

BM: One is end-user view.
... Think back. "Ajax" applied to much.
... Marketing benefit of using "Ajax" was inestimable.
... So think of value of "widget".
... We're also looking into the technical definition.
... Separate marketing and technical issues.

DA: Agree.
... Propose "midgets".


DB: On phone the Apple weather thing is seen as an application.
... But on the Apple desktop the end-user thinks of it as a widget.

JF: Developers would probably like it if we made it easy for them to be cross platform.

["One Widget"]

GK: Re weather widget,
... Widget is not the focus of your attention.
... Whereas on mobile device, it has your focus, so it's seen as an app to the user.
... On iPhone there is no difference in starting widget or browsing. All full-screen experience.
... Think destop widget is a background app.
... Never the case on mobile.

GG: Think there is no difference between widget and browser.
... Widget visible on home screen.
... But no wait for download.
... Just tap on the widget and it runs.
... Better user experience.
... Widget gets prime real estate on the UI.

DA: Are widgets part of MWeb in Korea?

Kyeongwoon Lee: Yes. Much use of widgets by Korean users.

scribe: Various support facities by carriers.

DA: More fragmentation.

MW: Everyone has widgets. No dominance in the market.
... MAybe now is time to join Art's group (WAF).

[Break for lunch]

Role of server-side adaptation

[Stephen Maryka doing demo of ICEFaces]

[Sean Patterson getting projector set up now]

SP: Sean Patterson, RH: Rotan Hanrahan, RL: Rhys Lewis, SM: Stephen Maryka
... We have a content-transformation server product
... here to talk about issues we see with content-transformation and Ajax
... typical thing that CT servers do is to transform HTML, CSS
... that is fairly straightforward to handle
... dealing with limitations: screen size, markup-language support (e.g., WML instead of HTML)
... a lot of browsers on devices have limited JS support
... though we are starting to see more that have JS support
... but for the most part, as far a CT servers, issue is to figure out how to deal with complex JS interaction in content delivered to devices with browsers that don't support JS
... For devices with high-end browsers, you just pass through all of it as-is.
... for devices with more limited support, you have to figure out how to deal with it.
... Requires much more granular information than just "does or does not support JS"
... Another approach is to put some sort of custom client on.
... Basically, need the ability to update just parts of the screen.
... Novarra is interested in knowing just how prominent this Ajax on mobile devices thing is going to be.
... This workshop has made me realize that is does have a future.

[Rotan Hanrahan steps up]

RH: The ideal world: Content Resource -> Web Presentation
... except that is not the Real World
... but there is a Proven Solution that relies on content adaptation using static and dynamic delivery-context metadata
... Solution: Adapt.

[Rhys Lewis steps up]

RL: "Mobile Ajax and Application Adaptation"
... The point is to make it easier for content providers/developers to do this stuff.
... W3C Ubiquitous Web Apps group is looking at some of these issues.
... Adapt the application logic also
... using a declarative model
... need policy or "styling" for that application behavior
... translate the author's abstract UI into a concrete UI
... we have the possibility of not only programming-free applications, but also markup-free applications

Yong Tien: Question to Rhys: Does your solution require your authors to learn [new languages]?

RL: They need to learn less [than they would in order to mark up in HTML, CSS, JS directly]

Rocco: What technologies are you using to detect the device/browser?

RH: You use whatever evidence is available to you
... the matching mechanisms depend on a variety of strategies

<Rotan> FYI, the DDWG home page is http://www.w3.org/2005/MWI/DDWG/Group/

RL: We do things like varying the JS we deliver to a particular device based on what browser is running on that device.

Kai: Is content adaptation injuring mobile ajax?

RL: What Rotan and I provide sits on the origin server.
... Sean's/Novarra's solution is in the middle.
... in the Best Practices working group now, in the Content Transformation group, we are working on some guidelines, targeted for publication in mid- to late-November
... to provide guidance on how Content Transformation proxies -- the adaptation servers in the middle -- to provide guidance on how that should behave

RH: Another important point is to provide metadata in the Ajax that will assist in determining what can/cannot be changed.

What new standards efforts do we need?

DC = Doug Crockford, AR = Alex Russell, AS = Andy Sledd, DZ = Daniel Zucker

AR: Our position is that the Web works
... and that you don't need to do a lot of adaptation
... we support any effort to give us better access to device capabilities

DC: I agree with what Jon said about One Web earlier
... the biggest problem we are dealing with is Mashups
... the browser did not anticipate mashups
... which creates security problems
... we need to get that broken browser security model fixed
... browser makers have not been able to go forward without consensus
... but the Google worker-pool solution is one exciting recent development in this area
... but we have to wait for IE6 to die
... on the other hand, in mobile, because of the shorter longevity of mobile devices, we have quicker turnaround on [getting newer browsers deployed on handsets]
... [DC made statement that mashups are one of the most groundbreaking changes to come in many years]

AS: Fragmentation remains a serious problem
... and fragmentation will get worse before it gets better
... problems of timeouts needs to be considered, as well as mobile data-pricing models
... service discovery is also quite different on mobile devices
... Also, turnover and replacement rate of mobile handsets is decreasing
... Solution requires us to Keep the Door Open, refactor/refine problem statements

[Dan Zucker steps up]

DZ: "How to Standardize for Mobile"
... Of course we need mobile subsetting.
... it is a simple question of device physics
... The desktop standard is a moving standard also
... Typical way is to produce a "Tiny" or "Basic" subset of specific standard
... We propose instead a range of well-defined profiles between the "Tiny" and "Full" standards

BM: We have seen one thing come out: The only thing you can do is to set a minimum baseline, even though it is a moving target.
... the baseline is a market-consolidation activity
... What Dan Zucker proposes is only going to extend the problem
... Instead, tell the market that the full standard is indeed the goal.

AR: For Dojo, we are just dropping IE stuff
... we should be demanding that the device makers give us the full web on devices

BM: OMA Browsing Enabler 2.4 includes XHR

AB: CPUs on devices have now caught up

JF: The OpenAjax Alliance just started its Mobile task force in August

BM: Standardized security mechanisms should be on the list.

DC: What we need is a security model that encourages cooperation under mutual suspicion.
... I think Gears provides us the discipline in which we can solve that.
... We are loading modules but they are not really modules because they are not contained.
... The security model in browsers has never been good, but mashups have amplified the problem.

LL: People don't log into their mobile devices.

DC: It turns out that the ECMAScript language cannot be repaired in this regard.
... What Gears does shows us is a way to run multiple instances

Yong Tian: Another way to deal with this is build smart caching into browsers

scribe: and we should be approaching this by listing out the existing problems first, and then looking at what possible technologies we can use to address those problems.

Gideon: Most of what we have talked about doesn't consider at all is applications that integrate voice use of the handset with browsing and with web applications

JF: Standards activities usually do poorly when inventing.

BM: Market creation vs. market consolidation.

Education and evangelism

JF, DA: Acid2 Test and CSS Garden are examples of efforts that have been important in raising awareness of compliance with CSS standards.

BM: Those were successful in part because they were simple.

DA: CSS Zen Garden is great because it allows/invites third-party designers to contribute/participate

Howard: One thing might be, take a set of syndicated feeds, let developers loose to see what they can do with those [as far as building mashups]
... for CSS Zen Garden, it enables consultants to demonstrate/showcase what they can do
... so maybe start out with 10 or 20 developers build some demos, set them up at the site, then open it all up to participation from other developers

AB: We must be careful about seeing "getting better browsers on handsets" as a solution.
... there are economic reasons that drive the what applications get deployed on particular devices
... we will *always* have lower-end devices with browsers on them

DA: Do we need to come up with a standard that specifies what a "Web 2.0"-capable device is?

BM: At least part of this is the DD and UA profiling and other work that goes on in the W3C
... which in part depend on static information about what browser is installed on the device
... Some users now download browsers to their handsets.

Rocco: Sometimes it's a good thing to have a separate device/environment to develop apps in

<Rotan> http://www.fiddlertool.com/fiddler/

[Matt and Kai discussing browser support for MPAPI]

<matt> http://www.mozilla.org/press/mozilla-2004-06-30.html

<matt> http://developer.mozilla.org/en/docs/Gecko_Plugin_API_Reference:Scripting_plugins has some details

Wrap-up comments

Wrap-up comments: Standards are important part of the solution (and also a big part of the problem) ... APIs and mashups are important pieces ... Moore's Law will have a significant effect ...

scribe: let's do the work in current working groups, not start new ones ...
... it doesn't look like next steps have been addressed today, and I think we need to talk about next steps ...
... It's been interesting to see discussion of coupling between Javascript and Java on mobile devices ...
... Good to have heard about what expectations are for devices makers, in terms of browsing requirements ...
... Was good to discover some commonalities ...
... Get involved in standards activity at W3C and elsewhere ...
... the problems I'm looking at will not find solutions in a standards committee ...
... great to see people looking at the unique features of mobile devices -- not just looking at them as a poor cousin of desktop PCs ...

DA: In general, the place to follow up on work related to this topic is through the W3C public mailing lists, the OpenAjax Alliance ...
... the only barrier is in how many e-mail messages you are capable of reading each day ...
... But specifically, we will of course be producing a workshop report.
... watch http://www.w3.org/2007/06/mobile-ajax/ for details

Much thanks to Microsoft for hosting, and to Steve Marx in particular for helping with logistics and troubleshooting.

[workshop closed]