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 MWwikihttps://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 Augusthttps://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 matrixhttps://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.
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" jforrester@wikimedia.org 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 MWwikihttps://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&am...
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@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Nov 20, 2012 at 5:19 PM, James Forrester jforrester@wikimedia.orgwrote:
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
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
On 20 November 2012 20:00, Faidon Liambotis faidon@wikimedia.org 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.
jforrester@wikimedia.org | @jdforrester
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
On 21 November 2012 11:54, Faidon Liambotis faidon@wikimedia.org wrote:
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 know; forgive my terseness.
It's a defendable line to say "if you want to keep using Windows XP, you can't use IE to do more than basic use (e.g., HTTPS will not work); if you want more, use a different browser or different OS". I don't think it's appropriate now if it's 10% of all users, but in a year? Maybe. But this isn't my call to make alone, and is more appropriate for Platform and Ops. :-)
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.
The "policy" is to have a list of browsers that we target. If we decide the list is longer than I originally proposed, that's fine. The idea is to have an agreed point where we say "sorry, but we can't justify spending donor funds on fixing the problems with your browser", instead of the current problem of trying to make do with ad-hoc decisions.
J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
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_fo...
On 20 November 2012 19:53, Faidon Liambotis faidon@wikimedia.org 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.
jforrester@wikimedia.org | @jdforrester
On Tue, Nov 20, 2012 at 5:19 PM, James Forrester jforrester@wikimedia.orgwrote:
*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.
On Tue, Nov 20, 2012 at 5:19 PM, James Forrester jforrester@wikimedia.org 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 MWwikihttps://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 Augusthttps://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 matrixhttps://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.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Nov 21, 2012 7:13 AM, "Leslie Carr" lcarr@wikimedia.org wrote:
On Tue, Nov 20, 2012 at 5:19 PM, James Forrester jforrester@wikimedia.org 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 MWwikihttps://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&am...
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_...
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@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 20 November 2012 23:54, Martijn Hoekstra martijnhoekstra@gmail.com 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.
jforrester@wikimedia.org | @jdforrester
On Wed, Nov 21, 2012 at 9:33 AM, James Forrester jforrester@wikimedia.org wrote:
On 20 November 2012 23:54, Martijn Hoekstra martijnhoekstra@gmail.com 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.
I think this sounds like a great compromise (perhaps even with m = 2 ?)
Leslie
J.
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
If I want to do things on Wikipedia from Lynx [0] I should be able to do as much as Lynx supports, not less because my useragent doesn't match something that we support.
Also if we cut lynx support Jidini will come and kill us in our sleep. Dead developers = productivity loss ;)
----- On a serious note, I agree with what others have said about making sure that there is a link that you can click and get to an edit form that will submit on essentially all browsers is not hard and something that should always work. More fancy features don't need to work on all browsers. Personally doing something like support last two latest versions of browser X doesn't really make sense to me. We should support what people use. If no one uses latest and greatest browser X, we shouldn't bother with it. If (a significant number of) people are still using firefox 3.5 for some unknown reason, we should still support it. Thus I think we should stick to using percentages, perhaps with varying levels of support for different percentages. I'm really unclear on what benefit we would get from declaring a list of supported browsers [that are somewhat unrelated to viewership percentages] instead of directly looking at the user-agent statistics.
-bawolff
On 21/11/12 18:33, James Forrester wrote:
On 20 November 2012 23:54, Martijn Hoekstra 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.
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.
<slightly ot>
Actually … I had firefox 17 months ago. And I'm up to release 20 now.
Mozilla pushes their pre-beta (dubbed "aurora" - generally 2 releases forward) at [0] , and their nightly build (funnily enough, dubbed "nightly" - generally 4 releases forward) at [1]. They're less stable, but aurora is generally feature complete an can be used for testing.
Matthew Bowker http://en.wikipedia.org/wiki/User:Matthewrbowker
[0] https://www.mozilla.org/en-US/firefox/aurora/ [1] http://nightly.mozilla.org/
On Nov 21, 2012, at 3:56 PM, Platonides platonides@gmail.com wrote:
On 21/11/12 18:33, James Forrester wrote:
On 20 November 2012 23:54, Martijn Hoekstra 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.
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 20 November 2012 22:12, Leslie Carr lcarr@wikimedia.org 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?timef...
J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
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
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...
On 21 November 2012 09:32, Isarra Yos zhorishna@gmail.com 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.
jforrester@wikimedia.org | @jdforrester
2012/11/21 James Forrester jforrester@wikimedia.org:
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?
I'm going to assume Isarra was talking about Opera, since it's the only good and at least slightly popular one that was left out. (It's also probably the least resource-intensive one for old computers.)
I'm a Opera user myself and I love it. I can't really offer fixing *all* the bugs on the MediaWiki–Opera border due to my limited time, but I'd like to ask to be CC'd on them :) In my experience, most of "Opera bugs" has been sloppy JS coding that just happened to work in other browsers, although it does have its own share of troubles. Still, I see no reason for making it a second-class citizen – if there is actually one, I'd greatly appreciate links to any writeups on the topic :)
(An example of the sloppy coding: removing all options in a <select> box on focus and repopulating it. Works on Firefox and Chrome, doesn't work on Opera, as the emptied <select> loses the focus, rendering the items unselectable. This is present in the wikEd gadget, I didn't have time nor incentive to report and fix it yet, especially since it blocks Opera entirely by default...)
-- Matma Rex
On 21 November 2012 07:41, Quim Gil qgil@wikimedia.org 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.
jforrester@wikimedia.org | @jdforrester
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
On Wed, Nov 21, 2012 at 10:25 AM, Gabriel Wicke gwicke@wikimedia.orgwrote:
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
On 11/21/2012 11:33 AM, Steven Walling wrote:
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.
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.
Throwing in my 10 cents on the matter.
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.
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 agree with this. And I think that gracefully degrading should be the policy wherever possible. If I want to do things on Wikipedia from Lynx [0] I should be able to do as much as Lynx supports, not less because my useragent doesn't match something that we support.
I fear that a binary browser policy would discourage people from keeping this in mind, and think that we can do better than that.
/\ This. I also agree with this 100%.
It could be fairly easily solved though by simply mentioning that the intention of the policy is not to discourage people from making gracefully degrading interfaces. That would solve the problem of people pulling out that policy and pointing to it as a reason for why their stuff doesn't at least semi-work.
On the topic of which browsers to include, I recommend against having a hard list (Firefox, Chrome, IE, etc.). I think it would be preferable to use percentages, but keep a list of what browsers meet that criteria at any given time (preferably automatically updated). I think a static list of browser, while correct and relevant now, may not be 5 years down the line. Although everyone at the WMF and who volunteers with the WMF is a lot better about updating outdated policies than almost anywhere else I have ever seen, we all know that we have our fair share of outdated policies and documentation.
Anyhow, that's where I stand at least.
Thank you, Derric Atzrott Computer Specialist Alizee Pathology
Whether it be a targeted list of browsers, a list of browsers we explicitly ignore, or something else entirely, anything that helps us balance engineering resources is a good thing.
In 2010 I suggested a rule, which became somewhat of a policy, that WMF won't spend time/money supporting browsers that have 0.1% market share or less based on our own stats[1] for reading and editing Wikitext source code in a textarea. Other kinds of features, such as extra editing features or, in the case of my current project, using the VisualEditor can have higher thresholds, and these thresholds will be set based on whatever the team sees as a balance between supporting as many users as possible and making enough progress to get things out the door at a reasonable pace.
The most important distinction here is that there are different levels of support based on the feature being considered. This is known as progressive enhancement, it's a very common technique, and we use it all the time with success. Currently we depend on our jquery.client module to black-list certain browsers with known compatibility issues. This allows new browsers, or ones we haven't tested with yet, to not be shut out just because we didn't explicitly give them the OK. I believe that this is an effective way to be friendly to the future, while also resolving known compatibility problems.
Bottom line:
1. Doing whatever it takes to make all features work in all browsers means spending 90% of our money on 10% of our users. - Spending 90% of our money on 10% of our users is a waste of donated money. - Wasting donated money is unethical. - Even if it were 80% of our money for 20% of our users, it's still out of balance. 2. Only spending money on engineering projects that will easily work for 100% of our users will severely limit what we can do. - Severe limitations on what we can do will make our user experience inferior to the rest of the web. - An inferior user experience will reduce the number of users we have. - Even if this only costs us 10% of our users, we've just lost the same number of people, but now our software sucks. 3. Balancing compatibility with better features will result in a better user experience. - A better user experience will increase the number of users we have. - This can easily offset the users we lost because they are still using IE 5.5 on Windows 2000.
- Trevor
[1] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
On Wed, Nov 21, 2012 at 12:19 PM, Gabriel Wicke gwicke@wikimedia.orgwrote:
On 11/21/2012 11:33 AM, Steven Walling wrote:
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.
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.
-- Gabriel Wicke Senior Software Developer Wikimedia Foundation
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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).
2012/11/21 James Forrester jforrester@wikimedia.org:
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
May I please remind you of the fact that many Mac users are running older systems until they stop working without updating their system? I for one will keep running my MacBook with Mac OS X 10.6.8 with Safari 5.1. In TeX development we have received complaints from Mac users running desktop systems no longer supported by MacTeX which currently supports system 10.5 and later. So supporting the current and immediately-previous versions of Safari may not be sufficient. Those users also usually cannot switch to current versions of Chrome or Firefox because they need too much memory.
Regards, Jürgen.
On 20 November 2012 17:19, James Forrester jforrester@wikimedia.org wrote:
TL;DR: We're proposing a more formal, but more limited, statement of browser 'support' for the cluster; thoughts appreciated.
To clarify this a little more, as I think a little of the nuance has been getting lost in the discussion:
* We currently don't focus our work on making MediaWiki, and in particular the Wikimedia cluster, work with browsers very well. This means we spend time or other resources on things we don't need, and not on areas that need more attention.
* This is a proposal to bring in a new level of work above our current efforts, called "support". This level would involve WMF Engineering spending donor funds until we have 100% of the functionality of everything we do, unless that area (e.g. the VisualEditor, or PediaPress) has a local policy.
* This is a very high commitment for any organisation, and particularly high for one which funded by charitable giving, and so can only be applied sparingly.
* Just because a browser is not in the "support" list does not mean that it will suddenly stop working, or that WMF Engineering will not test it to ensure that it continues to work. In fact, under this policy we would commit to only deliberately breaking functionality with a proper justification, and providing new functionality as "progressive enhancements" wherever possible.
* I said that "[e]ach piece of feature development and platform work would explicitly say whether it was to inherit this top-level policy or chose its own", which was because I felt that it wasn't my place to dictate how other parts of WMF Engineering choses to spend their resources. That said, I think it's very likely that Platform's work on basic writing (load, render, edit and save the wikitext edit form) might target at the 0.1% level, and reading (as I said, "article-namespace reading, history viewing and diffing") would target even below this 0.1%.
* However, this policy does mean that some people's currently-favoured browser set-ups will be unsupported, and at some point might cease to work. Though a pain, this is not the end of the world; there are normally simple work-arounds (e.g. switching browser) rather than more complex ones (like switching their Operating System). Is this perfect? No, but what is?
As a way forward, to steal Martijn's idea and put the numbers in:
| WMF Enginering will support all versions released in the past 6 months of | those browser products with 4% or more overall market share, and any one | browser version with more than 2%
However, this would mean (as of 23.11.2012):
Desktop: Chrome 23 - 20 Firefox 16 - 13 MSIE 10 and 9 - 7 (own merits) Safari (latest version only) Opera 12.02 (own merits)
Tablet Safari (latest version only) Android (latest version only)
Mobile Safari (latest version only) Android 4 and 2.3 (own merits)
… 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.
(Note that I tweaked the input numbers from the suggestion so that they included Android, which is 'just' 4.25%, and they ignore lots of older versions of Chrome and Firefox with less than 0.5% useage.)
If this works for people, I'll put it up on MediaWiki.org and start helping colleagues to plan and justify their own local support matrices next week.
J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
On Fri, Nov 23, 2012 at 12:50 PM, James Forrester jforrester@wikimedia.orgwrote:
… 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.
I worry less about it being harsh and more that it needs to be lined up with which documents the mobile teams current support matrix [1].
Removing Opera support as a general rule is not an option for us as it contributes a significant amount of readership traffic (6.69%) [2] .
--tomasz
[1] - http://www.mediawiki.org/wiki/Mobile/Testing_process [2] - http://stats.wikimedia.org/wikimedia/squids/SquidReportDevices.htm
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 tfinc@wikimedia.org wrote:
On Fri, Nov 23, 2012 at 12:50 PM, James Forrester < jforrester@wikimedia.org> wrote:
… 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.
I worry less about it being harsh and more that it needs to be lined up with which documents the mobile teams current support matrix [1].
Removing Opera support as a general rule is not an option for us as it contributes a significant amount of readership traffic (6.69%) [2] .
--tomasz
[1] - http://www.mediawiki.org/wiki/Mobile/Testing_process [2] - http://stats.wikimedia.org/wikimedia/squids/SquidReportDevices.htm
Something that seems to be being partially considered in these models is browser shares that are growing or shrinking.
For instance it would make more sense to me to "support" IE10 than IE7 even if IE7 has a far greater market share this month. If significant work is needed for IE7, it might have dropped below an age or market share threshold before that work is complete.
By the same logic, it seems fair that mobile browsers make the list on a lower raw market share given that that market is likely to continue to grow for some time.
Putting those rules (particularly for IE) into unambiguous, fair, numeric cutoffs may be hard. Predicting future IE market share depends a great deal on the vagaries of auto update policies and corporate IT departments. For instance Windows XP users are stuck on IE8 forever and there are probably quite a lot of them in corporate America.
Luke Welling
On Mon, Nov 26, 2012 at 2:53 PM, Tomasz Finc tfinc@wikimedia.org wrote:
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 tfinc@wikimedia.org wrote:
On Fri, Nov 23, 2012 at 12:50 PM, James Forrester < jforrester@wikimedia.org> wrote:
… 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.
I worry less about it being harsh and more that it needs to be lined up with which documents the mobile teams current support matrix [1].
Removing Opera support as a general rule is not an option for us as it contributes a significant amount of readership traffic (6.69%) [2] .
--tomasz
[1] - http://www.mediawiki.org/wiki/Mobile/Testing_process [2] - http://stats.wikimedia.org/wikimedia/squids/SquidReportDevices.htm
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Nov 26, 2012 9:17 PM, "Luke Welling" <lwelling lwelling@wikimedia.org@lwelling@wikimedia.org wikimedia.org lwelling@wikimedia.org> wrote:
Something that seems to be being partially considered in these models is browser shares that are growing or shrinking.
For instance it would make more sense to me to "support" IE10 than IE7 even if IE7 has a far greater market share this month. If significant work is needed for IE7, it might have dropped below an age or market share threshold before that work is complete.
Under this scheme both would be supported.
By the same logic, it seems fair that mobile browsers make the list on a lower raw market share given that that market is likely to continue to grow for some time.
Putting those rules (particularly for IE) into unambiguous, fair, numeric cutoffs may be hard. Predicting future IE market share depends a great deal on the vagaries of auto update policies and corporate IT departments. For instance Windows XP users are stuck on IE8 forever and there are probably quite a lot of them in corporate America.
As long as IE8 stays over 2% market share (view share, edit share), it would be supported under this proposal.
I've been thinking about this scheme for a bit now, and I'm starting to see deficiencies. IMO, for most mobile devices, it makes a lot of sense to support consuming MediaWiki, but not producing content. Now this could change in the near future, but currently, editing from my cellphone is just hell, and that probably has more to do with the android/cellphone technology stack (large text areas are impossible to work with on Android browser) than with the MediaWiki stack. We can try all we want to make it a full experience, but the technology simply isn't up to the goal.
Similarly, I could understand not supporting some cosmetic features for IE7, as they might in some cases just be too expensive for too little gain.
Luke Welling
On Mon, Nov 26, 2012 at 2:53 PM, Tomasz Finc <tfinc tfinc@wikimedia.org@tfinc@wikimedia.org
wikimedia.org tfinc@wikimedia.org> wrote:
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 <tfinctfinc@wikimedia.org
@ tfinc@wikimedia.orgwikimedia.org tfinc@wikimedia.org> wrote:
On Fri, Nov 23, 2012 at 12:50 PM, James Forrester < jforrester jforrester@wikimedia.org@ jforrester@wikimedia.org
wikimedia.org jforrester@wikimedia.org> wrote:
… 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.
I worry less about it being harsh and more that it needs to be lined up with which documents the mobile teams current support matrix [1].
Removing Opera support as a general rule is not an option for us as it contributes a significant amount of readership traffic (6.69%) [2] .
--tomasz
[1] - http:// http://www.mediawiki.org/wiki/Mobile/Testing_process
www.mediawiki.org http://www.mediawiki.org/wiki/Mobile/Testing_process /wiki/Mobile/ http://www.mediawiki.org/wiki/Mobile/Testing_process Testing_process http://www.mediawiki.org/wiki/Mobile/Testing_process
[2] - http://http://stats.wikimedia.org/wikimedia/squids/SquidReportDevices.htm
stats.wikimedia.orghttp://stats.wikimedia.org/wikimedia/squids/SquidReportDevices.htm /wikimedia/squids/http://stats.wikimedia.org/wikimedia/squids/SquidReportDevices.htm SquidReportDevices.htmhttp://stats.wikimedia.org/wikimedia/squids/SquidReportDevices.htm
Wikitech-l mailing list Wikitech Wikitech-l@lists.wikimedia.org-l@Wikitech-l@lists.wikimedia.org
lists.wikimedia.org Wikitech-l@lists.wikimedia.org
https:// https://lists.wikimedia.org/mailman/listinfo/wikitech-l
lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikitech-l /mailman/ https://lists.wikimedia.org/mailman/listinfo/wikitech-llistinfohttps://lists.wikimedia.org/mailman/listinfo/wikitech-l / https://lists.wikimedia.org/mailman/listinfo/wikitech-lwikitechhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l -l https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech Wikitech-l@lists.wikimedia.org-l@Wikitech-l@lists.wikimedia.org
lists.wikimedia.org Wikitech-l@lists.wikimedia.org
https:// https://lists.wikimedia.org/mailman/listinfo/wikitech-l
lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikitech-l /mailman/ https://lists.wikimedia.org/mailman/listinfo/wikitech-llistinfohttps://lists.wikimedia.org/mailman/listinfo/wikitech-l / https://lists.wikimedia.org/mailman/listinfo/wikitech-lwikitechhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l -l https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org