Scratchpad for the workshop: http://docs.google.com/Doc?id=dd3jk8v_68gmmnpx
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.
<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]
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.
JF: JSX?
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.
[Applause]
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?
[Applause]
[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".
[Laughs]
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]
[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.
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.
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: 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]