Re: [W3C Webmob] Profiles?

(Bryan, and people who think a profile could be helpful here, question for you below... wondering if we can take a different approach towards understanding what a profile sets out to solve...)

On Thursday, January 23, 2014 at 2:23 PM, Tobie Langel wrote:

> The Coremob work stemmed from the following observations:
> 
> 1. Despite a lot of work going on in very complex specs (such as WebRTC/getUSerMedia or WebGL) a lot of key use-cases weren't properly addressed by those and/or could be handled by much simpler specs. For example, one of the key features apps required was access to the camera, and this was much more easily provided for by the declarative media capture attribute than by getUserMedia (which to this day still doesn't have an appropriate solution for high def photo capture). Similarly, the focus on WebGL completely disregarded the fact that most successful app on the mobile market were 2D or isomorphic games, and that thus, a faster canvas element was a much more effective solution than pushing for WebGL implementations.

True that. I do wonder if we should revisit some of those or if it's too late. 
 
> 2. The resource constrains on mobile implied that good enough browser performance would require coordination from chip manufacturers, OEM, browser vendors, developers, and to some degree, operators.

I think it still does.  
> 3. Where technologies were properly deployed, implementation and interoperability issues plagued application development; the infamous death by a thousand paper cut issue. This stressed the importance of testing.


Could not agree more.  I kinda like the approach that the W3C XHR guys have been taking:

http://jungkees.github.io/XMLHttpRequest-test/

Implementation report with direct links to bug tracker issues in all the major browsers (that have an open bug tracker). I was hoping when we started this group that we would do something similar. 
 
> 4. There lacked a holistic approach to the Web platform. APIs developed in isolation by different WG were highly inconsistent and increased the cognitive load of developers. This is now hopefully being addressed by the new TAG.


>From my experience on the TAG, I don't think the TAG has the people-power to do this. It would mean somehow getting all editors/wgs in the same room and educating them - or not allowing publication of unless it goes through the TAG for a nod... I don't think either solution scales. We did try some of this by sending all new APIs through public-script-coord, but that's more of idiomatic checks rather than platform consistency (and milage varied significantly depending on if the people on public-script-coord found the API interesting enough to look at and comment on).  

Consistency, and hell some leadership on priorities for the Web platform, is certainly something that is needed ... but it's a hard problem to address because it's a matter of principles and having a shared vision for the platform.  Also, API design is hard. 

> 5. Monetization paths were more limited on the mobile Web than on native platforms. Likewise, distribution channels were also lacking.
Somewhat agree. This assumes a traditional apps store distribution/business model - we've been doing commerce on the Web and paying for services for like 15 years. And search engines are pretty good at finding what we need. 

Being able to install web apps along side native apps seems to be a missing component. I do conceded that people wanting to install apps might go to Apple/Googles respective stores first unless we add a means to make it easy to one click install a web page from a browser. That's been the point of:

http://w3c-webmob.github.io/installable-webapps/

And: 
http://manifest.sysapps.org/

> The aim of the original Coremob report was to identify a number of pressing issues and help the industry focus around them in order to enable developers to build the kind of applications which were highly successful on native platforms.
> 
> This is still relevant today.
> 
> However, a profile-based approach really isn't the best way to drive this effort.

I wonder if we can go back to the basics: what problem is a "profile" actually trying to solve? If we can get that, we can look at alternatives that are more palatable to those of us with the violent allergic reaction to the word "profile" :) 

Bryan: can you help use understand your needs a bit more by describing the above? Please try to just describe the problem and not how a profile addresses the problem.  
 
> Instead, the approach that this group has taken so far--focused, highly-researched work on hot topics combined with a bird's eye view of the platform derived from Dom's quarterly report--is a great way to go about this. I would really like to see more resources invested in Dom's work in order to turn this quarterly report into a constantly up to date document that would constantly give the OWP's pulse in a way neither /TR nor caniuse.com (http://caniuse.com) are able to.
> 
> Sorry for the long digression. 
No need to apologize, this is a great input :)

Received on Friday, 24 January 2014 12:04:41 UTC