notes and thoughts on compatibility data tables

Yesterday, Doug and I chatted about my experience with merging data
about compatibility data across various sources from 
https://github.com/dontcallmedom/canmymobilebrowser 

Here are some of the thoughts I expressed on the challenges I can
foresee for presenting and maintaining compatibility data for
WebPlatform.

Granularity
----------
Merging automatically data from different data sources that describe
compatibility at very different granular level is going to really hard;
doing it overtime where that granularity will be evolving differently in
the various data sources will be even more challenging.

Your experience might differ from mine, but I would expect merging these
data sets over time will prove extremely hard to automate; I think a
semi-automatic approach that would let users easily review new
information coming from one of the data sets would be more likely to
work (but would also require a higher upfront investment, as well as
more manual work over time).

Given the long term goal of using W3C test results as source for the
compatibility data, I think it would be useful to define early on a
framework to link a "feature" description (e.g. "basic support of
border-radius") in precise technical terms (roughly, the English
equivalent of what test cases would determine). That description would
also be useful to users of WPD to understand what is actually meant by
the title of the feature.

Data exposure
-------------
A key factor to ensure greater quality of the data will be to make very
easy for other projects (e.g. IDEs, external developers articles, press
articles on Web technologies, etc) to import and display the data
available in WPD compatibility tables.

The more people are exposed to the data, the more likely they are to
report bugs, and the more likely the various stakeholders (e.g. browser
vendors) will want the data to accurately reflect their products.

So working early on on exports of the data sets, or APIs to interact
with the data would probably have good return on investment
(data.webplatform.org maybe?). The investment can be progressive (e.g.
from simply publishing JSON files up to providing ways to easily insert
a nice-looking widget representing compatibility data in external web
sites). [FWIW, I think the point about data exposure applies more
generally to pretty much all of the structured content of WPD, but
compatibility tables are probably a good place to start]

As we discussed briefly as well, read-only access to the data is great,
but an API to update the data can also be beneficial: from browsers
vendors publishing their features as they release a new version of their
browser, to automated tests systems reporting results of compatibility
testing.

Display
-------
One thought that occurred to me yesterday after our discussion regarding
the good-looking graphical summary of compatibility table you showed to
me: beyond the bug I hit in displaying the expanded list of mobile
browsers, putting mobile browsers in this less visible spot might be
downplaying their importance (esp. given current trends in Web browser
usage).

More to the point (and as an example), Safari mobile already represents
more traffic than Opera (mobile and desktop version combined), and Opera
mobile represents more traffic than Opera desktop.

I understand that you can't make the default view too crowded (to the
risk of making the summary unreadable), but I wonder if showing mobile
support for each of the desktop version via a checkmark in a smaller
mobile icon associated to each of the (desktop) browser logo wouldn't
work as well.

Dom

Received on Friday, 5 April 2013 16:49:41 UTC