W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2013

Re: Sites using webkitAudioContext only

From: Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
Date: Tue, 18 Jun 2013 13:54:40 +0000
To: "public-audio@w3.org" <public-audio@w3.org>
Message-ID: <CDE6202C.747F%olivier.thereaux@bbc.co.uk>
On 18/06/2013 04:09, "Robert O'Callahan" <robert@ocallahan.org> wrote:
>
>If we require Web developers to make major modifications to work with the
>unprefixed AudioContext, then for many of them it becomes easier to just
>tell their users to use Chrome.

This sounds fairly drastic. Our recent sample (of one, thus obviously not
statistically relevant, but interesting anyway) of developers seems to be
happy updating their code along with the development of our spec and the
introduction of new implementations.

While Mozilla may be worried that app/sites developers will tell users to
"just use Chrome" rather than fix a handful of lines of their code, I
believe developers may be equally worried about bad publicity and lost
users if they are pointed at for sticking to prefixed code and deprecated
interfaces, or simply because their old code doesn't work everywhere when
everyone else's (especially later adopters') does. I am hopeful that there
is a decent compromise somewhere.

If I can try and summarise some of the mitigating ideas which have been
introduced in this thread so far:

* Collect and maintain a list of all the significant pieces of
documentation of the API
* Update HTML5rocks and other documentation which we control directly
* Get our community to help us ask implementers and writers to update
their examples
* Communicate positively about upcoming implementations, make it exciting
for developers to update their code
* Document known demos and apps using the web audio API as a way to
contact them when needed. Also as a way to promote/thanks early adopters?
* Publicise (more) aggressively the existence of the Monkey Patch(es)

A lot of this can be done through our community champions. Let's not
underestimate the massive goodwill of people who are eager to help us
deliver a better API, faster.

I would also like to reiterate my wish to see raw data about usage of
specific interfaces in code already in the wild.

CRogers mentioned some useful data points about how much some interfaces
are being used. It would be great to know which of these can be shared and
what granularity they offer. The key will be to agree on what constitutes
"significant" adoption of this or that interface. Is one app with a
million users significant? Probably not, as there must be a way to help
the developers of the app update their code. How about a couple of
libraries used in hundreds of pages? How about a thousand independent apps
with ten thousand monthly users each?

Olivier



-----------------------------
http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------
Received on Tuesday, 18 June 2013 13:55:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:18 UTC