Proposed new WMF browser support framework for MediaWiki

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposed new WMF browser support framework for MediaWiki

James Forrester-4
All,

*TL;DR: We're proposing a more formal, but more limited, statement of
browser 'support' for the cluster; thoughts appreciated.*

In WMF Engineering, we've been struggling with what we mean by 'supporting'
browsers, and how we can match limited developer time to our natural desire
to make everyone happy.

Right now our 'support' for user agents varies between existing features
and in particular between different developing products, but we lack a
single framework in which to consistently express what works and - more
importantly - what our users should expect to work. We have a
chronically-misleading page on
MWwiki<https://www.mediawiki.org/wiki/Compatibility#Browser> that
currently claims we will support any browser which gives us more than 0.01%
of users (an extremely-expensive claim) - this was changed in
August<https://www.mediawiki.org/w/index.php?title=Compatibility&diff=571245&oldid=571244>
from
the 0.1% threshold you see around more often, or the 1% one that we started
with.

So, the new proposal:

There would be a "top level" outline policy - a small number
of browsers are supported (i.e., WMF will keep spending money until they
work):

* Desktop: Current and immediately-previous versions of Chrome, Firefox,
MSIE and Safari
* Tablet: Current versions of iOS/Safari; Current and immediately-previous
ones of Android
* Mobile: Current versions of iOS/Safari; Current and the five previous
ones of Android[*]

Anything not in this list may "happen to work" but WMF Engineering will not
spend resources (read, developer time) on it. If a volunteer is willing to
work like hell to make, say, the VisualEditor work in Opera we would try to
support them by reviewing/accepting patches, but nothing more than that. It
doesn't mean we would go out of our way to break previous browsers as they
leave support, but we would not hold ourselves back from useful development
solely because it might break browsers that we've actively decided not
to support.

Each piece of feature development and platform work would explicitly say
whether it was to inherit this top-level policy or chose its own. This
would be based on what technical needs the product has and the user
goals/break-down. These product support policies would be reviewed by the
team every now and then and can go further or less far than the main policy
depending on circumstances - that's the decision of the team involved.

For example, the Mobile team's work might want to go further and support
mobile Opera, but might not care about breaking desktop support (as it's
not a target for them). As another example, for "basic" functionality in
Platform - I'm thinking specifically about just article-namespace reading,
history viewing and diffing - we might well want to be very broad in our
support, down even below the historic "0.1%" level.

I have created a browser
matrix<https://www.mediawiki.org/wiki/VisualEditor/2012-13_Q2_forward-look#Browser_matrix>
for
VisualEditor to identify the browser support that our team will be able to
provide. This is a table with ticks or crosses for support
of grouped browsers, gated at the 0.1% threshold (so browsers used by fewer
than 0.1% of our readers like IE 5.0 don't show up). This is now actually a
template which is as not-ugly as you can make it in wikitext[+]; I'm happy
to commit to updating its data every month as it's released so teams can
create their own, though finding a way to get this created automatically
would be nice too.

So, to turn this mass of text into an 'ask', I would love the thoughts of
this list about this. Do you think this might work? Is "making sure all the
different parts of MediaWiki keep working with <browser I love>" something
you'd see yourself volunteering to do?

I'd be happy to talk through the individual browser-level decisions but it
might be easier to agree that we want to focus browser support before we
decide the exact focus of this. :-) That said, do you think we should
support fewer browsers than those I've proposed (and if so, which and
why)? Different ones (again, why)? More (and if so, what do you propose we
stop doing instead)? Feedback would be very helpful.


[*] - This is what is meant when people bemoan "Android fragmentation".
[+] - Ironically for a page about the VisualEditor, creating wikitext that
it will likely forever struggle to edit.

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Tyler Romeo
If this plan is implemented, I'd recommend still testing with older
browsers rather than just saying it may happen to work or not.

--Tyler Romeo
On Nov 20, 2012 8:20 PM, "James Forrester" <[hidden email]> wrote:

> All,
>
> *TL;DR: We're proposing a more formal, but more limited, statement of
> browser 'support' for the cluster; thoughts appreciated.*
>
> In WMF Engineering, we've been struggling with what we mean by 'supporting'
> browsers, and how we can match limited developer time to our natural desire
> to make everyone happy.
>
> Right now our 'support' for user agents varies between existing features
> and in particular between different developing products, but we lack a
> single framework in which to consistently express what works and - more
> importantly - what our users should expect to work. We have a
> chronically-misleading page on
> MWwiki<https://www.mediawiki.org/wiki/Compatibility#Browser> that
> currently claims we will support any browser which gives us more than 0.01%
> of users (an extremely-expensive claim) - this was changed in
> August<
> https://www.mediawiki.org/w/index.php?title=Compatibility&diff=571245&oldid=571244
> >
> from
> the 0.1% threshold you see around more often, or the 1% one that we started
> with.
>
> So, the new proposal:
>
> There would be a "top level" outline policy - a small number
> of browsers are supported (i.e., WMF will keep spending money until they
> work):
>
> * Desktop: Current and immediately-previous versions of Chrome, Firefox,
> MSIE and Safari
> * Tablet: Current versions of iOS/Safari; Current and immediately-previous
> ones of Android
> * Mobile: Current versions of iOS/Safari; Current and the five previous
> ones of Android[*]
>
> Anything not in this list may "happen to work" but WMF Engineering will not
> spend resources (read, developer time) on it. If a volunteer is willing to
> work like hell to make, say, the VisualEditor work in Opera we would try to
> support them by reviewing/accepting patches, but nothing more than that. It
> doesn't mean we would go out of our way to break previous browsers as they
> leave support, but we would not hold ourselves back from useful development
> solely because it might break browsers that we've actively decided not
> to support.
>
> Each piece of feature development and platform work would explicitly say
> whether it was to inherit this top-level policy or chose its own. This
> would be based on what technical needs the product has and the user
> goals/break-down. These product support policies would be reviewed by the
> team every now and then and can go further or less far than the main policy
> depending on circumstances - that's the decision of the team involved.
>
> For example, the Mobile team's work might want to go further and support
> mobile Opera, but might not care about breaking desktop support (as it's
> not a target for them). As another example, for "basic" functionality in
> Platform - I'm thinking specifically about just article-namespace reading,
> history viewing and diffing - we might well want to be very broad in our
> support, down even below the historic "0.1%" level.
>
> I have created a browser
> matrix<
> https://www.mediawiki.org/wiki/VisualEditor/2012-13_Q2_forward-look#Browser_matrix
> >
> for
> VisualEditor to identify the browser support that our team will be able to
> provide. This is a table with ticks or crosses for support
> of grouped browsers, gated at the 0.1% threshold (so browsers used by fewer
> than 0.1% of our readers like IE 5.0 don't show up). This is now actually a
> template which is as not-ugly as you can make it in wikitext[+]; I'm happy
> to commit to updating its data every month as it's released so teams can
> create their own, though finding a way to get this created automatically
> would be nice too.
>
> So, to turn this mass of text into an 'ask', I would love the thoughts of
> this list about this. Do you think this might work? Is "making sure all the
> different parts of MediaWiki keep working with <browser I love>" something
> you'd see yourself volunteering to do?
>
> I'd be happy to talk through the individual browser-level decisions but it
> might be easier to agree that we want to focus browser support before we
> decide the exact focus of this. :-) That said, do you think we should
> support fewer browsers than those I've proposed (and if so, which and
> why)? Different ones (again, why)? More (and if so, what do you propose we
> stop doing instead)? Feedback would be very helpful.
>
>
> [*] - This is what is meant when people bemoan "Android fragmentation".
> [+] - Ironically for a page about the VisualEditor, creating wikitext that
> it will likely forever struggle to edit.
>
> J.
> --
> James D. Forrester
> Product Manager, VisualEditor
> Wikimedia Foundation, Inc.
>
> [hidden email] | @jdforrester
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Brion Vibber
In reply to this post by James Forrester-4
On Tue, Nov 20, 2012 at 5:19 PM, James Forrester
<[hidden email]>wrote:

> So, the new proposal:
>
> There would be a "top level" outline policy - a small number
> of browsers are supported (i.e., WMF will keep spending money until they
> work):
>
> * Desktop: Current and immediately-previous versions of Chrome, Firefox,
> MSIE and Safari
> * Tablet: Current versions of iOS/Safari; Current and immediately-previous
> ones of Android
> * Mobile: Current versions of iOS/Safari; Current and the five previous
> ones of Android[*]
>
> Anything not in this list may "happen to work" but WMF Engineering will not
> spend resources (read, developer time) on it. If a volunteer is willing to
> work like hell to make, say, the VisualEditor work in Opera we would try to
> support them by reviewing/accepting patches, but nothing more than that. It
> doesn't mean we would go out of our way to break previous browsers as they
> leave support, but we would not hold ourselves back from useful development
> solely because it might break browsers that we've actively decided not
> to support.
>


In supporting browsers, there are basically a few categories of 'stuff you
might have to do for a particular browser':

* use of features whose presence can be detected
* use of features whose presence cannot be detected
* workaround of bugs whose presence can be detected
* workaround of bugs whose presence cannot be detected

Presence of features and bugs may, or may not, match up with major version
numbers of software releases, so it's actually kind of tough to use a
matrix for declaring what we should support. :(

"Current and immediately-previous" releases are also really hard to match
up between projects on fast release cycles (like Chrome and Firefox which
are pushing out new "major versions" every couple months) and those where
"major versions" only change a few times per decade, like IE.

Supporting Chrome 22 (23 - 1) and supporting IE 9 (10 - 1) are totally
different animals with different usage profiles. Really nobody should be
running Chrome 22 -- it probably means your computer's broken and not
installing updates -- but IE 9's all over the place -- as is 8.

What a matrix is *really good* at though is two things:
* telling us what portion of our audience uses certain browser versions,
which gives us some information for prioritization if a compatibility
problem arises
* telling ourselves/our testers what they should test on to confirm that
they work

Roughly speaking, stuff should work in every browser that would reasonably
support it without browser bugs. In the presence of browser bugs, we can go
anywhere from inventing workarounds to blacklisting particular versions,
and depending on the importance of the feature, ubiquity of the software
version, etc it may be totally reasonable to leave some things broken or
blacklist a feature on some browser version.

Let's not be afraid to blacklist things, but a one-size-fits-all default
policy is tough to determine.

-- brion
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Faidon Liambotis
In reply to this post by James Forrester-4
On Tue, Nov 20, 2012 at 05:19:51PM -0800, James Forrester wrote:
> In WMF Engineering, we've been struggling with what we mean by 'supporting'
> browsers, and how we can match limited developer time to our natural desire
> to make everyone happy.
> <snip>
> So, to turn this mass of text into an 'ask', I would love the thoughts of
> this list about this. Do you think this might work? Is "making sure all the
> different parts of MediaWiki keep working with <browser I love>" something
> you'd see yourself volunteering to do?

So, I think you're intermixing two different things: MediaWiki support
and "WMF Engineering" or "cluster" browser support. They're not exactly
the same thing.

For example, browsers make a huge difference in the SSL features they
support. So, we currently don't do SNI, as it's unsupported on certain
browser/platforms¹ (mainly: Windows XP and Android < 3). Other SSL
features (e.g. RFC 5077) are in a similar state, and I guess we can
think of other such features not exclusive to MediaWiki.

Should this policy be expanded to cover such cases too? I think so. We
should definitely put more effort though and expand your use cases to
ops use cases too.

Regards,
Faidon

¹: http://en.wikipedia.org/wiki/Server_Name_Indication#Browsers_with_support_for_TLS_server_name_indication.5B5.5D

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Faidon Liambotis
In reply to this post by Brion Vibber
On Tue, Nov 20, 2012 at 05:46:22PM -0800, Brion Vibber wrote:
> "Current and immediately-previous" releases are also really hard to match
> up between projects on fast release cycles (like Chrome and Firefox which
> are pushing out new "major versions" every couple months) and those where
> "major versions" only change a few times per decade, like IE.
>
> Supporting Chrome 22 (23 - 1) and supporting IE 9 (10 - 1) are totally
> different animals with different usage profiles. Really nobody should be
> running Chrome 22 -- it probably means your computer's broken and not
> installing updates -- but IE 9's all over the place -- as is 8.

Agreed. IE 9 is only supported from Vista onwards and Windows XP is
21.29% of our user base according to the latest stats¹. I'm not sure
it's realistic to say that 20% of our user base may just "happen to
work" by luck.

Regards,
Faidon

¹: http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Steven Walling
In reply to this post by James Forrester-4
On Tue, Nov 20, 2012 at 5:19 PM, James Forrester
<[hidden email]>wrote:

> *TL;DR: We're proposing a more formal, but more limited, statement of
> browser 'support' for the cluster; thoughts appreciated.*
>

It's obviously good to take in to account the feedback Brion, Faidon, and
I'm sure others will give. But having a clearly defined list of browsers we
support is not a nice to have, it's necessary.

Thanks for working on this James. I look forward to being able to be wiser
about how much time we spend supporting old/obscure browsers.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Leslie Carr
In reply to this post by James Forrester-4
On Tue, Nov 20, 2012 at 5:19 PM, James Forrester
<[hidden email]> wrote:

> All,
>
> *TL;DR: We're proposing a more formal, but more limited, statement of
> browser 'support' for the cluster; thoughts appreciated.*
>
> In WMF Engineering, we've been struggling with what we mean by 'supporting'
> browsers, and how we can match limited developer time to our natural desire
> to make everyone happy.
>
> Right now our 'support' for user agents varies between existing features
> and in particular between different developing products, but we lack a
> single framework in which to consistently express what works and - more
> importantly - what our users should expect to work. We have a
> chronically-misleading page on
> MWwiki<https://www.mediawiki.org/wiki/Compatibility#Browser> that
> currently claims we will support any browser which gives us more than 0.01%
> of users (an extremely-expensive claim) - this was changed in
> August<https://www.mediawiki.org/w/index.php?title=Compatibility&diff=571245&oldid=571244>
> from
> the 0.1% threshold you see around more often, or the 1% one that we started
> with.
>
> So, the new proposal:
>
> There would be a "top level" outline policy - a small number
> of browsers are supported (i.e., WMF will keep spending money until they
> work):
>
> * Desktop: Current and immediately-previous versions of Chrome, Firefox,
> MSIE and Safari

I hate to make our job more difficult, but I think Faidon had a good point --

<Quote>
Agreed. IE 9 is only supported from Vista onwards and Windows XP is
21.29% of our user base according to the latest stats¹. I'm not sure
it's realistic to say that 20% of our user base may just "happen to
work" by luck.
</Quote>

Perhaps a percentage of use threshold system would be a bit better?  I
don't see a breakdown of a % of requests per client type
(desktop/phone/tablet) here -
http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm ,
but it should be creatable and hopefully bring a balance between
trying to come up with crazy workarounds for old clients and keeping
functionality for the vast majority of users.


Leslie

> * Tablet: Current versions of iOS/Safari; Current and immediately-previous
> ones of Android
> * Mobile: Current versions of iOS/Safari; Current and the five previous
> ones of Android[*]
>
> Anything not in this list may "happen to work" but WMF Engineering will not
> spend resources (read, developer time) on it. If a volunteer is willing to
> work like hell to make, say, the VisualEditor work in Opera we would try to
> support them by reviewing/accepting patches, but nothing more than that. It
> doesn't mean we would go out of our way to break previous browsers as they
> leave support, but we would not hold ourselves back from useful development
> solely because it might break browsers that we've actively decided not
> to support.
>
> Each piece of feature development and platform work would explicitly say
> whether it was to inherit this top-level policy or chose its own. This
> would be based on what technical needs the product has and the user
> goals/break-down. These product support policies would be reviewed by the
> team every now and then and can go further or less far than the main policy
> depending on circumstances - that's the decision of the team involved.
>
> For example, the Mobile team's work might want to go further and support
> mobile Opera, but might not care about breaking desktop support (as it's
> not a target for them). As another example, for "basic" functionality in
> Platform - I'm thinking specifically about just article-namespace reading,
> history viewing and diffing - we might well want to be very broad in our
> support, down even below the historic "0.1%" level.
>
> I have created a browser
> matrix<https://www.mediawiki.org/wiki/VisualEditor/2012-13_Q2_forward-look#Browser_matrix>
> for
> VisualEditor to identify the browser support that our team will be able to
> provide. This is a table with ticks or crosses for support
> of grouped browsers, gated at the 0.1% threshold (so browsers used by fewer
> than 0.1% of our readers like IE 5.0 don't show up). This is now actually a
> template which is as not-ugly as you can make it in wikitext[+]; I'm happy
> to commit to updating its data every month as it's released so teams can
> create their own, though finding a way to get this created automatically
> would be nice too.
>
> So, to turn this mass of text into an 'ask', I would love the thoughts of
> this list about this. Do you think this might work? Is "making sure all the
> different parts of MediaWiki keep working with <browser I love>" something
> you'd see yourself volunteering to do?
>
> I'd be happy to talk through the individual browser-level decisions but it
> might be easier to agree that we want to focus browser support before we
> decide the exact focus of this. :-) That said, do you think we should
> support fewer browsers than those I've proposed (and if so, which and
> why)? Different ones (again, why)? More (and if so, what do you propose we
> stop doing instead)? Feedback would be very helpful.
>
>
> [*] - This is what is meant when people bemoan "Android fragmentation".
> [+] - Ironically for a page about the VisualEditor, creating wikitext that
> it will likely forever struggle to edit.
>
> J.
> --
> James D. Forrester
> Product Manager, VisualEditor
> Wikimedia Foundation, Inc.
>
> [hidden email] | @jdforrester
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Leslie Carr
Wikimedia Foundation
AS 14907, 43821
http://as14907.peeringdb.com/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Martijn Hoekstra
On Nov 21, 2012 7:13 AM, "Leslie Carr" <[hidden email]> wrote:
>
> On Tue, Nov 20, 2012 at 5:19 PM, James Forrester
> <[hidden email]> wrote:
> > All,
> >
> > *TL;DR: We're proposing a more formal, but more limited, statement of
> > browser 'support' for the cluster; thoughts appreciated.*
> >
> > In WMF Engineering, we've been struggling with what we mean by
'supporting'
> > browsers, and how we can match limited developer time to our natural
desire
> > to make everyone happy.
> >
> > Right now our 'support' for user agents varies between existing features
> > and in particular between different developing products, but we lack a
> > single framework in which to consistently express what works and - more
> > importantly - what our users should expect to work. We have a
> > chronically-misleading page on
> > MWwiki<https://www.mediawiki.org/wiki/Compatibility#Browser> that
> > currently claims we will support any browser which gives us more than
0.01%
> > of users (an extremely-expensive claim) - this was changed in
> > August<
https://www.mediawiki.org/w/index.php?title=Compatibility&diff=571245&oldid=571244
>
> > from
> > the 0.1% threshold you see around more often, or the 1% one that we
started

> > with.
> >
> > So, the new proposal:
> >
> > There would be a "top level" outline policy - a small number
> > of browsers are supported (i.e., WMF will keep spending money until they
> > work):
> >
> > * Desktop: Current and immediately-previous versions of Chrome, Firefox,
> > MSIE and Safari
>
> I hate to make our job more difficult, but I think Faidon had a good
point --

>
> <Quote>
> Agreed. IE 9 is only supported from Vista onwards and Windows XP is
> 21.29% of our user base according to the latest stats¹. I'm not sure
> it's realistic to say that 20% of our user base may just "happen to
> work" by luck.
> </Quote>
>
> Perhaps a percentage of use threshold system would be a bit better?  I
> don't see a breakdown of a % of requests per client type
> (desktop/phone/tablet) here -
> http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm ,
> but it should be creatable and hopefully bring a balance between
> trying to come up with crazy workarounds for old clients and keeping
> functionality for the vast majority of users.
>
>
> Leslie

I think a best of both worlds would be preferable. I haven't seen the
stats, but I'd assume market share of IE 10 will be quite low. Still it
would be silly to not strive to support it. How about any browser released
in the last n months whose browser family has more then x % market share
plus any individual browser version with more then m % market share for
some sensible figures n, x and m?

>
> > * Tablet: Current versions of iOS/Safari; Current and
immediately-previous
> > ones of Android
> > * Mobile: Current versions of iOS/Safari; Current and the five previous
> > ones of Android[*]
> >
> > Anything not in this list may "happen to work" but WMF Engineering will
not
> > spend resources (read, developer time) on it. If a volunteer is willing
to
> > work like hell to make, say, the VisualEditor work in Opera we would
try to
> > support them by reviewing/accepting patches, but nothing more than
that. It
> > doesn't mean we would go out of our way to break previous browsers as
they
> > leave support, but we would not hold ourselves back from useful
development
> > solely because it might break browsers that we've actively decided not
> > to support.
> >
> > Each piece of feature development and platform work would explicitly say
> > whether it was to inherit this top-level policy or chose its own. This
> > would be based on what technical needs the product has and the user
> > goals/break-down. These product support policies would be reviewed by
the
> > team every now and then and can go further or less far than the main
policy
> > depending on circumstances - that's the decision of the team involved.
> >
> > For example, the Mobile team's work might want to go further and support
> > mobile Opera, but might not care about breaking desktop support (as it's
> > not a target for them). As another example, for "basic" functionality in
> > Platform - I'm thinking specifically about just article-namespace
reading,
> > history viewing and diffing - we might well want to be very broad in our
> > support, down even below the historic "0.1%" level.
> >
> > I have created a browser
> > matrix<
https://www.mediawiki.org/wiki/VisualEditor/2012-13_Q2_forward-look#Browser_matrix
>
> > for
> > VisualEditor to identify the browser support that our team will be able
to
> > provide. This is a table with ticks or crosses for support
> > of grouped browsers, gated at the 0.1% threshold (so browsers used by
fewer
> > than 0.1% of our readers like IE 5.0 don't show up). This is now
actually a
> > template which is as not-ugly as you can make it in wikitext[+]; I'm
happy
> > to commit to updating its data every month as it's released so teams can
> > create their own, though finding a way to get this created automatically
> > would be nice too.
> >
> > So, to turn this mass of text into an 'ask', I would love the thoughts
of
> > this list about this. Do you think this might work? Is "making sure all
the
> > different parts of MediaWiki keep working with <browser I love>"
something
> > you'd see yourself volunteering to do?
> >
> > I'd be happy to talk through the individual browser-level decisions but
it
> > might be easier to agree that we want to focus browser support before we
> > decide the exact focus of this. :-) That said, do you think we should
> > support fewer browsers than those I've proposed (and if so, which and
> > why)? Different ones (again, why)? More (and if so, what do you propose
we
> > stop doing instead)? Feedback would be very helpful.
> >
> >
> > [*] - This is what is meant when people bemoan "Android fragmentation".
> > [+] - Ironically for a page about the VisualEditor, creating wikitext
that

> > it will likely forever struggle to edit.
> >
> > J.
> > --
> > James D. Forrester
> > Product Manager, VisualEditor
> > Wikimedia Foundation, Inc.
> >
> > [hidden email] | @jdforrester
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Leslie Carr
> Wikimedia Foundation
> AS 14907, 43821
> http://as14907.peeringdb.com/
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Quim Gil-2
In reply to this post by James Forrester-4
On 11/20/2012 05:19 PM, James Forrester wrote:
> * Desktop: Current and immediately-previous versions of Chrome, Firefox,
> MSIE and Safari
> * Tablet: Current versions of iOS/Safari; Current and immediately-previous
> ones of Android
> * Mobile: Current versions of iOS/Safari; Current and the five previous
> ones of Android[*]
>
> Anything not in this list may "happen to work" but WMF Engineering will not
> spend resources (read, developer time) on it.

What types of problems are giving you a hard time keeping the support?
Newest versions of browsers can be as painful to support as legacy ones,
but the types of problems are probably very different.

Are we talking about bugs in the browsers? Sui generis interpretations
of HTML/CSS/JS specs? Performance problems? Limitations in the devices
using those browsers? Use of browser X specific features / workarounds
in our software?

Or is it simply a matter of us being unable to test through >15 browsers
and therefore trying to find criteria to limit the number to a more
feasible <10?

Someting to take into account is that developer teams of browsers not in
Wikimedia's "Tier 1" might be interested in driving the tests
themselves, as part of their productization work. Think of Opera,
Windows Phone, Blackberry, Series 40... Wikipedia is a top global site
and probably they are already testing their latest version against it.

We could guide them better on what to test and how to find / file /
comment on bugs and contribute patches. Having a regular contact in each
of those teams would be really useful.

Would this be helpful, and fitting in your browser support plans?

--
Quim

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

James Forrester-4
In reply to this post by Faidon Liambotis
On 20 November 2012 19:53, Faidon Liambotis <[hidden email]> wrote:

>
> On Tue, Nov 20, 2012 at 05:19:51PM -0800, James Forrester wrote:
> > In WMF Engineering, we've been struggling with what we mean by 'supporting'
> > browsers, and how we can match limited developer time to our natural desire
> > to make everyone happy.
> > <snip>
> > So, to turn this mass of text into an 'ask', I would love the thoughts of
> > this list about this. Do you think this might work? Is "making sure all the
> > different parts of MediaWiki keep working with <browser I love>" something
> > you'd see yourself volunteering to do?
>
> So, I think you're intermixing two different things: MediaWiki support
> and "WMF Engineering" or "cluster" browser support.

I disagree. I switched from talking about WMF Engineering to asking
whether third parties, enthusiasts and volunteers would want to take
on wider MediaWiki support because an effect of our suggested policy
is that WMF's involvement in MediaWiki support for browsers not on
"our list" will reduce. This does not mean I think the two things are
the same; I would love MediaWiki to work perfectly with a wider range
of user agents than WMF has the resources to support.

[Snip]

> For example, browsers make a huge difference in the SSL features they
> support. So, we currently don't do SNI, as it's unsupported on certain
> browser/platforms¹ (mainly: Windows XP and Android < 3). Other SSL
> features (e.g. RFC 5077) are in a similar state, and I guess we can
> think of other such features not exclusive to MediaWiki.
>
> Should this policy be expanded to cover such cases too? I think so. We
> should definitely put more effort though and expand your use cases to
> ops use cases too.

Yes, this policy would cover all of WMF Engineering; sorry for not
picking an area in Ops as one of my two examples. :-)

In this particular case, it might well be that you (or someone else in
Ops) at some point makes the call that using SNI is more important
than supporting users with Windows XP (though probably not whilst
they're 21%(!) of our users). I'd expect you to highlight this change
in support to the wider community rather than just breaking it by
switching over, but that is what the framework is for - making a
decision and justifying it. :-)

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

James Forrester-4
In reply to this post by Faidon Liambotis
On 20 November 2012 20:00, Faidon Liambotis <[hidden email]> wrote:

> On Tue, Nov 20, 2012 at 05:46:22PM -0800, Brion Vibber wrote:
>> "Current and immediately-previous" releases are also really hard to match
>> up between projects on fast release cycles (like Chrome and Firefox which
>> are pushing out new "major versions" every couple months) and those where
>> "major versions" only change a few times per decade, like IE.
>>
>> Supporting Chrome 22 (23 - 1) and supporting IE 9 (10 - 1) are totally
>> different animals with different usage profiles. Really nobody should be
>> running Chrome 22 -- it probably means your computer's broken and not
>> installing updates -- but IE 9's all over the place -- as is 8.
>
> Agreed. IE 9 is only supported from Vista onwards and Windows XP is
> 21.29% of our user base according to the latest stats¹. I'm not sure
> it's realistic to say that 20% of our user base may just "happen to
> work" by luck.

Those numbers are people using Windows XP, not people using Windows XP
with IE. I believe the numbers for (XP && IE) are going to be
substantially lower - probably half - but still far to high to
discount. However, you are right that Windows XP is likely to become
the next barrier to proper Web development after IE6, and perhaps we
should instead make an exception for IE compared to the other big four
browsers and suggest supporting current, and two immediately-previous
versions.

Given that I suggested "I'd be happy to talk through the individual
browser-level decisions but it might be easier to agree that we want
to focus browser support before we decide the exact focus of this."
I'm assuming this means you're happy with the overall policy and we're
just bike-shedding over which versions of which browsers? ;-)

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

James Forrester-4
In reply to this post by Leslie Carr
On 20 November 2012 22:12, Leslie Carr <[hidden email]> wrote:

> I hate to make our job more difficult, but I think Faidon had a good point --
>
> <Quote>
> Agreed. IE 9 is only supported from Vista onwards and Windows XP is
> 21.29% of our user base according to the latest stats¹. I'm not sure
> it's realistic to say that 20% of our user base may just "happen to
> work" by luck.
> </Quote>
>
> Perhaps a percentage of use threshold system would be a bit better?  I
> don't see a breakdown of a % of requests per client type
> (desktop/phone/tablet) here -
> http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm ,
> but it should be creatable and hopefully bring a balance between
> trying to come up with crazy workarounds for old clients and keeping
> functionality for the vast majority of users.

Do you mean a breakdown by combination of OS, OS version, browser, and
browser version? Yes, this would be very useful. The closest data on
this I can find online[*] (Flash, eww) sadly doesn't give the
breakdown by browser version (and the numbers are a little different
to ours; they're probably polling from a different demographic).

[*] - http://www.statowl.com/operating_system_market_share_by_os_version.php?timeframe=last_6&interval=month&chart_id=4&limit%5B%5D=windows&limit%5B%5D=mac&limit%5B%5D=linux&fltr_br=Internet+Explorer&fltr_se=&fltr_cn=

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Isarra Yos
In reply to this post by Quim Gil-2
On 21/11/2012 08:41, Quim Gil wrote:

> On 11/20/2012 05:19 PM, James Forrester wrote:
>> * Desktop: Current and immediately-previous versions of Chrome, Firefox,
>> MSIE and Safari
>> * Tablet: Current versions of iOS/Safari; Current and
>> immediately-previous
>> ones of Android
>> * Mobile: Current versions of iOS/Safari; Current and the five previous
>> ones of Android[*]
>>
>> Anything not in this list may "happen to work" but WMF Engineering
>> will not
>> spend resources (read, developer time) on it.
>
> Someting to take into account is that developer teams of browsers not
> in Wikimedia's "Tier 1" might be interested in driving the tests
> themselves, as part of their productization work. Think of Opera,
> Windows Phone, Blackberry, Series 40... Wikipedia is a top global site
> and probably they are already testing their latest version against it.
>
> We could guide them better on what to test and how to find / file /
> comment on bugs and contribute patches. Having a regular contact in
> each of those teams would be really useful.
>
> Would this be helpful, and fitting in your browser support plans?

Frankly, the rather limited proposed support was a little surprising to
me - I would have expected at least some effort toward supporting
anything in the billions of hits per month. I know Wikimedia is big, and
all that, but that means the support would need to be big as well... and
it also means that what Quim Gil puts forward here may well be plausible.

I dunno, perhaps I'm just biased because none of the browsers I use even
made the list, but different browsers can support different hardware
very differently...

--
-— Isarra


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

James Forrester-4
In reply to this post by Martijn Hoekstra
On 20 November 2012 23:54, Martijn Hoekstra <[hidden email]> wrote:
> I think a best of both worlds would be preferable. I haven't seen the
> stats, but I'd assume market share of IE 10 will be quite low. Still it
> would be silly to not strive to support it.

Well, until this month IE 10 wasn't released (just a developer
version; I wasn't counting these). Thus the "current and
immediately-previous versions" for IE would have been 9 and 8.
Supporting browsers before they're released is a nice-to-have and, as
you say, sensible to get ahead of the work, but it's not as crucial as
fixing "live" versions for millions of people.

> How about any browser released
> in the last n months whose browser family has more then x % market share
> plus any individual browser version with more then m % market share for
> some sensible figures n, x and m?

Interesting idea. Perhaps x = 5, m = 1 and n = 12; with these numbers
we'd get pretty much what I suggested, plus IE 7 and Opera 12. The
cost of supporting these (especially IE 7) would be heroic in some
areas, however - but that's what the "local policies" for different
features are for, after all.

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

James Forrester-4
In reply to this post by Quim Gil-2
On 21 November 2012 07:41, Quim Gil <[hidden email]> wrote:
> What types of problems are giving you a hard time keeping the support?
> Newest versions of browsers can be as painful to support as legacy ones, but
> the types of problems are probably very different.
>
> Are we talking about bugs in the browsers? Sui generis interpretations of
> HTML/CSS/JS specs? Performance problems? Limitations in the devices using
> those browsers? Use of browser X specific features / workarounds in our
> software?

All of these, but especially the "Specification? What specification?
We do things differently here!" problem.

> Or is it simply a matter of us being unable to test through >15 browsers and
> therefore trying to find criteria to limit the number to a more feasible
> <10?

No; testing infrastructure is something we need to do however many
browsers we're supporting (and is trivial compared to the work in
supporting the CSS issues of IE7, for example).

> Someting to take into account is that developer teams of browsers not in
> Wikimedia's "Tier 1" might be interested in driving the tests themselves, as
> part of their productization work. Think of Opera, Windows Phone,
> Blackberry, Series 40... Wikipedia is a top global site and probably they
> are already testing their latest version against it.
>
> We could guide them better on what to test and how to find / file / comment
> on bugs and contribute patches. Having a regular contact in each of those
> teams would be really useful.
>
> Would this be helpful, and fitting in your browser support plans?

Yes, definitely; if someone from Opera wanted to put in the work to
make Opera and MediaWiki compatible, and that that would make more
sense as patches for MW rather than for Opera, of course we'd love to
see that. This is what I meant by "[i]f a volunteer is willing to work
like hell to make, say, the VisualEditor work in Opera we would try to
support them by reviewing/accepting patches".

Having better (any?) relationships with the browser manufacturers
would be excellent, of course.

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

James Forrester-4
In reply to this post by Isarra Yos
On 21 November 2012 09:32, Isarra Yos <[hidden email]> wrote:
> Frankly, the rather limited proposed support was a little surprising to me -
> I would have expected at least some effort toward supporting anything in the
> billions of hits per month.

Our 20 bn page hits a month overall means "over a billion" is a
threshold around 2%. My proposal would cut out two of those (IE 7 and
Opera 12), and was just a suggestion, not an announcement of a
decision already taken. :-)

> I dunno, perhaps I'm just biased because none of the browsers I use even
> made the list, but different browsers can support different hardware very
> differently...

Indeed. Which browsers would you like to see added?

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Gabriel Wicke-3
In reply to this post by James Forrester-4
On 11/20/2012 05:19 PM, James Forrester wrote:
> There would be a "top level" outline policy - a small number
> of browsers are supported (i.e., WMF will keep spending money until they
> work):

> Anything not in this list may "happen to work" but WMF Engineering will not
> spend resources (read, developer time) on it.

I don't think that a binary 'is supported' list is that helpful for the
optimization of average user experience with limited resources.

Progressive enhancement [1] (aka 'responsive design') has in the past
been very successful at making most of our users happy. If it is
technically possible to provide a sane (but not necessarily as flashy)
user experience for users of older browsers with little extra work, then
that is an easy optimization win that should not be ignored.

This does complicate matters a bit for product, as decisions in this
area are very dependent on technical detail and differ from case to
case. It would however be sad to see more manpower in product to result
in less attention being given to this detail in the name of easily
presentable support charts. Users receiving an unreasonable 'your
platform is not supported at all' message do not care about browser
support charts- all that matters to them is that they are shut out of
whatever they were trying to do.

What exactly most users are trying to do might actually vary a bit
between browser generations, which can also be exploited in the
optimization process. I would guess that experienced editors are more
likely to run recent software than anonymous users. Features geared
towards anonymous users should thus probably emphasize compatibility
over flashiness, while features aimed at power users can make more use
of recent browser technology.

Gabriel

[1]: http://en.wikipedia.org/wiki/Progressive_enhancement
--
Gabriel Wicke
Senior Software Developer
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Thomas Dalton
In reply to this post by James Forrester-4
> So, the new proposal:
>
> There would be a "top level" outline policy - a small number
> of browsers are supported (i.e., WMF will keep spending money until they
> work):
>
> * Desktop: Current and immediately-previous versions of Chrome, Firefox,
> MSIE and Safari
> * Tablet: Current versions of iOS/Safari; Current and immediately-previous
> ones of Android
> * Mobile: Current versions of iOS/Safari; Current and the five previous
> ones of Android[*]
>
> Anything not in this list may "happen to work" but WMF Engineering will not
> spend resources (read, developer time) on it. If a volunteer is willing to
> work like hell to make, say, the VisualEditor work in Opera we would try to
> support them by reviewing/accepting patches, but nothing more than that. It
> doesn't mean we would go out of our way to break previous browsers as they
> leave support, but we would not hold ourselves back from useful development
> solely because it might break browsers that we've actively decided not
> to support.

"Support" is a very vague term. I think we need to recognise that, in
reality, we will support different browsers to different degrees.
There is a big difference between "everything works exactly as
intended" and "you can read articles with no noticeable problems, but
some advanced features fail gracefully". Your list may be appropriate
for the former, but we should support significantly more browsers (the
0.1% threshold, perhaps) at the latter level (which probably won't
involve too much work, as long as you're happy to just blacklist
things if they're not easy to fix).

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Steven Walling
In reply to this post by Gabriel Wicke-3
On Wed, Nov 21, 2012 at 10:25 AM, Gabriel Wicke <[hidden email]>wrote:

> This does complicate matters a bit for product, as decisions in this
> area are very dependent on technical detail and differ from case to
> case. It would however be sad to see more manpower in product to result
> in less attention being given to this detail in the name of easily
> presentable support charts.
>

That was a bit mean-spirited I think. The work to make the site degrade
gracefully is not just on the product management side, it is also effort
for designers and features engineers which may already feel overworked
maintaining one version of what they build -- or rather, one version for
many skins and languages.

I was going to go on a long rant here in response to your assertion that we
shouldn't have a flashy interface, but I'll spare everyone and just say
that I strongly disagree.

Steven
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposed new WMF browser support framework for MediaWiki

Faidon Liambotis
In reply to this post by James Forrester-4
GOn Wed, Nov 21, 2012 at 09:17:24AM -0800, James Forrester wrote:
> Those numbers are people using Windows XP, not people using Windows XP
> with IE. I believe the numbers for (XP && IE) are going to be
> substantially lower - probably half - but still far to high to
> discount.

Doh, my bad.

> However, you are right that Windows XP is likely to become the next
> barrier to proper Web development after IE6, and perhaps we should
> instead make an exception for IE compared to the other big four
> browsers and suggest supporting current, and two immediately-previous
> versions.

Well, I think with this exception you're trying to adjust the "latest
browser" rule to cover special cases, instead of acknowledging these
special cases for what they are.

e.g. if IE 11 comes out in 6 months while IE 8/Windows XP remains
prevalent, are we going to adjust the rule to say "three
immediately-previous versions"? What if Microsoft suddenly decides to
use the Chrome/Firefox versioning scheme?

The real reason is that you want Windows XP support, so you might just
as well put that in the rules, instead of extrapolating from the
browser's platform support.  Also, do note another thing from the other
sub-thread: SNI works on IE 8 on Vista or later, but not on IE 8 on
Windows XP, so the browser version rule won't work well in this case.

I think there is a more general flaw here, as also evident with the
Android exception. The problem is that you just can't drop support for
browsers that have a large market share, no matter when they were
released. I think that market share needs to be factored in in the
policy, or else we'll end up adding exceptions to the rules every time
our policy dictates that we're going to drop support for an older but
popular platform.

> Given that I suggested "I'd be happy to talk through the individual
> browser-level decisions but it might be easier to agree that we want
> to focus browser support before we decide the exact focus of this."
> I'm assuming this means you're happy with the overall policy and we're
> just bike-shedding over which versions of which browsers? ;-)

Well, it completely makes sense to me to have a supported browsers
policy, if that's what you're asking. On the other hand, I'm no
MediaWiki or web developer, so my view should be considered as such :)

Regards,
Faidon

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12