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&a… 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… 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. jforrester(a)wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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?

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

On Tue, Nov 20, 2012 at 5:19 PM, James Forrester &lt;jforrester(a)wikimedia.org&gt; 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

> browsers, and how we can match limited developer time to our natural

> 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

> of users (an extremely-expensive claim) - this was changed in > August<

> from > the 0.1% threshold you see around more often, or the 1% one that we

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

<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

> 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

> spend resources (read, developer time) on it. If a volunteer is willing

> work like hell to make, say, the VisualEditor work in Opera we would

> support them by reviewing/accepting patches, but nothing more than

> doesn't mean we would go out of our way to break previous browsers as

> leave support, but we would not hold ourselves back from useful

> 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

> team every now and then and can go further or less far than the main

> 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

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

> for > VisualEditor to identify the browser support that our team will be able

> provide. This is a table with ticks or crosses for support > of grouped browsers, gated at the 0.1% threshold (so browsers used by

> than 0.1% of our readers like IE 5.0 don't show up). This is now

> template which is as not-ugly as you can make it in wikitext[+]; I'm

> 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

> this list about this. Do you think this might work? Is "making sure all

> different parts of MediaWiki keep working with <browser I love>"

> you'd see yourself volunteering to do? > > I'd be happy to talk through the individual browser-level decisions but

> 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

> 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

-- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Tue, Nov 20, 2012 at 05:19:51PM -0800, James Forrester wrote: So, I think you're intermixing two different things: MediaWiki support and "WMF Engineering" or "cluster" browser support.

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.

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.

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?

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

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.

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? ;-)

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.

I am not opposed to having a flashy interface at all and did not assert anything like that. However, having flashy interfaces does not automatically mean that the user experience for users with older soft / hardware has to be bad. In many cases, it is actually pretty easy from a technical perspective to provide a reasonable experience for older browsers while still having flashy things where supported.

I fear that a binary browser policy would discourage people from keeping this in mind, and think that we can do better than that.

On 20 November 2012 23:54, Martijn Hoekstra &lt;martijnhoekstra(a)gmail.com&gt; wrote: 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. 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. jforrester(a)wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 20 November 2012 23:54, Martijn Hoekstra wrote: 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.

On 21/11/12 18:33, James Forrester wrote: Funnily, Firefox 17 was released yesterday. So the latest Firefox is in fact not shown in [[VisualEditor/2012-13_Q2_forward-look]] and I doubt anyone on this thread had it installed when it started. Which serves as a counterexample for the Brion statement of "nobody should be running Chrome 22". Which was released two months ago. I think that in addition to the some rule for the rapid release versions, like "plus all its versions released in the last year" would be needed. Does it seem too much? Well, a year ago we were at Firefox 9. But Firefox 10 is itself an Extended Support Release. Does this mean much more work? It depends. For common browsers, we could develop for the "new" and "old" versions. If it works for both, it is likely to work in all the releases inbetween, too. If the feature only works for some version (eg. suppose ContentEditable had been added on FF 12 [if was in fact FF 3]), it could be documented, and the feature supported just from that one onwards. We must support old browsers, to the point where a browser designed in the HTML4 days should provide an _acceptable_ experience. Yes, you wouldn't have fancy HTML5 video or . But that shouldn't mean that you couldn't rollback a certain vandalism with malformed wiktext because it completely broke your editor. We should have such a great-vision goal in mind. Then for «hard» features such as Visual Editor, we may need to be satisfied with much less, of course. The bad thing I see with saying "volunteers can add VE support for $SMALLBROWSER if they wish" is that only a few will be able to understand the code, much less to fix it. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

… which seems to be a little harsh on the mobile and tablet fronts, and overly- generous on the MSIE side given their exceptional costs to support per %age of users, but not too terrible.

Correction. I was looking at the total Other/Unknown. Opera is actually 4.66% --tomasz On Mon, Nov 26, 2012 at 11:00 AM, Tomasz Finc &lt;tfinc(a)wikimedia.org&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l