[Compat Data] Alternatives data use cases

[Jeremie Patonnier]

Hi folks!

Among the first feedback we get about "what do we want to do with our
compatibility data", there is some traction to be able to improve various
aspect of our compatibility tables. Possibly with something closer than
what caniuse.com is doing.

Beyond compatibility tables, I wish to have your opinion on other possible
use cases for such data:
Compatibility Badges

There are two ideas :

1. Provide a very quick visual hint on top of a page to tell which
browser currently support the features describe on the page (it can be a
logo or anything else).
2. Allow to create in-line compatibility badges to provides quick
information within our content. Such badges could be able to update
themselves if the data evolve. We are currently doing this by hand for
Firefox, but it could be automated for all browsers.

Compatibility Filters

We could create pages listing features with the ability to show/hide some
of the features based on a browser (and possibly its version) selected by
the user. We would also possibly wish to build pages listing the features
of a specific browser and allow the user to see the features of the version
of it's choice (this would be especially handy for Firefox OS).
Compatibility Search

It would be nice to allow user to define one or more browsers (and their
versions) to perform search on MDN and provide results only relevant for
the given browsers.


Of course if you have some other crazy ideas, I would love to here them :)
Best,
--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

[Jean-Yves Perrier]

On 31/01/2014 13:31, Jeremie Patonnier wrote:
> Compatibility Filters
>
Compatibility filters for pages is definitively something we want: the
set of proprietary interfaces, methods or properties is not the same in
FxOS 1.0/1.1/1.2/...

This is also important for XPCOM and other Mozilla-specific projects. We
would like to display a "history" of the page for different version of
Fx. Or the common areas for a set a version of Fx (like: the API common
to the ESR, up to the latest Nightly).

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

[Jean-Yves Perrier]

One important point to keep in mind is that we don't always need the
same level of details.

In big summary tables, we'll likely need to know if a given feature is
supported or not (like is the CSS property 'font-variant' supported).
In the page itself, we need to go in more details: not only if
font-variant is supported, but what values are supported (CSS2.1 values,
or the newly added features in CSS Fonts L3).

The ability to generate this two kinds of data is important (and may be
tricky to achieve).

Badges at different levels must be able to specify what kind of details
they need.

[Luke Crouch]

Sorry to be pedantic, but can we call them compatibility "markers"?
Badges is a very loaded word around Mozilla, and we're going to start
doing MDN badges for visitors and contributors very soon.

FWIW, the show/hide content by browser compatibility sounds like a
pretty messy implementation from a technical stand-point. I would want
to run experiments and see some baselines on how much demand, use, and
impact that feature would have before implementing the full thing. :/

-L

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

[Jean-Yves Perrier]

On 31/01/2014 14:03, Luke Crouch wrote:
>
> FWIW, the show/hide content by browser compatibility sounds like a
> pretty messy implementation from a technical stand-point. I would want
> to run experiments and see some baselines on how much demand, use, and
> impact that feature would have before implementing the full thing. :/
>
> -L
>

If I recall well, Sumo does this: the article is not identical
(paragraph are added/removed), keystrokes adapted if you ask for an
article for Mac, Windows or Linux. A basic implementation likely is a
couple of lines of Javascript to swap some CSS classes on the root or
high-level container.

[Jeremie Patonnier]

Yes, right

I think it's good to consider two different use cases :

1. Building listings of features base on the level of information we
want to display
2. Let the user choose which browser/version he want to watch.

For 1 it will require to see how to handle data with a notion of "level of
details".

For 2, we need to define more concrete use cases and what it means.

Maybe it could be helpful to create some visual mock up. Would you have me
doing this?


2014-01-31 Jean-Yves Perrier <jper...@mozilla.com>:

> One important point to keep in mind is that we don't always need the same
> level of details.
>
> In big summary tables, we'll likely need to know if a given feature is
> supported or not (like is the CSS property 'font-variant' supported).
> In the page itself, we need to go in more details: not only if
> font-variant is supported, but what values are supported (CSS2.1 values, or
> the newly added features in CSS Fonts L3).
>
> The ability to generate this two kinds of data is important (and may be
> tricky to achieve).
>
> Badges at different levels must be able to specify what kind of details
> they need.
>
>

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

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

[Jean-Yves Perrier]

Yep. I do think having concrete mock-up for the different use-case will
make them easier to describe.

And doing them will likely make the gory details show up anyway.

Also, having these visual use-case may be a good starting point to have
UX involved and also to be sure that the back-end will give the needed
information.

On 31/01/2014 14:19, Jeremie Patonnier wrote:
> Yes, right
>
> I think it's good to consider two different use cases :
>
> 1. Building listings of features base on the level of information we
> want to display
> 2. Let the user choose which browser/version he want to watch.
>
> For 1 it will require to see how to handle data with a notion of "level
> of details".
>
> For 2, we need to define more concrete use cases and what it means.
>
> Maybe it could be helpful to create some visual mock up. Would you have
> me doing this?
>
>
> 2014-01-31 Jean-Yves Perrier <jper...@mozilla.com

> <mailto:jper...@mozilla.com>>:

>
> One important point to keep in mind is that we don't always need the
> same level of details.
>
> In big summary tables, we'll likely need to know if a given feature
> is supported or not (like is the CSS property 'font-variant' supported).
> In the page itself, we need to go in more details: not only if
> font-variant is supported, but what values are supported (CSS2.1
> values, or the newly added features in CSS Fonts L3).
>
> The ability to generate this two kinds of data is important (and may
> be tricky to achieve).
>
> Badges at different levels must be able to specify what kind of
> details they need.
>
>
> --
> Jean-Yves Perrier
> Technical Writer / Mozilla Developer Network
>

> _________________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org <mailto:dev...@lists.mozilla.org>
> https://lists.mozilla.org/__listinfo/dev-mdc

> <https://lists.mozilla.org/listinfo/dev-mdc>
>
>
>
>
> --
> Jeremie
> .............................

> Web : http://jeremie.patonnier.net <http://jeremie.patonnier.net/>
> Twitter : @JeremiePat <http://twitter.com/JeremiePat>

[Jeremie Patonnier]

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

> Sorry to be pedantic, but can we call them compatibility "markers"? Badges
> is a very loaded word around Mozilla, and we're going to start doing MDN
> badges for visitors and contributors very soon.
>

No problem, consider it done :)

> FWIW, the show/hide content by browser compatibility sounds like a pretty
> messy implementation from a technical stand-point. I would want to run
> experiments and see some baselines on how much demand, use, and impact that
> feature would have before implementing the full thing. :/

I fully agree, on that point. I just want to be sure there is some demand
for such feature and how to express the needs we could have around this.
The clearer we are on our features demand the easier it will be to discuss
the implementation issues.

--
Jeremie
.............................
Web : http://jeremie.patonnier.net

Twitter : @JeremiePat <http://twitter.com/JeremiePat>

[Jeremie Patonnier]

Okay, I'll do this.

I'll try to post some drafts by the end of next week.


2014-01-31 Jean-Yves Perrier <jper...@mozilla.com>:

>> --
>> Jeremie
>> .............................

>> Web : http://jeremie.patonnier.net <http://jeremie.patonnier.net/>
>> Twitter : @JeremiePat <http://twitter.com/JeremiePat>
>>
>
>
> --
> Jean-Yves Perrier
> Technical Writer / Mozilla Developer Network
>

[Luke Crouch]

Be sure to cc Holly Habstritt - I pinged her about this thread but
she'll want to be in the loop on mock-ups and wireframes for sure.

Exciting stuff. :)

[Luke Crouch]

+Ricky

SUMO adapts content for platform and Firefox version, and their (old)
code is lying dormant in ours.

Ricky,

AIUI, SUMO attaches platform/browser relevancy to the entire document -
not individual sections?

We would also have the added complexity of many many more browsers,
versions, and variants. :/

-L

On 1/31/14 8:18 AM, Jean-Yves Perrier wrote:
> If I recall well, Sumo does this: the article is not identical
> (paragraph are added/removed), keystrokes adapted if you ask for an
> article for Mac, Windows or Linux. A basic implementation likely is a
> couple of lines of Javascript to swap some CSS classes on the root or
> high-level container.

[Jean-Yves Perrier]

On 31/01/2014 14:47, Luke Crouch wrote:
>
> We would also have the added complexity of many many more browsers,
> versions, and variants. :/

We can start with a Minimum Viable Product for this.

On Mozilla-specific technology, only the Gecko version is relevant most
of the time. That wouldn't be too complex an experiment.

[Jeremie Patonnier]

Oh yes, she will :)

Even if the mock up I'm working on are not UX stuff but more a visual
representation of our needs, she'll be informed. However, they could be
used as a challenge basis for UX once our basic functional data requirement
will be set.


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

> Be sure to cc Holly Habstritt - I pinged her about this thread but she'll
> want to be in the loop on mock-ups and wireframes for sure.
>
> Exciting stuff. :)
>
>
> -L
>

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

[Jeremie Patonnier]

2014-01-31 Jean-Yves Perrier <jper...@mozilla.com>:

> On 31/01/2014 14:47, Luke Crouch wrote:
>
>>
>> We would also have the added complexity of many many more browsers,
>> versions, and variants. :/
>>
> We can start with a Minimum Viable Product for this.
>

It's possible when it come to implementation, but thinking about
scalability should be one of our key requirement.

So having inputs regarding the difficulties (or not) beyond such
scalability will help us.

[Ricky Rosario]

On 1/31/14, 9:47 AM, Luke Crouch wrote:
> Ricky,
>
> AIUI, SUMO attaches platform/browser relevancy to the entire document
> - not individual sections?

In SUMO, articles are assigned to one or more products (Firefox, Firefox
for Android, Firefox OS, Webmaker, Thunderbird, more to come). Then
within each article, you can specify content for specific versions of
the product. For Firefox desktop, you can also specify content for
specific OSes.

Here is an example (keep in mind that our articles are written in
pseudo-mediawiki syntax):

*{for winxp,linux}At the top of the Firefox window, click the {menu
Tools} menu and choose {menu Downloads}.{/for}{for win7,win8}At the
top of the Firefox window, click the {button Firefox} button and
then choose {menu Downloads}.<br><br>[[Image:firefox button -
download]]{/for}{for mac}On the menu bar, click the {menu Tools}
menu and then choose {menu Downloads}{/for}


For version, the syntax looks like:

{for fx23}This content shows up in Firefox 23 and above{/for}
{for not fx23}This content show up in Firefox 22 and below{/for}
{for fx27}This content shows up in Firefox 27 only{/for}
{for m28}This content shows up in Fennec 28 and above{/for}


Hmm, I should've just pointed to the article that explains it all:
https://support.mozilla.org/en-US/kb/how-to-use-for

Let me know if you have any questions!
Thanks.
-Ricky

[Janet Swisher]

On 1/31/14 10:15 AM, Ricky Rosario wrote:
> Here is an example (keep in mind that our articles are written in
> pseudo-mediawiki syntax):
>
> *{for winxp,linux}At the top of the Firefox window, click the {menu
> Tools} menu and choose {menu Downloads}.{/for}{for win7,win8}At the
> top of the Firefox window, click the {button Firefox} button and
> then choose {menu Downloads}.<br><br>[[Image:firefox button -
> download]]{/for}{for mac}On the menu bar, click the {menu Tools}
> menu and then choose {menu Downloads}{/for}

Note that this particular example is called out in the article as a
"bad" usage of the feature.

> Hmm, I should've just pointed to the article that explains it all:
> https://support.mozilla.org/en-US/kb/how-to-use-for
>
>

Please note the "Best practices" section at the end of that article.

From an information management standpoint, going crazy with conditions
can become a maintenance nightmare at the content level. I'm speaking
based on experience of trying to do similar things with "conditional
text" in FrameMaker, to reuse the same source document across multiple
product lines, models, versions, and output formats. At some point, it
makes more sense to either fork the document, or start using a real
component-based content management system.

SUMO only has to deal with two version series (Firefox desktop and
mobile). Y'all are suggesting supporting a version series for every
different browser, which is a much greater complexity.

--
Janet Swisher <mailto:jREMOVE...@mozilla.com>
Mozilla Developer Network <https://developer.mozilla.org>
Developer Engagement Community Organizer

[Jeremie Patonnier]

Hi!

I agree with Janet that MDN scope is so much wider than SUMO that having in
content filtering could make things amazingly hard to maintain (and I
follow Luke when he said it could make things quite hard to implement and
maintain on the technical side).

Let me detailed that filtering feature I have in mind. It can be actually
seen at three different levels:

1. At the content level as we discussed here (but maybe not such a good
idea)
2. At the page level : If the user choose a given browser (and possibly
version), we could mark a page (and/or links to that page) as "irrelevant"
if the browser is not compatible with all the features documented on the
page. This could be helpful for people looking for specific information
about a given browser. It will spare them the need to always check at the
compatibility tables or markers to ensure that what he is reading is
relevant to his needs.
3. At the compatibility data level: If a user want to see only the data
of a given browser (or set of browsers) we could avoid to display all the
other compatibility data. This sounds realistic if we move compatibility
data away from content.

Does it makes things clearer and more realistic?

I think point 1 is a bit to much efforts for a gain which is unclear. Point
2 could be a very nice nice-to-have but we need to make some UX and Tech
experiment in order to see if it's really relevant. That said, I think
point 3 could be a game changer for MDN especially when it comes to
compatibility tables (more about this on another thread regarding
compatibility tables).



2014-01-31 Janet Swisher <jswi...@mozilla.com>:

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