Re: [W3C Webmob] Profiles?

On 23 Jan 2014, at 10:38, Patrick H. Lauke <redux@splintered.co.uk> wrote:

> On 23/01/2014 03:17, SULLIVAN, BRYAN L wrote:
>> If we avoid problematic words but arrive at the same destination I am
>> happy. I am not a fan of arbitrary lists or vocabulary prohibitions,
>> and do not recommend that W3C engage in either. But reasoned focus on
>> priorities given real-world use cases, yes. Whatever you accept to
>> call that, I'm ok with it.
> 
> Just wondering about the underlying assumption though. It seems the idea is that as an app developer, I'll look at the technologies listed as supported in a "profile" to decide what my app should use. But isn't it the other way around? I build my web app with technologies that I need, and that informs what my app's required "profile" is. Then only browsers/devices that support those (through feature-detection) will be able to use it. Though admittedly, devs will also look at sites like caniuse.com to determine which technologies are considered "safe"...so perhaps it's more from this angle that we should strive to tackle it?

Generally, developers focus on supporting a number of Web browsers either because they contractually agreed to do so or because they try to achieve the most rational balance between reach and development cost. While progressive enhancement can then used to improve the experience in better browsers, this is only applicable to non-mission critical APIs. If you're building an Instagram clone and you don't have access to the device's camera, you won't go very far to build an actual revenue-generating product.

So above all, it is the deployed APIs that matter to developers, and the reach their application will have depending on what mission-critical APIs are required.

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.

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.

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.

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.

5. Monetization paths were more limited on the mobile Web than on native platforms. Likewise, distribution channels were also lacking. 

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.

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 are able to.

Sorry for the long digression.

Best,

--tobie

Received on Thursday, 23 January 2014 14:24:10 UTC