Fwd: Android for Mobile No Longer Supported / Compatibility data project

[Chris Mills]

Hi there,

Joe from Google approached me with the below point, I wasn’t sure of the best answer, so I thought I’d throw it out for comment.

1. What do we think of this proposal? Google are keen to ditch legacy default Android browser support information, but I thought perhaps it was worth keeping at least for now, as a sizeable number of people still use it:

http://gs.statcounter.com/#mobile+tablet+console-browser-ww-monthly-201402-201502 <http://gs.statcounter.com/#mobile+tablet+console-browser-ww-monthly-201402-201502>

2. If we do decide to get rid of the "default Android” (not really the default anymore) browser stats, what is the best way to do this? Would the new compatibility data project provide an easy way to mass remove all that data? What is the eta on that?

thanks for listening ;-)


Chris Mills
Senior tech writer || Mozilla
developer.mozilla.org <http://developer.mozilla.org/> || MDN
cmi...@mozilla.com <mailto:cmi...@mozilla.com> || @chrisdavidmills



> Begin forwarded message:
>
> From: Joe Medley <jme...@google.com>
> Date: 5 March 2015 00:50:49 GMT
> Subject: Android for Mobile No Longer Supported
> To: Chris Mills <cmi...@mozilla.com>
>
> Chris,
>
> Is there a way to automate updates of the browser compatibility table across the site? Our legacy Android browser is no longer supported, having been replaced by Chrome for Android some time ago. We're interested in removing or sunsetting these entries.
>
> Joe
> Joe Medley | Technical Writer | jme...@google.com <mailto:jme...@google.com> | 816-678-7195

[Jean-Yves Perrier]

On 05/03/2015 18:13, Chris Mills wrote:
> Hi there,
>
> Joe from Google approached me with the below point, I wasn’t sure of the best answer, so I thought I’d throw it out for comment.
>
> 1. What do we think of this proposal? Google are keen to ditch legacy default Android browser support information, but I thought perhaps it was worth keeping at least for now, as a sizeable number of people still use it:
>
> http://gs.statcounter.com/#mobile+tablet+console-browser-ww-monthly-201402-201502 <http://gs.statcounter.com/#mobile+tablet+console-browser-ww-monthly-201402-201502>

I think it is too early. 18% of mobile devices as you link. We try to
list IE Mobile with less than 2%.

If no new devices go out with the Android Browser, it will plummet in a
couple of years max: very few devices survives more than 5-6 years.

> 2. If we do decide to get rid of the "default Android” (not really the default anymore) browser stats, what is the best way to do this? Would the new compatibility data project provide an easy way to mass remove all that data? What is the eta on that?
>

Once the compat data project is done, it should be trivial: adapting the
macro and regenerating the pages. Before it, it is a nightmare.

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

[Luke Crouch]

+1 Jean-Yves and I'd also like to keep the data around. MDN is great as a
repository of the information web developers *need*, not the information
browser vendors *want* them to have. :)

-L

On Thu, Mar 5, 2015 at 1:03 PM, Jean-Yves Perrier <jype...@gmail.com>
wrote:

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

[Eric Shepherd]

Yeah, we need to keep it for now. We’ll filter it out when the time is right. For now, there are too many people still using it, and it’s just in general too soon.


Eric Shepherd
Senior Technical Writer
Mozilla Developer Network(https://developer.mozilla.org/)
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy





On Mar 5, 2015, 2:03:17 PM, Jean-Yves Perrier <jype...@gmail.com> wrote: On 05/03/2015 18:13, Chris Mills wrote: > Hi there, > > Joe from Google approached me with the below point, I wasn’t sure of the best answer, so I thought I’d throw it out for comment. > > 1. What do we think of this proposal? Google are keen to ditch legacy default Android browser support information, but I thought perhaps it was worth keeping at least for now, as a sizeable number of people still use it: > > http://gs.statcounter.com/#mobile+tablet+console-browser-ww-monthly-201402-201502 I think it is too early. 18% of mobile devices as you link. We try to list IE Mobile with less than 2%. If no new devices go out with the Android Browser, it will plummet in a couple of years max: very few devices survives more than 5-6 years. > 2. If we do decide to get rid of the "default Android” (not really the default anymore) browser stats, what is the best way to do this? Would the new compatibility data project provide an easy way to mass remove all that data? What is the eta on that? Once the compat data project is done, it should be trivial: adapting the macro and regenerating the pages. Before it, it is a nightmare. -- Jean-Yves Perrier Senior Technical Writer / Mozilla Developer Network _______________________________________________ dev-mdc mailing list dev...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-mdc MDN contributor guide: http://bit.ly/ContributorGuide Doc project Trello board: https://trello.com/b/HAhl54zz/status

[Karl Dubost]

Le 6 mars 2015 à 04:03, Jean-Yves Perrier <jype...@gmail.com> a écrit :
> I think it is too early. 18% of mobile devices as you link. We try to
> list IE Mobile with less than 2%.

Maybe a way to meet the two ends is
1. to keep the data for Android browser (at least for historical purpose)
2. to have a color/marker/date for EOL browsers (example Presto, Camino, Android)
3. to have a way to display data for only supported browsers at first sight
4. to have a switch to make old data visible on user request.


--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Chris Mills]

I think I definitely agree that we need to keep the data around.

I also like Karl’s idea about having some kind of special icon or marker for EOL browsers. Could we factor this in to the new compat project?

Chris Mills
Senior tech writer || Mozilla

developer.mozilla.org || MDN
cmi...@mozilla.com || @chrisdavidmills

[Jeremie Patonnier]

I totally support Luke's point.

It also worth mentioning that whatever Google folks want, Android Ginger
bread (2.3) and Ice Cream Sandwich (4.0), which do not ship with Chrome
Mobile by default, are still on sell. So calling them EOL is a bit abusive
for some markets.

That said, it also worth remaining that there is no such thing as an "Android
Browser <http://slides.com/html5test/the-android-browser>" and we will need
to rethink how we are displaying those data at some point. It might also be
necessary to make some difference between Chrome Mobile and the Android
WebView which are not necessarily in sync. On that point, having help from
Google people would be very helpful.

++
Jeremie

2015-03-06 0:02 GMT+01:00 Luke Crouch <lcr...@mozilla.com>:

> +1 Jean-Yves and I'd also like to keep the data around. MDN is great as a
> repository of the information web developers *need*, not the information
> browser vendors *want* them to have. :)
>
> -L
>

> On Thu, Mar 5, 2015 at 1:03 PM, Jean-Yves Perrier <jype...@gmail.com>

> wrote:
>
> > On 05/03/2015 18:13, Chris Mills wrote:
> > > Hi there,
> > >
> > > Joe from Google approached me with the below point, I wasn’t sure of
> the
> > best answer, so I thought I’d throw it out for comment.
> > >
> > > 1. What do we think of this proposal? Google are keen to ditch legacy
> > default Android browser support information, but I thought perhaps it was
> > worth keeping at least for now, as a sizeable number of people still use
> it:
> > >
> > >
> >
> http://gs.statcounter.com/#mobile+tablet+console-browser-ww-monthly-201402-201502
> > <
> >

> http://gs.statcounter.com/#mobile+tablet+console-browser-ww-monthly-201402-201502

> > >
> > I think it is too early. 18% of mobile devices as you link. We try to
> > list IE Mobile with less than 2%.
> >

> > If no new devices go out with the Android Browser, it will plummet in a
> > couple of years max: very few devices survives more than 5-6 years.
> > > 2. If we do decide to get rid of the "default Android” (not really the
> > default anymore) browser stats, what is the best way to do this? Would
> the
> > new compatibility data project provide an easy way to mass remove all
> that
> > data? What is the eta on that?
> > >
> > Once the compat data project is done, it should be trivial: adapting the
> > macro and regenerating the pages. Before it, it is a nightmare.
> >
> > --
> > Jean-Yves Perrier
> > Senior Technical Writer / Mozilla Developer Network
> >
> > _______________________________________________

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

> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
> MDN contributor guide: http://bit.ly/ContributorGuide
> Doc project Trello board: https://trello.com/b/HAhl54zz/status
>

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

[Luke Crouch]

Based on the outstanding draft of the new compat tables [1] I guess so.

McDonald's idea for Stephanie and John to tear apart:

1. Store the "EOL" as a free-form note on the Browser model [2]
2. Display the browser with an icon & icon-caret-down element to show the
notes

But IIRC we've already discussed some kind of "browser status" field before?

-L

[1] http://stephaniehobson.github.io/browsersupports/2/
[2]
https://github.com/mozilla/web-platform-compat/blob/b51bc9c273c11674f35448c362751550134c51b0/webplatformcompat/models.py#L28-L30

On Fri, Mar 6, 2015 at 1:01 AM, Chris Mills <cmi...@mozilla.com> wrote:

> I think I definitely agree that we need to keep the data around.
>
> I also like Karl’s idea about having some kind of special icon or marker
> for EOL browsers. Could we factor this in to the new compat project?
>
> Chris Mills
> Senior tech writer || Mozilla
> developer.mozilla.org || MDN
> cmi...@mozilla.com || @chrisdavidmills
>
>
>
> > On 5 Mar 2015, at 23:06, Karl Dubost <kdu...@mozilla.com> wrote:
> >
> >
> > Le 6 mars 2015 à 04:03, Jean-Yves Perrier <jype...@gmail.com> a écrit
> :

> >> I think it is too early. 18% of mobile devices as you link. We try to
> >> list IE Mobile with less than 2%.
> >

> > Maybe a way to meet the two ends is
> > 1. to keep the data for Android browser (at least for historical purpose)
> > 2. to have a color/marker/date for EOL browsers (example Presto, Camino,
> Android)
> > 3. to have a way to display data for only supported browsers at first
> sight
> > 4. to have a switch to make old data visible on user request.
> >
> >
> > --
> > Karl Dubost, Mozilla
> > http://www.la-grange.net/karl/moz
> >

[John Whitlock]

Browsers have free-form notes [1], which can include vendor's regrets about
their past projects.

The API's version model includes a "status" field with one of "unknown",
"current", "future", "retired", "beta", and "retired beta" [2]. It's
intended to reflect the vendor's support for a version.

For example, Mozilla has a rapid release (RR) variant, which gets a new
number, moving the old RR version to "retired" and the new version from
"future" to "current". There is also an extended support release (ESR)
version that is supported for a longer time span [3]. Ideally, Firefox
Desktop will show two "current" versions, for the RR and ESR releases.
This relies on contributors updating the API data as new versions are
released.

In this case, it sounds like Google is not supporting "Android Browser",
which would imply all versions get the "retired" tag. If there is a
dominant, community-supported fork of Android Browser, then I think that
community could call that version "current", with the release_notes_url
pointing to their version. I'd also support a new browser identity for the
fork. It's a branding and "least surprise" decision - what do mobile
developers expect? There API data is a reflection of the community
consensus, not observations made by robots.

The API's job is to provide the data, and the client is responsible for
display. The API packages related data (browsers, versions, specs, etc.)
in a "view_feature" response, which includes some extra data to make
current MDN-style displays easier, such as suggesting important versions to
display, and organizing browsers into desktop and mobile groups. [4] This
hack can be ignored by clients, who could ignore the "meta" section and
process the data directly to decide what to display. Or, the meta hack
could grow into a feature, such as "browser sets", to designate a filter of
browsers and versions that the client is interested in, or versions could
be annotated with the latest market share.

Of course, intention is one thing, and execution another. I'm impatient to
see any API-derived data on MDN, and consider other considerations second
priority. There is enough uncertainty in the thinnest of vertical
functional slices to occupy the MDN team.

John

[1]
https://web-platform-compat.readthedocs.org/en/latest/draft/resources.html#browsers
[2]
https://web-platform-compat.readthedocs.org/en/latest/draft/resources.html#versions
[3] https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment
[4] https://web-platform-compat.readthedocs.org/en/latest/draft/views.html