- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 19 Nov 2013 12:01:37 +0100
- To: public-web-mobile@w3.org
Hi,
The draft minutes of our F2F last week during TPAC are available at:
http://www.w3.org/2013/11/14-webmob-minutes.html
http://www.w3.org/2013/11/15-webmob-minutes.html
and copied as text below; please send corrections and additions to the
list.
More importantly, Natasha compiled a summary of the most salient points
of our discussions at:
http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face#Conclusions
Dom
WebMob TPAC F2F
14 Nov 2013
See also: [2]IRC log
[2] http://www.w3.org/2013/11/14-webmob-irc
Attendees
Present
Mohammed, Natasha, DKA, Bryan, Mounir, Ruinan, Kotakagi,
Christine Perey, Tobie, Sangwhan, JonathanJ, DanSun,
Kenneth, wonsuk, koichi
Regrets
Dom, Marcos, Jo
Chair
Natasha_Rooney
Scribe
mounir_, Dan, sangwhan, bryan
Contents
* [3]Topics
1. [4]First round of focus topics
2. [5]Update on Coremob Report
3. [6]Scrolling
4. [7]Testing
5. [8]Push API
6. [9]homescreen bookmarking
7. [10]API gap
* [11]Summary of Action Items
__________________________________________________________
<kotakagi> Intro presented by Natasha
<Ruinan> [12]http://www.w3.org/wiki/Mobile/Work
[12] http://www.w3.org/wiki/Mobile/Work
<schuki> [13]http://www.w3.org/wiki/InternetRelayChat
[13] http://www.w3.org/wiki/InternetRelayChat
<Ruinan> [14]http://www.w3.org/2008/04/scribe
[14] http://www.w3.org/2008/04/scribe
<schuki> action Natasha to speak to marcos re having no
teleconfs
<trackbot> Created ACTION-76 - Speak to marcos re having no
teleconfs [on Natasha Rooney - due 2013-11-21].
<mounir_> ScribeNick: mounir_
First round of focus topics
schuki: we are going to discuss a few topics that we discussed
before because we believe they are important for the web and
mobile
... we will discuss the history of these topics, the issues
that exists in current proposals/implementations and new
work/potential issues
... we want to make sure we get some outcome from this work
... we will have some guest speakers for some topics
... lets begin with the first topic, which is offline
... it has been a hot topic here at tpac
... if anybody has extra insights, please feel free to raise
your hands
<scribe> Scribe: mounir_
schuki: <describes appcache and localStorage>
... <describes what IndexedDB is>
... regarding the issues, appcache is hard to use, especially
for large applications
... appcache has a fallback system when there is no network
... this method is assumed to be broken
... people expect to use the cache first and download in the
background
... this creates strange issues
... lot of times with appcache, you have to declare things in
the server
... which is a bit hairy sometimes
... local storage seems robust enough but can only use strings
mounir_: the main issue is that it is actually doing sync
operations
schuki: regarding IndexedDB, the main problem is the learning
curve
... I will go to the new proposals to solve offline
... the first one is Service Worker, proposed by Alex, from
Google
... <showing the GitHub project>
... service worker is more robust that appcache
... it is solving the issues so far
... my personal opinion is that we should go and implement that
solution
... and I would encourage every one to follow the repo
... so, how can WebMob help with that?
... we could write a testing demo app
... any question or comment to the offline conversation?
... we will break for 45 minutes because the next topic
involves Bryan Sullivan and he is not here yet
... thank you everyone
Update on Coremob Report
<dka> Scribe: Dan
<dka> ScribeNick: dka
NR: We are evolution of the CoreMob group.
<schuki>
[15]http://coremob.github.io/coremob-2012/FR-coremob-20130131.h
tml
[15] http://coremob.github.io/coremob-2012/FR-coremob-20130131.html
NR: [presents the CoreMob report]
... Since the report was published, geolocation and video are
"interoperable".
dan: what does that mean? can we wait until marcus comes online
to clarify?
koichi: [speaking of yesterday's geolocation session]
<schuki>
[16]http://www.w3.org/wiki/TPAC2013/session-geolocation#Notes
[16] http://www.w3.org/wiki/TPAC2013/session-geolocation#Notes
koichi: [making reference to yesterday's TPAC breakout on
geolocation - and nest steps for geo API]
NR: I will add this as a note to the github.
... Marcus has raised a number of issues associated with the
coremob report. He's flagged a few of them as needing review -
meaning priority is higher. This give us the opportunity to
make further comments.
[17]https://github.com/w3c-webmob/coremob-report
[17] https://github.com/w3c-webmob/coremob-report
[18]http://coremob.github.io/coremob-2012/FR-coremob-20130131.h
tml
[18] http://coremob.github.io/coremob-2012/FR-coremob-20130131.html
NR: is this report applicable to what we do, or should we
create something else?
dka: I think we should not issue a new report, but rather we
should move forward on the basis of this report. Possibly we
should consider the issues raised and issue a new version.
NR: [more description of CoreMob report]
... [ presenting www.w3.org/Mobile/mobile-web-app-state/ ]
... this is a way to keep up to date with the specifications...
... [going through some additional comments]
<schuki> [19]http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face
[19] http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face
<schuki>
[20]http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Thursday#10
:45_Update_on_Coremob_Report_.28Natasha.29
[20]
http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Thursday#10:45_Update_on_Coremob_Report_.28Natasha.29
<schuki> 3 options to move forward:
<schuki> 1. continue to build the report
<schuki> 2. leave the report as it is and work on a new coremob
2013 / 2014 doc
<schuki> 3. leave the report as it is and work on
www.w3.org/Mobile/mobile-web-app-state/
tobie: having edited coremob report. There is some overlap
between coremob report and Dom's report (mobile web app state).
One reason I started it was to have the info in one place on
status of specs and implementations that we care about for
mobile.
... I don't think publishing a document is the best thing -
rather something with a shorter lifespan. Maybe something
slightly different - a central place that people can look at -
what's missing, what's the state and what should people look
at? I would try to merge these two documents.
<schuki> +1
NR: A document is pretty static...
tobie: another point - I've been building infrastructure to
make a document be a more live doc - there is info on the state
of specs available via an API - a document could have fresh
data on the state of certain APIs and so be up to date all the
time.
NR: that would be awesome.
+1
NR: any suggestions on keeping up to date with implementations?
tobie: this is related to running tests - I am leading this
effort to have a system to make it easy to run the test suites
people are building for each stack and make it easy for mobile
industry to run these tests internally, in a single place, with
an API - which could be build upon to show what the "state of
the union" is - we need resources to continue to this work.
<tobie> dka: we should wait for dom to make a decision on this
Mounir: if you go to chromestatus.com you have a huge list of
features you can reference in chrome.
<tobie> … also see if there are info from the current vendors
available we could leverage.
<schuki> [21]http://www.chromestatus.com/features
[21] http://www.chromestatus.com/features
NR: we could pull this kind of thing into automatically update
the document that we choose...
dka: what does it mean to have a live document?
NR: I'd like to choose one or the other - my preference would
be to continue with the webapp state document.
... we can manually add to it in the short term, incorporate
material from other sources with the goal having it be
completely automated.
<schuki> action Natasha to check coremob and webappstate doc
include the same spec
<trackbot> Created ACTION-77 - Check coremob and webappstate
doc include the same spec [on Natasha Rooney - due 2013-11-21].
dka: do we update the coremob doc to point to mobile web app
state? and does mobile web app state contain all the same specs
as coremob?
<schuki> action natasha to check with dom whether we can
discontinue coremob and just work on webappstate
<trackbot> Created ACTION-78 - Check with dom whether we can
discontinue coremob and just work on webappstate [on Natasha
Rooney - due 2013-11-21].
<schuki> action natasha to check status of chromestatus +
testing effort and see if we can add apis to manage the
webappstate document automatically (long term goal)
<trackbot> Created ACTION-79 - Check status of chromestatus +
testing effort and see if we can add apis to manage the
webappstate document automatically (long term goal) [on Natasha
Rooney - due 2013-11-21].
NR: if people are interested in working on webapp state
document or coremob doc - then please let us know.
dka: how are we going to continue the work of coremob? e.g. for
new use cases, new features, new specs, etc...
NR: we are going to work on focus topics, e.g. offline, spec is
service worker, service worker spec will be included into this
document...
dka: where will we document the use cases that come out of the
focus topics?
NR: there is no need to work on use cases or requirements for
these focus topics...
... we can continue to write scenarios such as in the coremob
document - we can say "we thing web apps should be able to do
XYZ in the future"... but we need people to write those
scenarios down.
... the only way it will happen with people being busy is if
its a regular recurring action / topic.
... sometimes the answer might be we don't have any new ones -
or new ones may arise, e.g. with augmented reality.
dka: does that document become a document of this working
group?
NR: in some cases we don't need to create requirements - e.g.
offline where they already have use cases and requirements. We
need to find out what is missing and then put it in.
... the wiki describes the group in better detail. We can add
use cases and requirements.
<schuki> action Natasha to add to DELIVERABLES: adding use
cases / requirements section to coremob / mobilewebapp state
document and add use cases / requirements to regular meetings
<trackbot> Created ACTION-80 - Add to deliverables: adding use
cases / requirements section to coremob / mobilewebapp state
document and add use cases / requirements to regular meetings
[on Natasha Rooney - due 2013-11-21].
NR: I'm going to add "the document" to our deliverables and add
use cases and requirements to our regular meetings - a regular
deliverable for us.
dka: cordova is starting to produce stats about what apis apps
produced with cordova actually use.
tobie: we worked on this at Facebook 2 years ago - it's a good
exercise [analyzing top 100 apps]. I saw work on the mailing
list that did some not manual work - automated analysis of
android APIs. the output of that data is wrong, and brings the
focus on the wrong feature set. Intrepreting the data is the
tricky thing. The permissioning model of android is different
from android - a lot of the key APIs that came out of that
discussion don't transpose to the Web.
... you need to do some manual work.
dka: I don't disagree.
NR: we will talk about that in closing the gap with dom
tomorrow as well.
<tobie> Phonegap data looks like a great source of information
NR: Any other comments?
CP: did anyone look at business models?
NR: We want to do that - it's key to organizations who are
members - especially from operators.
... business models are important - use cases might dip into
that.
... we could have business use cases.
CP: I was more thinking that native apps have business models -
they are sold or have something sold in them [in-app].
NR: One of the focus topics is on payments - which is related.
It's different with apps - it's a "closing the gap" topic.
There is an easy way for a native app developer to [monetize].
Mounir: there is business on the web and also you can sell
webapps...
... i don't feel there is much technical solution /
[discussion] we need to have there...
tobie: when we started the coremob CG - we were looking at 3
aspects.
... one is closing the gap
... two is the business model. You need to have developers who
are making money.
... the last is distribution - app markets, search, social
channels...
... making money building web applications is a problem - it is
solved to some extent through ads and through payments. One
thing that hasn't been addressed yet is to think about carrier
billing - these apps are running on devices that are connected
to users' phone bills?
mounir: is carrier billing something that people use out of
developing countries.
dka: Telefónica has direct-to-bill payments rolled out with
Microsoft and Google (app markets) in Spain and for Microsoft
app market in the UK. It is effective when it can be done.
There are challenging regulatory and integration issues which
have held them back.
NR: I like the idea. Dave Ragget will come talk about web
payments tomorrow.
dka: I am co-chairing the upcoming workshop on web payments
happening in March - a core part of this will be mobile
payments.
NR: one thing we could do in this IG is to work on use cases
and requirements.
CP: not everyone is looking for financial payment - focusing on
payment might be limiting.
NR: examples?
CP: social reach, branding outreach, barter...
... other economies -
NR: the Web naturally reaches more people than native
platforms...
... lots more web users - I will find the research.
<Zakim> tobie, you wanted to comment on biz models and to
tobie: interesting - about other incentives - but that said it
would be good for this group to answer the question of
precisely what part of the ecosystems are needed for there to
be a turning point where mobile web is good enough to compete
with native.
... what's missing is the quality applications and premium
content on mobile which is not accessible on the web right now.
<Zakim> tobie, you wanted to comment on mobile strategies
dka: star trek example - star trek poster on the underground
says "download our app" at the bottom - there is a reason they
put that there to engage the end user to go to the cinema to
watch a movie - what's stopping them from putting "go to our
web site"?
tobie: use case for looking up flight times in genevva -
couldn't access landing times for planes from an iPhone... so
what was wrong with the airport? after that, I saw "gvapp" -
the airport's mobile strategy is "let's have an IOS app and an
android App".
... an international traveler going to download an app just to
get airport info? doesn't make sense. Companies are trying to
have a mobile strategy and they hire someone to build apps -
and the only thing they know because it's cool and trendy is
IOS and Android. But for a ton of use cases which would be
better served by the web - this a key item to discuss. We need
a strategy to address this.
+1
NR: this will get taken up as closing the gap.
tobie: it's not a technological problem - it's educating
developers and also addressing the business-level people -
giving the message out that the web solves a bunch of use cases
better than native.
... having an add with "download this app to engage" is a daft
strategy,
... it's hurting businesses - there is a strong business case
to be made for the web in lots of scenarios.
Mounir: from a tech standpoint we are mostly ready - but people
are not used to using web apps on the mobile - it's a mind-set
issue. If you go back a couple of years ago, it was "IOS app"
now it's "android and IOS" so hopefully it will change...
dka: as the number of platforms increase will the
interoperability story of the web start to resonate more?
Mounir: do we know how much cordova is used - e.g. in the
android app stores?
tobie: I believe it is something like 4% - so 1000s of apps.
<schuki> action Natasha to add 'education to devs on how the
web solves your app use cases' to things we want to work on, as
maybe the gap in development is due to education as well as
other factors
<trackbot> Created ACTION-81 - Add 'education to devs on how
the web solves your app use cases' to things we want to work
on, as maybe the gap in development is due to education as well
as other factors [on Natasha Rooney - due 2013-11-21].
tobie: still today a lot of content in the native Facebook app
is HTML5 - one of the reason we expanded the native element was
the performance issue.
... I will dive deeper into this - e.g. scrolling performance -
later today.
... the technological gap needs to be addressed. Companies that
have enough resources are handling the technical challenge by
going native and handling the multiple code bases problem by
keeping as much code as possible as html5.
... not addressing the cross-operating system thing that much.
what they are addressing is that it's difficult to ship a new
application. On the web you ship the code and agile companies
are shipping code to production many times a day - you can't do
that with native. Outside of this particular issue which is
applications that have requirements to be native - there are a
lot of use cases that would be better for everyone if they were
a [expletive deleted] web site.
NR: I've added education as an action.
tobie: also education to c-types; to business guys.
NR: lunch now
... back at 2
<tobie> OWP on mobile has a branding problem
<sangwhan> scribenick: sangwhan
<schuki> [22]http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face
[22] http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face
<schuki>
[23]http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Thursday#4p
m:_Focus_Topics_Round_2
[23]
http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Thursday#4pm:_Focus_Topics_Round_2
<schuki>
[24]http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Thursday#4p
m:_Focus_Topics_Round_2
[24]
http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Thursday#4pm:_Focus_Topics_Round_2
[Self introduction time]
Scrolling
Natasha: this afternoon we will be covering several topics
... as on the screen (wiki page)
... we are doing some small task forces to help developers
write mobile apps
... if you have questions add yourself to the queue
... please use the irc if possible
... tobie will talk a bit about scrolling, and sangwhan might
add some commentary
tobie: i looked into this a bit, while i'm not the best
candidate to talk about this
... before working testing in w3c i worked on mobile related
matters
... one of the reasons why we did a transition between
web/native was scrolling performance
... smoothness is key, and smooth scrolling is a difficult
problem to solve
... apart from gaming, it is one of the most intensive
operations on mobile platforms
... i've been trying to get the css working group to find a
solution to this
<dom> [25]http://dev.w3.org/csswg/cssom-view/#scrolling
[25] http://dev.w3.org/csswg/cssom-view/#scrolling
tobie: some of the suggestions i got from fb engineers have
been shared on the coremob list
... while i don't have a solution this group should definitely
look into this
... infinite scroll is something i would like to see in future
applications
... this isn't particularly easy due technical challenges of
how browsers work
... the big problem is that devs are implementing these
features in js
mounir_: Does using a worker to fetch data help?
<dka> Good example of infinite scroll: qz.com - also one of the
companies /web sites on the forefront of the progressive mobile
web.
tobie: workers are pretty much what everyone uses
... but it still doesn't help because layout et al is done in
the main thread
... cloning the dom tree into a worker might be one approach
... you could possibly bind processors to particular elements
in the dom
... neither i nor the group should be the ones who come up with
the solutions
... and we should bring the problems to the groups and have
them solve it
Dan: the web is a page, with a top and a bottom - and infinite
scrolling is a different metaphor
... there are clear philosophical differences between the
initial design and infinite scrolling so far is a hack that
goes on top of it
... has this been discussed or is this a tag issue?
tobie: probably tag
... ever since i started working with the w3c the market has
already changed from documents to applications
<bryan> +1 the infinite scrolling ship has already arrived in
port
<schuki> [26]http://dev.w3.org/csswg/cssom-view/#scrolling
[26] http://dev.w3.org/csswg/cssom-view/#scrolling
tobie: scrolling through a lot of content is something that we
would want to do
Dan: I was talking about a page, where a end of the page is the
end of the page
... what i was noting is that you are bringing up that now the
end of a page isn't really the end of the page
tobie: Ads probably influenced this
... but on a mobile device scrolling and swiping is a natural
ux
schuki: thanks for the input
<schuki> sangwhan: appending things to the dom comes with a
memory problem, so there needs to be some work on garbage
collection
<Dong-Young_Lee>
[27]http://www.sencha.com/blog/the-making-of-fastbook-an-html5-
love-story
[27]
http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story
sangwhan: mobile devices have limited memory, and while
infinite scrolling is a natural ux you'll eventually run out of
memory
... e.g. explicit gc of elements that have left the viewport
tobie: while you have a point and this is necessary, this is
not necessarily gc but there should be a solution
bryan: re what tobie posted to the coremob list, we researched
those issues and verified many of them, e.g. particularly for
HTML5 games - Scrolling and UI fluidity, touch events/tracking,
Hardware acceleration control, Multiple audio tracks for
background & effects, Audio sync with animation & video
christine: i consider the infinite scrolling problem as a
infinite map
... we should think about this in a approach where this is a
map, not a list
tobie: good point
... it should be made so that there are components that can be
used
<bryan> these items I listed are on our performance priority
list for WebMob re closing the gap with native
tobie: if you have a blob of data that you want to look at, you
want the native layer to do the heavy lifting
... a lot of data in a small screen, we just need to figure out
the most sound technical solution to address this
<bryan> we need to document the gaps on the wiki with links to
examples and analyses that people can reference
JonathanJ:
[28]http://dannysu.com/2012/07/07/infinite-scroll-memory-optimi
zation/
[28]
http://dannysu.com/2012/07/07/infinite-scroll-memory-optimization/
tobie: there are a lot of things that fall into the scrolling
category
... not sure if css wg has looked into this
<dom> has anyone brought up CSS OM View yet?
mounir_: @@@ has been trying to address this problem
<dom> [29]http://dev.w3.org/csswg/cssom-view/#scrolling
[29] http://dev.w3.org/csswg/cssom-view/#scrolling
tobie: we should come up with the problems and approach the wgs
mounir_: nowadays, browsers are doing off the main thread
scrolling/compositing, if you use those modern browsers,
workers and be mindful with memory usage (do not keep the
entire newsfeed in the DOM), maybe things could already be
better? I feel that there are some experiment that could be
done here.
tobie: if you keep adding stuff at the end of the dom you'll
hit problems
... the reason why devs get it "wrong" is because it's not a
simple problem
... browsers should try to address this
schuki: we need to move on to the next topic
... next topic is testing
... which is also covered by tobie
Testing
[Tobie asking people if they are familiar with the testing
efforts]
<schuki> action scrolling use cases should be documented, also
make notes as we may need user agent action as well as
developer-focused options
<trackbot> Error finding 'scrolling'. You can review and
register nicknames at
<[30]http://www.w3.org/Mobile/IG/track/users>.
[30] http://www.w3.org/Mobile/IG/track/users%3E.
<bryan> how to continue the CoreMob focus on setting priorities
for testing of features
tobie: those who are unfamiliar feel free to ask questions
tobie: wrt testing is that it's expensive and companies need to
fund it
<schuki> action Natasha (to reassign) scrolling use cases
should be documented, also make notes as we may need user agent
action as well as developer-focused options
<trackbot> Created ACTION-82 - (to reassign) scrolling use
cases should be documented, also make notes as we may need user
agent action as well as developer-focused options [on Natasha
Rooney - due 2013-11-21].
<bryan> we need to know what the users need, and focusing the
effort to analyze priorities will help optimize the ROI for
mobile stakeholders
<bryan> we need to measure what users need explicitly through
outreach, polls, etc. depending just upon what the insiders
think will only take us so far
<bryan> the WebMob group can help focus this effort as a
community of interest
mounir_:
<bryan> we need a WebMob 2014 document or something similar, to
help frame the current thought on key testing goals. Our
position at the close of CoreMob was that CoreMob 2012 was not
a "one and done"
mounir_: We discussed testing APIs that are hardware related a
few months ago, like battery api or a messaging api. It is hard
to test because you do not have access to the hardware to
verify if what should happen happen. Do you have any update on
this?
schuki: next topic will be covered by bryan
Push API
<JonathanJ> [31]http://www.w3.org/TR/push-api/
[31] http://www.w3.org/TR/push-api/
bryan: if we want someone to fund the mobile testing we need to
make sure that people understand that we will make good use of
it
... the spec you are seeing is a working draft of the push api,
from 4 months ago
<JonathanJ> [32]http://www.w3.org/2013/03/push-pag-charter
[32] http://www.w3.org/2013/03/push-pag-charter
bryan: we are currently going through a pag
... we had some other work in att going on to send
notifications
... what we have here is similar to that, but the current spec
needs a prior agreement
... there was wap, but for the web we needed something simpler
... for this we came up with a api that is delivery system
independent
... the spec doesn't talk about what the transport mechanism
is, and that was part of the goal
... in the spec we mention a couple standard transport methods,
but there are many non-standard methods as well
... the toc in the spec gives you a pretty good outline
... the security model is based on the DAP approach
... initially we did not use promises, but now most specs
including ours has changed to make use of promises and service
workers
... there are some things we need to work on, i don't have a
very good understanding of service workers
<JonathanJ> Service Worker -
[33]https://github.com/slightlyoff/ServiceWorker/blob/master/ex
plainer.md
[33]
https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md
[Q&A about technical details of Service Workers]
DanS: my understanding of SW is that it won't work when there
is no browser
... how to make this transport independent?
bryan: that is what the spec looks like as it is
... it's explained to some extent in the flow chart (in spec)
... how the push registration would work we'll need the UAs to
figure out
... the current api lets implementations even work completely
offline
tobie: what do you mean by offline?
bryan: mobile phones can have data off
... there is a signalling system that lets you make phone calls
... i was mentioning this
tobie: the next step should be to take the spec and look at
which parts of the spec can be implemented using service
workers
<anssik> +1 to tobie's suggestion
<anssik> re push & ServiceWorkers, see
[34]https://gist.github.com/slightlyoff/7fae65a908ac318f69a3
[34] https://gist.github.com/slightlyoff/7fae65a908ac318f69a3
<JonathanJ> I think that ServiceWorker likes active service
manager, Push API likes passive service manager
<schuki> action Natasha (tp reassign) in push api doc there are
use cases, we should map them against the push use case in
service worker and see what the gap is between the two
<trackbot> Created ACTION-83 - (tp reassign) in push api doc
there are use cases, we should map them against the push use
case in service worker and see what the gap is between the two
[on Natasha Rooney - due 2013-11-21].
Ruinan: @@@
mounir_: @@@
bryan: we had two considerations when designing the spec, one
is scalability
mounir_: i disagree with your position regarding privacy
... #@!#@!
<bryan> +1 to Eduardo's support (the major contributions so far
actually)
<JonathanJ> +1 me too
bryan: is this group interested in discussing unresolved
questions of the push api
<schuki> action Bryan to send email to public mailing list
about anymore work to be done on push api
<trackbot> Created ACTION-84 - Send email to public mailing
list about anymore work to be done on push api [on Bryan
Sullivan - due 2013-11-21].
<bryan> ScribeNick: bryan
homescreen bookmarking
natasha: discussion on the list led by Marcos and Ernesto on
homescreen bookmarking
... link is
[35]http://w3c-webmob.github.io/installable-webapps/
[35] http://w3c-webmob.github.io/installable-webapps/
dka: are they looking at the manifest-based bookmarking?
... in FFOS we have a manifest based upon the W3C Widgets
Manifest format
... this is where we think things re going, to install via
manifest via an appstore
... looking at FT (Financial Times) on FFOS, it uses the API
FFOS exposes to check if installed, and offer to user to
install if not. It's a hosted app with a JSON manifest.
<JonathanJ> web manifest -
[36]http://www.w3.org/2008/webapps/manifest/
[36] http://www.w3.org/2008/webapps/manifest/
dka: those are our use cases. we've seen Chrome implement a
similar functionality. So it would be a mistake just to focus
on the iOS save to homescreen capability
schuki: our focus is not limited to that
dka: we should document that set of use cases as described
... documenting the user experience that is wanted should be
part of the document
schuki: all of the approaches should be included; some action
on the TF to ensure that, may need some help
... other call for any more collaborators, please let Marcos
and Ernesto know. we need people to help out
<wonsuk> Use Cases and Requirements for Installable Web Apps:
[37]http://w3c-webmob.github.io/installable-webapps/
[37] http://w3c-webmob.github.io/installable-webapps/
<schuki> [38]https://github.com/w3c-webmob/installable-webapps
[38] https://github.com/w3c-webmob/installable-webapps
bryan: we should get actual user input on what the install
experience should be or would be nice, with some example/demo
videos on which we could get user feedback
schuki: developer events may be one way to get that input
dka: someone could step up with money to do a user mockup
testing
bryan: maybe thru ADA?
kenneth: maybe a google+ group since there are a lot of devs
there; also for getting feedback on issues to avoid
schuki: if anyone wants something else they need to get
involved
... next is to setup a google+ or github group for comments on
ideas
<schuki> action Marcos check whether you have firefoxOS
included in the installable web apps doc, and if not add it,
ask Dan A for help
<trackbot> Created ACTION-85 - Check whether you have firefoxos
included in the installable web apps doc, and if not add it,
ask dan a for help [on Marcos Caceres - due 2013-11-21].
<schuki> action Natasha setup a github repo / google+ group to
canvas opinions from devs on this topic
<trackbot> Created ACTION-86 - Setup a github repo / google+
group to canvas opinions from devs on this topic [on Natasha
Rooney - due 2013-11-21].
bryan: we could also include some demo code in the doc to show
how devs currently and in the future might use the features
(maybe it's already there)
API gap
<dka>
[39]https://www.dropbox.com/s/51bmutcuqikz03e/Visionmobile-Tele
fonica-How_Can_HTML5_Compete_with_Native.pdf
[39]
https://www.dropbox.com/s/51bmutcuqikz03e/Visionmobile-Telefonica-How_Can_HTML5_Compete_with_Native.pdf
dka: you may have read this report from vision mobile,
sponsored by Telefonica
... the idea was to canvas the dev community and tools vendors
on key gaps between native and web on mobile
... one key finding was around performance
... as an issue its on the radar as a key focus area; tobie was
addressing performance earlier;
... but other urgency is on APIs - there is some controversy
around this re bringing it to par with native
... devs go native to get access to APIs not available on the
web; this is changing, and the more APIs we have, the stronger
the argument about embracing the web
... e.g. the starwars poster with a QR code linking to an app
store vs a web app - fgor now they say it wont work and go away
... Jo feels that to a certain extent the web will never catch
up to native
... e.e. latest dark matter or alien detection API
... the argument I would like to put forward is that we need a
major shift in how users use the web on mobile devices
... a UI that is from the 80s e.g. mouse/pointers, is not
aligned with a world of touch screens
... kids learn how to use a mouse at school as they did not
grow up with it.
... the point is that accelerated of development in the
platform is not sustainable; we will go thru further shifts but
should expect that the touch interface and APIs will be around
for a while
... with these key APIs and knowing which are popular, let's
add them to the web; native will still be attractive to those
that need what the web can't provide, but let's add the core
features we can
... the point is what is the relative priority on APIs that are
currently in the gap
... Tobie raised some issues around how to survey; but let's
have some discussion on what's important on that list
<view>
[40]http://www.slideshare.net/andreasc/how-can-html-compete-wit
h-native
[40]
http://www.slideshare.net/andreasc/how-can-html-compete-with-native
<dka> Popular Cordova APIs
<dka> org.apache.cordova.file
<dka> org.apache.cordova.camera
<dka> org.apache.cordova.splashscreen
<dka> org.apache.cordova.network-information
<dka> org.apache.cordova.geolocation
<dka> org.apache.cordova.vibration
<dka> org.apache.cordova.media
<dka> org.apache.cordova.media-capture
<dka> org.apache.cordova.contacts
<dka> org.apache.cordova.device-motion
<dka> org.apache.cordova.device-orientation
<dka> org.apache.cordova.battery-status
dka: e.g. talked to Phonegap on that are the popular APIs in
that platform; through tht product they have been able to ID
what are popular APIs in the system or requested
... this is initial data, popular APIs that Cordova devs are
requesting
... interesting that net info is a highly requested API; its
been a persistent question in W3C e.g. whether this is a short
term issue
<JonathanJ> Standards for Web Applications on Mobile -
[41]http://www.w3.org/2013/09/mobile-web-app-state/
[41] http://www.w3.org/2013/09/mobile-web-app-state/
dka: I would argue that devs are still requesting this API, IMO
this falls under the category that "the device knows about it
but we are not letting the webapp know about it" - why?
... I asked about the use cases for offline and knowledge of
the net info ... (missed the rest)
... going on, some are contentious - some are already in scope
for W3C e.g. battery
... hoping to bring more voices into this, and to put this into
a report
<schuki> khronos
christine: I've been working closely with different stds orgs,
one common question e.g. with Kronos, WebGL, WebCL are
available for devs
<dka> [42]http://www.khronos.org
[42] http://www.khronos.org/
christine: Khronos would like to make all these APIs available
to devs on the web; Khronos do not do the web so need help
... on Dan's list, 7 of 10 are known/used by the Khronos APIs
... camera is being worked on; a new one is stream input on
devices capturing sensor data; Khronos would like to ensure
these APIs are supported by lower-level silicon APIs
... several meetings so far but no actions have been taken
<schuki> bryan: we have a problem getting APIs built in w3c
<schuki> ... sys apps has picked up some stuff, DAPs is still
running with stuff
<schuki> ... network information: I wrote a report about the
saga on this
<schuki> ... we don't need to know what network we're connected
to
<schuki> ... we should express what the developer wants
<schuki> ... dev wants to deliver a request effectively
<schuki> ... network info api is good for network efficiency
<schuki> ... another way to say to the browser "get me the
resource within the next 10 mins"
<schuki> ... another idea is to get the resource, and i don't
care how, just get it
<schuki> ... network info api as a way to promote efficiency
has other approaches
<schuki> kenneth: service worker can do this
kenneth: that works pretty well with the service worker concept
dka: looking at the vision mobile report, limited access to
hardware APIs is second only to performance issues
<dka> Vision mobile report says 37% of developers don't choose
Mobile Web (HTML5) because of lack of API support.
wonsuk: I am curious why power and wifi APIs are in here
dka: this is one source of info in looking at most popular
APIs. programmatic research was used to determine which APIs
are popular, but also there was a lot of 1-on-1 interviews of
devs and tools vendors
wonsuk: we can consider which APIs e.g. power and wifi are
possible based upon this input
dans: I am surprised that FFOS have so many APIs, in slide 6,
98% of Android apps can be implemented in FFOS in terms of the
APIs they use
<schuki> bryan: when we started doing wac we found a few number
of webapps used no APIs at all
<schuki> ... so we could just package them
dka: many FFOS APIs are not standard, and support animated
games for example. the 98% figure needs to be verfied
... some games e.g. do not need APIs
schuki: going back to Kenneth's comment on service worker, we
will take data-driven approach rather than a documentation
approach (captured correctly?)
dka: the idea of the report is to make this data public through
the group, so we can point to it when we need to. we need work
on the backup data, but when people ask for research this is a
data source
schuki: Dom will give us an overview in the closing the gap
report in a later session
... suggest we defer the UI Primitives topic to tomorrow
<JonathanJ>
[43]http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Friday
[43] http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Friday
some suggestions for tomorrow on WebMob focus - Help review and
improve mobile-focused info on [44]http://docs.webplatform.org/
- Linking to WebMob from [45]http://www.w3.org/Mobile/ -
Helping Dom maintain the info on [46]http://www.w3.org/Mobile/
[44] http://docs.webplatform.org/
[45] http://www.w3.org/Mobile/
[46] http://www.w3.org/Mobile/
Summary of Action Items
[End of minutes]
--------------------------------------------
Web and Mobile Interest Group F2F meeting (day 2)
15 Nov 2013
[2]Agenda
[2] http://www.w3.org/wiki/Mobile/TPAC_Face-to-Face_Friday
Attendees
Present
Dominique_Hazael-Massieux, Jonathan_Jeon, Natasha, DKA,
Bryan, Ruinan, Kotakagi, Christine Perey, DanSun, koichi
Regrets
Marcos, Jo
Chair
schuki
Scribe
schuki, dom
Contents
* [3]Topics
1. [4]closing the gap
2. [5]web standards roadmap
3. [6]Payments
4. [7]permissions on the web
5. [8]WebDriver
6. [9]Security
7. [10]Developer tools / debugging gap
8. [11]Summary
* [12]Summary of Action Items
__________________________________________________________
trackbot, prepare meeting
<trackbot> Date: 15 November 2013
closing the gap
dom: most people think the mobile landscape is between ios and
android
... the good news is most of this analysis html5 is the 3rd
platform
... on desktop however, it seems web is no 1
dom: anyone making a choice about providing content to their
users need to make a decision
... when a dev is making a trade off between web and native,
what do they consider?
... user experience, and provider considerations
... in user experience some of the things that are important
are: discoverability, obtainablity, usability, upgrade process,
secuirty / safety / privacy
... provider consideratons: develop costs, deploy, profit, ??
dom: when you weigh it up you find
... web is better for discoverability, obtainability, upgrade,
deployment, develop costs, and security (some people might
disagree)
... native is usally better for use and profit
... this analysis is for desktop
... when put this way it seems web has much better opportunity
for desktop
dom: for mobile you get a much different picture
... on web discovery, obtainability, upgrade, staying safe and
deployment is easier than on native, but the ease / advantage
isn't as large as in the desktop model
... and native use, development and profit is stronger
[13]http://w3c-webmob.github.io/gap-analysis/
[13] http://w3c-webmob.github.io/gap-analysis/
...the payment process is much more streamlined in native,
making money is a lot easier in mobile native development
... web payment is not as efficient in mobile
... therefore native is probably stronger for mobile at this
time
... web has a larger number of plus points, but the negative
points outweight these
dom: I imagine people here today want to strengthen the web for
native
... the question is; what can we do to change this balance?
... i think we need to reduce the disadvantages (starting with
user exp) and then work on building on the advantages
dom: in this ppt I didn't go through the finer details of the
gap, but in the report I wrote it has a lot more of this detail
... my point is what we need to do is look at these values and
find out what are the priorities to making the web the place to
build mobile applications
... what is making the users and developers choose native -
lets answer this.
dom: the one thing i haven't looked at is the type of apps
people are building
dom: we would like to see where the web has a stronger presence
on desktop
dom: lets take news for example
... whilst many people go to the web for news
... newspapers still think they need to have a native
application
... i would be interested to know whether people feel like this
is an interesting topic
bryan: this is great, it would be good to think of how we're
going to have a dialogue on the doc
dom: the doc is on github, i would like people to do pull
requests on the document
... you are also welcome to send tips to the mailing list
<schuki> a/comments/comments
bryan: what research states that offline is problematic
... and what do people do to breach that gap
... so why is it a gap, what are the alternatives, and how will
they satisfy the market?
dom: a lot of this info stems from what facebook brought to
coremob last year
dom: yes you can do offline on the web
dom: but quota management is difficult
... app cache doesn't work
... etc
bryan: for certain types of apps, what do devs want to do
bryan: I have been doing this with a number of apps (building
offline) very successfully for 3 years
bryan: i think we need to provide some more perspectives
dom: i agree
<bryan> The lifecycle and roles could be looked at in more
detail, to identity gaps that may be hidden by the high level
of abstraction in the lifecycle from user & developer, as shown
on the slides. For example, as shown by my 2012 presentation at
the AT&T Developer Summit
([14]http://developer.att.com/home/community/conference/HTML5.p
df), the areas to consider include: developer communities, open
source code availability, SDKs, emulators,
platform/ecosystem-specific ce[CUT]
[14] http://developer.att.com/home/community/conference/HTML5.pdf)
bryan: at wac we put a lot of effort into thinking of the
lifecycle
... of how a dev build an app
... we also went into how a user discovers apps
dom: one of the great advantages the web has are the links
<bryan> The application category is one dimension, but there
are others that are more horizontal e.g. accessibility - or
maybe that needs to be another column
bryan: horizontal aspects would be good
... e.g. accessibility
dom: the reason why native is so strong over mobile is native
has learnt a lot from the web
... as native on mobile came after the web native could learn
from the trends on the web
... accessibility is on the document but it is a bit of a bolt
on atm
... security and privacy could also do with some work
bryan: I had a discussion with Lisa (seacat deluca) about
closing the gap
... and we need some experts to talk about accesibility
dom: there is a new accessibility task force that has been
setup
... this should be able to help us
<bryan> one of our goals for WebMob is to look at gaps in
various domains including accessibiity, e.g. are native device
accessible features also innately applicable/usable in the web
browser environment, or are there further gaps to close
DanS: I concur that it would be good to keep up with
accessibility
... images is another interesting topic
dom: on native you can download as much as you want for offline
storage
... but for web it is a lot harder
... so I mentioned images because they are heavy and take up a
lot of space
DanS: what about the file apis?
dom: last I heard there was a discussion in the web apps group
re file system apis
... there may be a new approach to file system
... one of the biggest limitations to all these solutions (web
storage, file, indexed db)
... the issue is space
... for app developers it's a real difficulty
schuki: generally speaking, there are ways to run offline web
apps
... but there are problems with scalability
... the current solutions are built in a difficult flow
... there are interesting trends in app development
... you would want to pull content in the background when on a
better connection
dom: there are a number of things that are critical in closing
the gap
... development tools is one of these issues
... also deployment steps
... and making a business out of apps
dom: as we know advertising on mobile (smaller screen) is hard
to get right and keep the user exp
... app stores makes it easier to make money
... one of the items we can discuss in the payment session
could be getting paid
... how does a developer get paid on the web? in app stores
there is a standard model
dom: google is doing well with new payment systems
... making it easier for users to complete payments
dom: so we should think about how we can close the gap, and
build on this document to help this
dom: one thing that this group could have a role to play is
looking at different types of devices
... on the screen is a car, tablet, tv, camera, clock
... users will change from one device to the other
... connected devices are getting more and more diverse, we as
a group should be working on what the web could do for all the
different user experiences
... the web could also help not by competing with native, but
by embracing it
schuki: google request auto complete for filling out forms:
[15]http://www.chromium.org/developers/using-requestautocomplet
e
[15] http://www.chromium.org/developers/using-requestautocomplete
dom: how can we make sure we are pushing away the silos
<JonathanJ> [16]http://www.w3.org/2013/Talks/dhm-mobicase/
[16] http://www.w3.org/2013/Talks/dhm-mobicase/
bryan:
... this area od links, intents and activities (around hybrid
apps) is something we should look at
... hybrid app's dom is different from browser dom
... there is no method to do messaging between them, etc.
... the openID foundation is working on distributing keys based
on the URI concept
... it works but there would be some things that would work
better if we had messaging between web and hybrid apps
dom: a few other examples of what we may want to look at
include; appurl (quixey) is using a url by detecting the device
and redirecting where a user goes based on their device
<JonathanJ>
[17]http://www.w3.org/2013/Talks/dhm-bringing-web-native-closer
/
[17] http://www.w3.org/2013/Talks/dhm-bringing-web-native-closer/
dom: i am interested to know with web intents / activities etc,
do we want to take this on?
shucki: Web Intents and Activities might be a good way to look
at this
... similar to what DKA presented on top APIs used in PhoneGap
<bryan> event if we don't have bandwidth to address all these
issues, it would be good to put them on a wiki as gaps that we
could close in the future, or watch and report on how things
develop in the interim
DanS: question about ads, is there something going on to help
with this?
dom: we don't have an answer right now
schuki: next steps?
dom: bryan will send input on the report
<schuki> action bryan to send input to the closing to the gap
report to the listy
<trackbot> Created ACTION-87 - Send input to the closing to the
gap report to the list [on Bryan Sullivan - due 2013-11-22].
dom: i am wondering if the type of app analysis should continue
schuki: +1
dom: can DanS help on ads?
DanS: not sure, too early for me
dom: i will just add it as a line item for now
<schuki> action dom add ads on closing the gap report (just add
a title for now)
<trackbot> Created ACTION-88 - Add ads on closing the gap
report (just add a title for now) [on Dominique Hazaël-Massieux
- due 2013-11-22].
<schuki> action natasha (to reassign) get someone to help out
on ads on doms closing the gap doc (Dan Sun)
<trackbot> Created ACTION-89 - (to reassign) get someone to
help out on ads on doms closing the gap doc (dan sun) [on
Natasha Rooney - due 2013-11-22].
<schuki> action bryan to ask Lisa to see if she can help out on
accessibility on the closing the gap doc
<trackbot> Created ACTION-90 - Ask lisa to see if she can help
out on accessibility on the closing the gap doc [on Bryan
Sullivan - due 2013-11-22].
dom: can people let me know if they want to continue this work?
schuki: I've heard people want to see it continue
<schuki> +1
<manu2> +1
schuki: we need people to give feedback/input
<dka> +1
<JonathanJ> +1
<Ruinan> +1
dom: this analysis framework is good, although we are looking
to go to a different structure and put this in a more accesible
place
bryan: I think it is a good idea, taking this stuff to become a
dashboard
<schuki> +1
dom: i know we talked about this with reference to the coremob
report
<Zakim> dka, you wanted to say it's important to show how far
we've come as well.
dom: after the break we will talk about the web app standards
doc and we can discuss this dashboard idea
dka: the other thing I wanted to ask was about the vision of
where the web plays in the web of things discussion
dom: this is a demo where I move a phone and it replicated a
canvas on a browser on another device
dom: this is cool but I think the thing we need is design
patterns
... we might not have the right people here to do that
... but it would be great if we could
<schuki> [18]http://specs.wacapps.net/
[18] http://specs.wacapps.net/
<schuki> bryan ^
dom: one of the important thing in this area is discovery
... i am hopinh the group can help
<schuki> ?
<JonathanJ> It can also figure out how to work open web app
store and manifest -
[19]http://www.w3.org/wiki/System_Applications_WG:_Manifest
[19] http://www.w3.org/wiki/System_Applications_WG:_Manifest
web standards roadmap
dom: this document looks at the various standards that w3c
develops
... for each specs the doc identifies the relevant feature /
spec
<schuki> .. how stable it is, gives a link to the editors
draft, which mobile browsers are implementing the feature
<asahiro> join #webmob
... i have also linked to the relevant w3c courses
dom: the purpose of the document is to show you what is
currently available and what is coming
... and I have tried to take a feature based approach rather
than a spec approach
... as devs want to know about features
dom: the document is divided into categories of features
... i want to talk about how i have been building it, and how i
want to change it
... and make it easier to reuse the data
... inparticular i am thinking about this dashboard idea
dom: i have been maintaining for the last 2 years
[20]http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mo
bile
[20]
http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile
dom: this wiki page has the same content with less of the
graphical aspect
... there has been few contributions
... i have extracted the data and uploaded to github
... 1 json file per each feature
<schuki>
[21]https://github.com/w3c-webmob/mobile-web-app-standards
[21] https://github.com/w3c-webmob/mobile-web-app-standards
dom: 3 different groups want to build this document
... so I have created this repo
dom: do people want to continue working on this?
<bryan> +1 to this approach - a JSON-based "state of the web"
database with different presentation formats is a great idea
dom: I could use help in maintaining the data
<schuki> +1 from me too
dom: i am taking a lot of data from 'can i use'
[22]https://github.com/dontcallmedom/canmymobilebrowser/blob/ma
ster/local-data.json
[22]
https://github.com/dontcallmedom/canmymobilebrowser/blob/master/local-data.json
[23]https://github.com/dontcallmedom/w3c-editors-draft-tracker
[23] https://github.com/dontcallmedom/w3c-editors-draft-tracker
dom: I can see people are in support of the json approach
... i will continue with this
dom: I would love help on how to design it and make it more
readable
manu2: ideally this is automated, so what are you looking at to
gather this info?
dom: it's semi automated
... stability is manual
... some things need people to ask standards setters
... there could be some work on making the automation better
ddavis: how easy would it be to provide this to other groups?
dom: hopefully with moving it to a wiki that could help
... i would like it if people added to the json files and
pulled those in automatically
bryan: there's a lot of info here which is great
bryan: web platform docs, they have some stuff about mobile,
it's more educated focused,
... the majority of the info from your doc will be valuable, so
we could consider pulling it in
dom: the document could be hard to read, but by extracting the
data we can allow them to use it
bryan: the json approach is great
<ddavis> +1
dom: right now the implementation doesn't go too much into the
data
<JonathanJ> +1
Payments
<scribe> ScribeNick: dom
dsr: W3C looked at payments early on
... esp. on micropayments
... but didn't quite work out
... lots of innovation in this space
... but it's a burden for developers to get in relation with
all the payment providers
... also hard on users to have freedom in their payment systems
... We have an upcoming workshop in March 2014 in Paris
... the call for participation will be sent in a few weeks,
probably early December
... we want to create a level playing field
... interested parties come from a variety of background
... mobile network operators, credit card systems (with lots of
variation on associated costs)
... also plenty of innovation from start up
<manu2> manu: In general, the purpose of the Web Payments work
at W3C is to integrate payments into the core architecture of
the Web.
<manu2> manu: The work touches on identity, security, mobile,
banking, and financial industry in general. There is a lot of
coordination that will need to be done if we are going to be
successful.
<manu2> manu: Here are a couple of useful links for learning a
bit more about Web Payments
<manu2> manu: We had a breakout session on Wednesday that
provided a quick introduction to the space:
[24]http://www.w3.org/wiki/TPAC2013/session-web-payments
[24] http://www.w3.org/wiki/TPAC2013/session-web-payments
<manu2> manu: The minutes from the breakout session are here:
[25]http://lists.w3.org/Archives/Public/public-webpayments/2013
Nov/0035.html
[25]
http://lists.w3.org/Archives/Public/public-webpayments/2013Nov/0035.html
<manu2> manu: We are planning a W3C Web Payments Workshop
during the last week of March 2014 in Paris, we'll notify this
group when we put out the Call for Position Papers
<manu2> manu: If you want a technical introduction to the
space, you can go here: [26]https://payswarm.com/intro
[26] https://payswarm.com/intro
<manu2> manu: If you want to join the Web Payments CG,
instructions on how to do so are here:
[27]https://payswarm.com/join
[27] https://payswarm.com/join
<manu2> manu: Things that WebMob can help with: Coordination
and raising technology issues across various groups.
<manu2> manu: SysApps - Secure Element API is vital for
high-value financial transactions. How does it work with NFC
and Web Payments stack?
<manu2> manu: WebCrypto - Web Crypto API is important for doing
client-side digital signatures for purchasing. How do you
coordinate a Secure Element w/ the Web Crypto API to perform a
digital signature on a purchase request or purchase
authorization?
<manu2> manu: NFC - NFC API is important for both online and
offline purchases, does it integrate cleanly with Secure
Element, Web Crypto, and Web Payments?
<manu2> manu: geolocation - There are use cases where you would
want to use geolocation to determine an indoor location when
performing a purchase, such as access to a particular portion
of a building (like a museum) based on payment. Authorization
of purchases is also important (is your mobile phone in the
same vicinity as the physical purchase you're performing?)
<manu2> manu: Offline - How do you perform an offline purchase
using SysApps, WebCrypto and Web Payments. Is there a clear
integration story for all of the applications?
dsr: we can hear from Manu on the Web Payments CG
<manu2> manu: Web Payments - Making sure that the mobile
payment use cases are defined clearly up front. Ensure that any
sort of native mobile payment story is also possible via Web
Payments on mobile. Suggest new business models that are
possible w/ Web Payments that are not possible via mobile.
Create a clear Mobile Web App Store payment story.
<manu2> manu: In general, make sure there are clear technology
integration stories for the mobile use cases and be very
aggressive at making sure the Working Groups are coordinated to
ensure the realization of those use cases.
dsr: levelling the playing field can mean moving beyond the
device barrier for virtual wallets
... also dealing with offline payments
... person to person payments
... what are the red lines for the different players?
manu: players include governments, operators, banks, credit
card companies, online payment companies (e.g. paypal)
... none of them want to get disrupted
... we want to advance the state of the art
... what can this group do to help?
... lots of coordination needed
... coordination happens at the technology level, not around
user stories
... sysapps, webapps, nfc, etc all develop relevant pieces
... but nobody has looked at building a consistent story
... e.g. sysapps has a proposed secured element API that would
be critical to high value transactions
... the webcrypto API defines crypto that would be needed to
sign these transactions
... likewise, NFC is important to online/offline payments
... but this needs integration with secure/payments
<dsr> Also work on Bluetooth that is chartered for the SysApps,
and its role for in store payments
manu: Geo is starting to look at indoor location, which can be
used to facilitate short range payments
... Offline is a huge use case for payments — you won't be
connected at all time
... you want to run transactions even when not connected
... It's very important that WebMob helps coordinate this
beyond the technical work
... build the big picture story
Bryan: it's a key part of the User Experience with a number of
technologies under development
... it's a great opportunity to take a look at this and with a
number of other W3C technologies (WebRTC, Speech API), there
are a number of technologies that integrate beyond the browser
and affect the user experience, opens up choices in terms of
providers
... really excited to see this coming up
... right now, we have an over the top approach where we expose
this through network apis
... this is widely used by content providers; I'm not seeing
this changing
... but integrating that in the browser with discoverability is
a great area to concern
dka: very excited about the workshop too
... I just wonder if it makes sense to think of as another
web-native gap
... and thus look there again at the status of the various
relevant specs
... there are other scenarios where credit card readers are
integrated in the phone, but for which you need an app
... clearly we're dealing with a multiplicity of scenarios and
technologies
... we should try to grasp that diversity
dsr: the sysapps work on secure element is probably relevant
<dsr> The secure element API is intended to allow trusted apps
access to secure elements via a variety of means, including for
example, SIM, microSD, contactless Cards, and so forth.
dom: two level of possible integration: hardware API, vs more
high level à la Web Intents
... would be useful to add a section on payments to the roadmap
doc
Ruinan: can you clarify what you see behind Web Payments? how
does this different from what e.g. paypal already enables
dsr: the idea is to level the playing field with more
integration of payment systems within the Web, esp. the browser
... this raises also important questions on identity, hardware
integration
... we can't work on all of them, but we should identify which
can be worked on
<Zakim> manu, you wanted to ask WebMob to put forward some use
cases that we don't consider in the Web Payments Use Cases
document: [28]https://payswarm.com/specs/source/use-cases/
[28] https://payswarm.com/specs/source/use-cases/
manu: the core idea is that there is no core open standards for
the Web
... sending an email around the world is easy today
... we should make payments on the Web as easy as that
<bryan> Payments is a particularly important area for mobile
user experiences, particularly re usability, payment method
options, and payment provider choice. There are a lot of
players with an interest here, and W3C should help ensure that
as payments develop on the web, the platform remains open and
level to all players and technologies that may help drive its
development. We currently support payments via RESTful network
APIs (N-API), which an over-the-top approac[CUT]
manu: This is also a much bigger problem: we want to make it
easy, but also available to a much broader set of users
... which currently have no link to a payment/finance situation
<bryan> (continuing) also are active in NFC-based payments
(with the launch of ISIS in the U.S.). Augmenting these with a
browser-native payment API framework which can integrate a
variety of technologies and providers, we should be able to
provide a robust set of options for developers and users.
manu: if we can bring this to them via mobile and Web, we can
have a significant impact
<dsr> Improving the user experience, reducing the burden on
developers and providing a level playing field for payment
solution providers. What are the missing standards and where
can we find a consensus for further work.
manu: getting WebMob to build use cases and contribute
mobile-use cases to our document would be extremely useful
<bryan> +1 to creating use cases
<manu2> [29]https://payswarm.com/specs/source/use-cases/
[29] https://payswarm.com/specs/source/use-cases/
schuki: we'll work on getting volunteers with marcos
DKA: I'm interested to help
... I'll try to get more resources from Telefonica
... we want to bring up our use cases based on our experience
on mobile payments
<scribe> ACTION: Schuki to hunt for volunteers on payments
[recorded in
[30]http://www.w3.org/2013/11/15-webmob-minutes.html#action01]
<trackbot> Created ACTION-91 - Hunt for volunteers on payments
[on Natasha Rooney - due 2013-11-22].
<schuki> action natasha (to reassign) use cases for payments
(dka said TEF could help)
<trackbot> Created ACTION-92 - (to reassign) use cases for
payments (dka said tef could help) [on Natasha Rooney - due
2013-11-22].
permissions on the web
dom: the web started with a sandbox approach
... now we are moving more to a consent approach
<JonathanJ> [31]http://www.w3.org/2012/Talks/dhm-tag/
[31] http://www.w3.org/2012/Talks/dhm-tag/
dom: this area sometimes comes with a curse of affecting what
apis we can bring to the web
[32]http://www.w3.org/2012/Talks/dhm-tag/#%284%29
[32] http://www.w3.org/2012/Talks/dhm-tag/#%284%29
dom: risks come in the form of privacy, or with security
... privacy: data leakage, fingerprinting (relating what
cookies make possible but without relinquishing the control of
the user, so you should be able to tell a site to remove data
attributable to you - fingerprinting is this association with
you)
... and context leakage (if i can determine you have a highend
web cam plugged in your computer then i can assume you like
video and i can charge you more for video)
dom: UI mitigation - now seeing many prompts when sites want to
use functionality, integrate the flow (showing your intent
through UI), state indicator (e.g. your camera is on because
you can see a green light by the camera and it is on),
... web intents (mediation between apis on native and web - but
this is not bein worked on anymore),
dom: how do you keep prompt etc meaningful to the user?
... many groups considering all these issues and what they
should do
dom: I don't want pages / sites / apps I don't know to hurt me
... need to deal with dependancies among permissions
... there is also the issues with how many prompts we see on
the screen?
dom: Sys Apps have been looking into this
... trying to figure out what is the permissions model
dom: many people have suggested we adopt the model of native
... having permissions managed by network provider
... it's harder to manage this space atm
dom: so I have asked the tag to help
... i hope we can spend some resources on working on this
<Zakim> PhilA, you wanted to talk about fingerprinting/PDM
PhilA: the problem space here is establishing a connection
between service provider and the user
... any kind of comm needs to be 2 way
... the incentive for the user to know about this stuff is to
know why they are being tracked / monitored / etc
... what is the incentive of the servive provider?
... could charge more money by watching whether a person will
continue to look at a item to buy and charge more if they do
PhilA: so we have to get incentives on both sides, and this can
cvause issues
<bryan> What is privacy sensitive should be a choice of the
user, with APIs following those choices to determine how much
information is acceptable to share with apps, for what
purposes, for how long, etc. We did a bunch of good work on
this in WAC and can bring that back to the table as a policy
proposal, updated for JSON representation.
<bryan> Having a link in web pages to a document (e.g.
well-known resource) defining the privacy-affecting
considerations related to apps would be a first step in
educating and giving the user effective choice tools.
bryan: we did some research and found prompting doesn't work,
just way be our only hope!
... i think we should revisit this subject
... in wac te platform wasn't ready
... in sys apps it is much more ready
... we should encourage developers and let the user make
choiced in effective UI
... browser vendord are struggling with implementation
... we should focus on what is acceptable, not spend too much
time defining or figuring out
bryan: what about the unknown knowns!?
bryan: we're evolving with rich apis. Is it time to get the
devs involved
<schuki> +1 for ponies
dom: i had suggested to the tag to help with the web app
permissions problem
... fingerprinting etc
... data minimisation would be one of these topics too
... I have a distinction between prompting all the time or just
once for the app lifetime
... i think we ned to consider this, because if we don't we
will hit a wall for what we can do
<dka> +1 on continuing the work
schuki: we're looking for interest and volunteers as always :)
<manu2> +1 continue with permissions (would love to help, but
overcomitted)
<JonathanJ> +1
<scribe> ACTION: Dom to bring back up permissions on the TAG
agenda [recorded in
[33]http://www.w3.org/2013/11/15-webmob-minutes.html#action02]
<trackbot> Created ACTION-93 - Bring back up permissions on the
tag agenda [on Dominique Hazaël-Massieux - due 2013-11-22].
<bryan> s/{????]/the fact that the policy and user-engagement
approach failed in DAP had more to do with the unreadiness of
browsers to support rich APIs at the time, and the related lack
of need for a policy expression; that was OK, we can't force
implementers, but times have changed and the web platform has
moved on, e.g. with sysapps and web-based OSs. We should
restart the discussion with no preconceptions./
<schuki> action natasha (to reassign) continue permissions
work, decide on task force to manage - get task force to decide
on next step
<trackbot> Created ACTION-94 - (to reassign) continue
permissions work, decide on task force to manage - get task
force to decide on next step [on Natasha Rooney - due
2013-11-22].
WebDriver
<scribe> ScribeNick: dom
schuki: David Burnes from Mozilla here to present WebDriver
David: I'm the coeditor of the Web Driver spec
... it lets you automate browser interaction
... you tell the browser what to do via a user script
... we're not bound by the javascript sandbox, in an elevated
privilege context
... I'll show it in action to illustrate
... [showing a python-based Web driver example
... ]
... [showing how you can get a page loaded in a Web-driver
controlled browser]
... Once the page has loaded, I can get access to the DOM, find
elements (via CSS selector, id, name)
... also has xpath support to enable back- and forward lookup
... [showing how to access a link and click on it]
schuki: can you measure the time it takes?
david: you could, but without the true value since you're
outside of the browser
... you can tie to the events sent from the browser
... you can really simple things like clicking and typing
... using a "do what I mean" approach
... we have a more advanced API with more detailed interaction
... (hold shift, move the mouse by x and y, click, ...)
... that's the "do as I say" approach
... it's not always a one-to-one mapping, but we try to get as
close to it
... This is in the Web browser
... we have started to look at mobile too
... I've been involved in applying this to Firefox OS
... [demonstrating the Firefox simulator running tests
automatically via Web driver]
... There is an open source version of the Firefox WebDriver
implementation
... currently showing mozilla's own implementation
... we have really nice FirefoxOS interactions
... access to both the chrome part of the browser as well as
the content layer
... you can detect e.g. vibration
dom: is that part of the WebDriver API or an extension?
David: currently an extension
... level 1 is about driving content
... level 2 will have what's needed for mobile
... including links to hardware APIs
... this level 2 is particularly useful given the 3 open
sources projects that are looking at this space
... Apium, SelenDroid, iOSDriver
... [showing Web driver typing text as a user would]
... Testing is the major use case (80%); some for automation
schuki: we have debugging and diagnostic on our agenda for
later today
... how would this apply to other mobile Web Apps?
david: we've tried to keep the API as simple as possible
... "executeScript" is the basic action that enables all the
rest
... e.g. geolocation is implemented that way
... this could be used likewise for other systems
<Zakim> dom, you wanted to ask about permissions management
dom: how can this be used for interacting with permission
dialogs?
david: we can set the permissions in the profile
... in Mozilla
... in our architecture, we can also drive the browser chrome
... via XUL
... we might need to look at a broader permission management
questions
... but no interoperability on this in sight at this point
manu: WebDriver incredibly important to our continuous
integration in my company
... we've had to do a lot of integration to make repeatable
testing
... which I think has been a barrier for Web developers to
adopt that kind of workflow
... is there any plan to facilitate this?
david: interop in this space is really hard
... the biggest user base for Web driver is for people that are
not technical
... at the other end of the spectrum, some people dedicate a
lot of resources to Web driver automatic testing
... finding the right balance between these two extremes is
challenging
... from a W3C perspective, we only care about the browser side
of things
... getting interop at the lower layer of continuous
integration seems like just too big a goal
<Zakim> manu, you wanted to ask about test frameworks.
schuki: thanks david! this will be useful input in our
discussions on debugging and testing
Security
dom: as part of the closing the gap analysis the web is seen as
being a less secure platform than nativw
<schuki> s/nativm/native
... in native you have specific storage space
... the question is what should w3c do?
... it is difficult to disentangle what is perception and what
is reality
... I recommend we work with security group to assess what the
risks are and hiw we can reduce these
[34]http://www.w3.org/Security/wiki/IG/Mobile_Security_analysis
[34] http://www.w3.org/Security/wiki/IG/Mobile_Security_analysis
dom: a reoccuring topic is offline storage
... most mobile platforms have compartmentalisation
... a browser that hosts several apps cannot use
compartmentalisation
... there is the same origin method of compartmentalisation
... how do we ensure the browser gives the amount of security
necessary to run web apps?
dom: in the context of enterprise software (and other similar
cases) is the way to manage keys and certificates
<schuki> the web crypto working group has started looking into
this
... but i think we should start looking at which topics we
should address in this field
... I think the topics are stream encryption
... but we should check this with the security group
dom: another popular topic is because javascript is
interpretted by the browser then there are a number of secuirty
risks around cross site scripting
... web app source code is always open - you can see it
... there are tehcniques around that
dom: use cases might be a good topic
... i would love some volunteers to help
<schuki> action natasha (to reassign) build secuirty task force
then task with finding use cases, requirements, and working
with sec group
<trackbot> Created ACTION-95 - (to reassign) build secuirty
task force then task with finding use cases, requirements, and
working with sec group [on Natasha Rooney - due 2013-11-22].
bryan: do you think it would be a good idea to work with (e.g.)
testing programme to find if we are working with the guidelines
bryan: if we did find and link to some test suites would we be
fine to publish them?
dom: probably ok, does this group think we should produce some
guidance to developers
... we still have room to have impact me in this space
bryan: maybe we can work with gsma, David Rogers, maybe give
some help here
fan: we can help with use cases here
<fan> obfuscation use cases are what irdeto would like to
provide
dom: maybe a good idea to include this in the dashboard, but
yes we need to decide the exact next steps
Developer tools / debugging gap
schuki: there are some tools out there that can help with
debugging/developing on devices
... WebDriver provides clearly some useful stuff here
dom: diagnostic api proposal
... this is being discussed in w3c
... we may want to look into this
<schuki> action Natasha (to reassign) recruit dev tools /
debugging experts
<trackbot> Created ACTION-96 - (to reassign) recruit dev tools
/ debugging experts [on Natasha Rooney - due 2013-11-22].
<bryan> For some of these purposes, esp resource efficiency, we
can reference the free AT&T Application Resource Optimizer
(ARO) tool at
[35]http://developer.att.com/developer/forward.jsp?passedItemId
=9700312
[35]
http://developer.att.com/developer/forward.jsp?passedItemId=9700312
<schuki> action Natasha (to reassign) document or add to wiki a
selection of dev tools, assess and list what we feel is missing
for mobile web app developers
<trackbot> Created ACTION-97 - (to reassign) document or add to
wiki a selection of dev tools, assess and list what we feel is
missing for mobile web app developers [on Natasha Rooney - due
2013-11-22].
bryan: there are tools available
<Zakim> bryan, you wanted to say that here again we need to
reach out to actual users (devs) on what they need and percieve
as the tooling gaps
schuki: individuals in this group probably aren't necessarily
very expert in this field
... so it would be useful to see that we bring people with that
expertise in the group from our various companies
... I've take an action item toward that
... we should discuss how to get to a better understanding if
the current state
... with input from social media and the list
... I'm particularly interested in on-device debugging
<schuki>
[36]http://www.w3.org/wiki/Mobile/#New_and_Popular_Pages
[36] http://www.w3.org/wiki/Mobile/#New_and_Popular_Pages
[37]http://www.w3.org/wiki/Mobile/Dev_Tools
[37] http://www.w3.org/wiki/Mobile/Dev_Tools
<bryan> I do believe we've had real progress in web platform
support for developers in the last few years, web performance,
web driver, etc - much of what's needed may be an educational
outreach e.g. thru webplatform; if we find that there are
further gaps in the actual platform (instead of just tools that
the market provides), that would be the real value this group
could add.
[38]https://docs.google.com/document/d/1Yw_qNMCnGsWQRsdcrifzh_k
zFey-ThQ3yp-DmxuJxvg/edit?pli=1
[38]
https://docs.google.com/document/d/1Yw_qNMCnGsWQRsdcrifzh_kzFey-ThQ3yp-DmxuJxvg/edit?pli=1
dom: a useful next step might be to look at what has happened
if anything to this diagnostics API proposal?
<schuki> action natasha (to reassign) pull in diagnostics api
into the docs
<trackbot> Created ACTION-98 - (to reassign) pull in
diagnostics api into the docs [on Natasha Rooney - due
2013-11-22].
Summary
schuki: summarizing our meeting
... we're an IG, not creating standards
... we'll collaborate with other groups to achieve our goals of
promoting the Web as a platform to mobile dev
... to be successful, we need to keep our wiki up to date and
well organized
... we've discussed a lot of documentation
... out of coremob and dom's work
... some of it automated, some manual
... we're looking at moving some of it to dashboards through a
more data-driven approach
... we'll pull in documents into that approach
... and look at how use cases and requirements fit in that
vision
... Marcos raised issues on the coremob report in github
... I'll send a reminder on this to the list
... We talked about the offline situation, with ServiceWorker
to the rescue
... it sounds like something we'll come out soon
... in Chromium, and I hope we can work together on demos and
tests
... we'll keep track of that technology in the dashboard
... We talked about scrolling (in the context of new trends
such "infinite scrolling")
... the question was raised whether garbage collection is
something on which developers should have influence
... momentum scrolling is another related topic that is
important to touch-screen devices
... Tobie presented briefly the testing effort
... this group can benefit a lot from this
... they are still looking for funds
... it would be great if your company can be interested in
sponsoring on it
... if this continues and gets set up, we should be able to
integrate the data that comes out of it in our dashboard
... Marcos and Ernesto have been working on homescreen
bookmarkign
... right now somewhat iOS heavy, will push Marcos to bring
perspectives from other platforms
... Bryan presented the Push API; the PAG that was raised on
this spec has been resolved
... clearly needed to close the gap
DKA: Safari on Mavericks has a similar but proprietary API
... we're looking at a possible polyfills to fallback between
one API and the other
... we'd be happy to report back on that if and when we do it
<scribe> ACTION: DKA to report back on push API polyfill
[recorded in
[39]http://www.w3.org/2013/11/15-webmob-minutes.html#action03]
<trackbot> Created ACTION-99 - Report back on push api polyfill
[on Daniel Appelquist - due 2013-11-22].
schuki: we went through the API Gap identified out of the
visionmobile research
<scribe> ... completed by the analysis of PhoneGap most used
APIs
UNKNOWN_SPEAKER: incl camera and network info
... We discussed this morning on "closing the gap" which got
support for continuation
... support also to continue the app category approach
... Dom also presented the evolution of the WebAppState report
... with JSON files that Dom extracted from the existing report
... mix of manual and automation
... will continue to work on this
... Dave and Manu presented the ongoing work on payments with
the workshop in Paris in March
... lots more to it than I had realized
... this group can help with use cases and requirements
... Permissions and Security covered by Dom, with the
differences with Native
... Dom will bring it to the TAG
... further analysis is needed, possibly based on feedback from
the TAG
... We need to understand how the sandbox model of the Web can
apply to the requirements of mobile
... We need to make sure to collaborate effectively with the
Web Security IG
... Finally, we had a light discussion on developer tools and
debugging
... we had a good demonstration of WebDriver applied to
FirefoxOs
... we should try to collect links to dev tools, incl via
social networking
... and get more involvement from dev tools experts in the
group
... The next steps will include building task forces
... where people that are not here today will be needed
... I'll prepare this list of task forces and will ask people
to sign up to these
... if you have a particular affinity to a topic, please
consider signing up
<schuki> action Natasha (to reassign) take top 100 / 200 apps
and find the gap - this will show the gap in games
<trackbot> Created ACTION-100 - (to reassign) take top 100 /
200 apps and find the gap - this will show the gap in games [on
Natasha Rooney - due 2013-11-22].
<dka> +1 to doing something about mobile-web-games - e.g. a
workshop
DKA: the intersection of developer tools, outreach and feedback
and games shows a possible interest in organizing one or a
series of event on the topic
... maybe not a formal workshop, a meetup of some sort
... between game developers and e.g. browser vendors in
... W3C should put some energy behind this, and I would be
happy to help with that
Bryan: we've done a considerable testing of the water in this
field
... it would be good to have focus on games
dom: I'm looking into how we can involve dev community better
schuki: I'm creating a wiki page to help us organize ourselves
... Thank you all for coming, travel safely!
... Great to have our F2F at TPAC
... I think we have a good way forward
... I want your feedback on what we may have done wrong
... feel free to email, IRC, chat with Dom if about me
... we want to steer this group into the right direction
... hoping to see through our various communication channels
Bryan: excellent job natasha, thank you!
dom: +1
[applause]
<Ruinan> +1
<kotakagi> +1
<PhilA> rrsagent generate minutes
Summary of Action Items
[NEW] ACTION: DKA to report back on push API polyfill [recorded
in
[40]http://www.w3.org/2013/11/15-webmob-minutes.html#action03]
[NEW] ACTION: Dom to bring back up permissions on the TAG
agenda [recorded in
[41]http://www.w3.org/2013/11/15-webmob-minutes.html#action02]
[NEW] ACTION: Schuki to hunt for volunteers on payments
[recorded in
[42]http://www.w3.org/2013/11/15-webmob-minutes.html#action01]
[End of minutes]
Received on Tuesday, 19 November 2013 11:01:58 UTC