[Compat Data] What do we want to do with compatibility data?

[Jeremie Patonnier]

Hi!

As you might know we are starting a project to improve our compatibility
data. Currently, those data are available on MDN on the form of
compatibility data explaining which feature is implemented by which browser.

Those data are directly contribute into each pages, therefor as the number
of data grow, it becomes harder to maintain them and almost impossible to
reuse them across MDN consistently (those of you who are localizing content
see what I mean). So some of us came with the idea to turn those data into
something a bit more structured with the following objectives in mind:

1. Avoid misleading MDN users with inaccurate data.
2. Make sure our data are coherent and up to date all across MDN
3. Easing data contribution (contribute once, update everywhere)

This is mostly a technical project but we need your input about this. And
more precisely, we need as many answers as possible to the following
questions:

- If our compatibility data are available in a structured way, How would
you have us to display/use such compatibility information on MDN?
- When contributing such compatibility data, what's bother you and how
would you prefer to contribute such data?
- Beyond displaying the data on MDN, how would you access those data
(while editing MDN or on another web site), and for what purpose?

If you are interested, I draft a first data requirement page on
WikiMo<https://wiki.mozilla.org/MDN/Development/CompatibilityTables/Data_Requirements>.
Please,
review it, I'll gladly update it with your inputs :)

As usual, I gladly answer any question you could have.
Best,
--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

[Luke Crouch]

On 1/27/14 11:56 AM, Jeremie Patonnier wrote:
> - If our compatibility data are available in a structured way, How would
> you have us to display/use such compatibility information on MDN?

In a compatibility table that's immediately visible when landing on the
API's landing page.

> - When contributing such compatibility data, what's bother you and how
> would you prefer to contribute such data?

I want a single button, "Submit your browser's web compatibility data to
Mozilla."

> - Beyond displaying the data on MDN, how would you access those data
> (while editing MDN or on another web site), and for what purpose?

We should publish the compatibility data in an API format too so that
developer tools (Firefox, Firebug, Chrome, Sublime Text, vim, whatever)
can integrate it.

--
Q: Why is this email five sentences or less?
A: http://five.sentenc.es

[Jeremie Patonnier]

Hi Luke :)

Thanks for those first inputs.

2014-01-27 Luke Crouch <lcr...@mozilla.com>

> On 1/27/14 11:56 AM, Jeremie Patonnier wrote:
>
>> - If our compatibility data are available in a structured way, How
>> would you have us to display/use such compatibility information on MDN?
>
> In a compatibility table that's immediately visible when landing on the
> API's landing page.
>
>> - When contributing such compatibility data, what's bother you and
>> how would you prefer to contribute such data?
>
> I want a single button, "Submit your browser's web compatibility data to
> Mozilla."
>

Could you detail the functional workflow you have in mind here?

Let me explain. Do you think of some kind of a "magical" button that sends
data and said thanks to the user. Or do you imagine something like opening
a new page where the user have to do somethings (answering question,
waiting for some tests to run, uploading some data files, etc.) before
sending it's data?

What's behind that question is that for some APIs (such as in JS) it's very
easy to automated most of the tests. However there are cases where a human
check is required. This is for example the case with CSS if we want to
avoid false positive (I add some examples last year with Chrome
implementing some CSSOM interfaces but not rendering anything regarding
those interfaces)

I'm not interested in the technical details yet, but having an idea of the
functional workflow you have in mind will help us define the various edge
cases we will have to handle, one way or another.

> - Beyond displaying the data on MDN, how would you access those data (while
>> editing MDN or on another web site), and for what purpose?
>
> We should publish the compatibility data in an API format too so that
> developer tools (Firefox, Firebug, Chrome, Sublime Text, vim, whatever) can
> integrate it.
>

[Renoir Boulanger]

Hi all

I'm glad to see that MDN has this project in mind!

At WebPlatform Docs, we started working on a similar project.

Our plan is to automate the import of compatibility information based on features and browser vendors. Mozilla is one of them. For this we had to think about a way to represent the features regardless of the vendor [0].

At this time, we have a work-in-progress importer made with NodeJS [1] and we are currently planning to finish up the spec [0] and then implement it in the importer.

Here are a list of relevant links on the topic:

[0]: http://webplatform.github.io/browser-compat-model/
[1]: https://github.com/webplatform/mdn-compat-importer
[2]: http://lists.w3.org/Archives/Public/public-webplatform/2014Jan/0017.html
[3]: http://lists.w3.org/Archives/Public/public-webplatform-tests/2013OctDec/0000.html
[4]: http://lists.w3.org/Archives/Public/public-webplatform-tests/2013OctDec/0001.html
[5]: http://lists.w3.org/Archives/Public/public-webplatform-tests/2013OctDec/0034.html
[6]: http://lists.w3.org/Archives/Public/public-webplatform-tests/2013OctDec/0029.html

Hope we can work together,

Renoir Boulanger | Developer operations engineer
W3C | Web Platform Project

http://w3.org/people/#renoirb ✪ https://renoirboulanger.com/ ✪ @renoirb
~

[Mihai Chereji]

On 01/27/2014 08:07 PM, Luke Crouch wrote:
> On 1/27/14 11:56 AM, Jeremie Patonnier wrote:
>> - If our compatibility data are available in a structured way,
>> How would
>> you have us to display/use such compatibility information on MDN?
> In a compatibility table that's immediately visible when landing on
> the API's landing page.
>> - When contributing such compatibility data, what's bother you
>> and how
>> would you prefer to contribute such data?
> I want a single button, "Submit your browser's web compatibility data
> to Mozilla."

>> - Beyond displaying the data on MDN, how would you access those data
>> (while editing MDN or on another web site), and for what purpose?
> We should publish the compatibility data in an API format too so that
> developer tools (Firefox, Firebug, Chrome, Sublime Text, vim,
> whatever) can integrate it.
>

Hello,

Two proposals:

1. I like the idea of having a button that would automatically submit
detected features for a client. Perhaps running the
http://modernizr.com/ suite would be the best option, perhaps enhanced
with tests for other features, not in the scope for the library.

2. In my opinion, http://caniuse.com is the golden standard when it
comes to checking for availability of features across different browser
versions. Offering something like that, + an API offering data per
browser/per feature would be awesome.

Best,
--
Mihai Chereji

[Luke Crouch]

I'm thinking about JS API's more than CSS.

I would want at least one magical button so it's super-easy for anyone
to contribute to the compatibility database in 5 seconds of interaction.

Seems like the easiest experimental feature to build before jumping into
the more complicated CSS feature.

-L

[Jean-Yves Perrier]

Hi!

I quickly look at the schema. How do you plan to deal with l10n? There
are quite a few English-only fields.

--
Jean-Yves

> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc


--
Jean-Yves Perrier
Technical Writer / Mozilla Developer Network

[David Bruant]

Le 27/01/2014 18:56, Jeremie Patonnier a écrit :
> - Beyond displaying the data on MDN, how would you access those data
> (while editing MDN or on another web site), and for what purpose?

Caniuse allows to import Google Analytics stats [1], so that you know
how many (current) users of your website you're leaving out if you
choose to use a given features. I don't really have a high-traffic
website, but if I did, I'd probably hook the MDN compat data (which I
expect to be finer-grain than caniuse data) up to know when, say, 80% of
my users have WebAudio or flexbox (or any other feature) available so
that it's worth investing in the development of a feature using it. Or
when less than, say, 5% of users don't have some feature, etc.

David

[1] http://caniuse.com/#stats_import

[Luke Crouch]

+1 to the GA integration - I had forgotten about that, but it's a great

[Jesús Pérez]

Hi

I think this is an amazing project and it will be very helpful for
developers :)

- If our compatibility data are available in a structured way, How would
you have us to display/use such compatibility information on MDN?

I like how the tables are displayed in http://caniuse.com because you can
see at a glance if something is supported in the different versions (or if
there is any regression).
Maybe the table at the bottom of the page and a link/button in on the top
to access directly to the table. I prefer not to use tabs to separate
mobile and desktop but have all in the same table. Also it's a good idea
hide the old versions of the browsers with the option to expand the table.
A section of notes (or footnotes) I think is also needed to put links to
bugs or documentation for not fully implemented features.

- When contributing such compatibility data, what's bother you and how
would you prefer to contribute such data?

With an "Edit" button that transforms the cells in inputs/selects and that
allows add new rows (browser's versions) could be easy for contributors to
maintain the tables manually.
Get all the info that we can automatically from browsers is also a good
idea, but with a warning (some kind of tag, or maybe put the cell in other
color) to change or confirm the sent data.
Also, I don't know if lot of people (contributors in that case) going to
access MDN with browsers others that Firefox (desktop) or Chrome/Chromium,
so we are not going to get data from new mobile/tablet versions of the
browsers (one of the most interested things for me)

- Beyond displaying the data on MDN, how would you access those data
(while editing MDN or on another web site), and for what purpose?

An API that can be used for debugging tools would be great (and really
useful), but if people are not actually in the page, we're not going to
have less contributions to this data?
And agree GA integration is a great feature :)

Best regards

> _______________________________________________
> dev-mdn mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdn
>



--

Jesús Pérez

http://about.me/tx2z

http://jesus.perezpaz.es - http://caosmental.com -
http://revista-exegesis.com

[Luke Crouch]

I like caniuse.com display for individual API's, but I also really like
mobilehtml5.org display for overall compatibility.

Our browser visits are: Chrome: 55%; Firefox: 32%; IE: 5%; Safari: 5%;
Opera: 1%; Android: 0.5%

IMO, we can put a "campaign" around this kind of valuable data and
content to invite more and new visitors to contribute.

[David Bruant]

Le 28/01/2014 14:10, Luke Crouch a écrit :
> I like caniuse.com display for individual API's, but I also really
> like mobilehtml5.org display for overall compatibility.

Agreed. We have to be careful not to provide overall compatibility
"scores" of sort like html5test does as it's a somehow misleading
information for users.
That could be something W3C web-platform tests could do, though (to
balance the ridiculous tables of ietestcenter).

David

[Bruno Heridet]

> - If our compatibility data are available in a structured way, How would
>
> you have us to display/use such compatibility information on MDN?

caniuse.com has been mentionned several times in this thread.

I'd like to point that their data are easily available/editable as ready to consume JSON files on their github account https://github.com/Fyrd/caniuse/tree/master/features-json and even throug NPM https://github.com/Fyrd/caniuse/blob/master/package.json

As it's almost the defacto place for such information, maybe it would make sense to contribute to this project and have MDN automatically grab the data from there?

[Jeremie Patonnier]

Hi!

2014-01-29 Bruno Heridet <delap...@gmail.com>

> > - If our compatibility data are available in a structured way, How
> would
> >
> > you have us to display/use such compatibility information on MDN?
>
> caniuse.com has been mentionned several times in this thread.
>

> As it's almost the defacto place for such information, maybe it would make
> sense to contribute to this project and have MDN automatically grab the
> data from there?
>

I agree its a valuable third party data source we should consider. However,
I'm not sure their data schema fits all MDN needs (especially l10n) and as
they are flatten representation of their data base, relation between data
are not so obvious if we want to rebuild them to fit our needs. That said,
I haven't check their schema since last summer so maybe it has changed.
I'll take a look.

That said, we haven't started discussion about the technical schema and I
wish to gather as much as possible functional requirements before we start
moving to the technical part.