trackbot, prepare meeting
<trackbot> Date: 15 November 2013
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
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 (http://developer.att.com/home/community/conference/HTML5.pdf), the areas to consider include: developer communities, open source code availability, SDKs, emulators, platform/ecosystem-specific ce[CUT]
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: http://www.chromium.org/developers/using-requestautocomplete
dom: how can we make sure we are pushing away the silos
<JonathanJ> 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> 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> 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 - http://www.w3.org/wiki/System_Applications_WG:_Manifest
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
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> 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'
https://github.com/dontcallmedom/canmymobilebrowser/blob/master/local-data.json
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
<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: http://www.w3.org/wiki/TPAC2013/session-web-payments
<manu2> manu: The minutes from the breakout session are here: 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: https://payswarm.com/intro
<manu2> manu: If you want to join the Web Payments CG, instructions on how to do so are here: 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: 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> 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 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].
dom: the web started with a sandbox approach
... now we are moving more to a consent approach
<JonathanJ> 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
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 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].
<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
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
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
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 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> http://www.w3.org/wiki/Mobile/#New_and_Popular_Pages
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.
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].
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 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