[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.
>

[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]

On 27/01/2014 20:28, Luke Crouch wrote:
>
> Seems like the easiest experimental feature to build before jumping
> into the more complicated CSS feature.
>

I disagree. We must first agree on the database, that is knowing the
information that we need, which is not "feature xyz on Fx 29 supported?
Yes/No" but much more complex.


--
"Prenez soin des minutes, les heures prendront soin d'elles-mêmes."
P.D. Stanhope (4e baron de Chesterfield, 1694-1773)

[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