Re: Should we come up with a browser support matrix?
I added a v1 of this to the wiki at https://wiki.jenkins-ci.org/display/JENKINS/Browser+Compatibility+Matrix Of course, feel free to make comments and edits :) -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
Great, thanks Tom. I just reworked the page a bit into a table to help make the information more quickly findable by readers. Hope this suits you and others. 2014-08-26 15:06 GMT+02:00 Tom Fennelly tom.fenne...@gmail.com: I added a v1 of this to the wiki at https://wiki.jenkins-ci.org/display/JENKINS/Browser+Compatibility+Matrix Of course, feel free to make comments and edits :) -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
On 26.08.2014, at 15:06, Tom Fennelly tom.fenne...@gmail.com wrote: I added a v1 of this to the wiki at https://wiki.jenkins-ci.org/display/JENKINS/Browser+Compatibility+Matrix Of course, feel free to make comments and edits :) Any particular reason you list Firefox ESR as L2? -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
That's great, thanks Baptiste. On Tuesday, August 26, 2014 2:26:18 PM UTC+1, Baptiste Mathus wrote: Great, thanks Tom. I just reworked the page a bit into a table to help make the information more quickly findable by readers. Hope this suits you and others. 2014-08-26 15:06 GMT+02:00 Tom Fennelly tom.fe...@gmail.com javascript: : I added a v1 of this to the wiki at https://wiki.jenkins-ci.org/display/JENKINS/Browser+Compatibility+Matrix Of course, feel free to make comments and edits :) -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;! -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
Good question... no reason other than being hasty. I'll update it and make it L1. In fact... is there a need to mention it specifically? On Tuesday, August 26, 2014 6:14:05 PM UTC+1, Daniel Beck wrote: On 26.08.2014, at 15:06, Tom Fennelly tom.fe...@gmail.com javascript: wrote: I added a v1 of this to the wiki at https://wiki.jenkins-ci.org/display/JENKINS/Browser+Compatibility+Matrix Of course, feel free to make comments and edits :) Any particular reason you list Firefox ESR as L2? -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
On 26.08.2014, at 19:39, Tom Fennelly tom.fenne...@gmail.com wrote: Good question... no reason other than being hasty. I'll update it and make it L1. In fact... is there a need to mention it specifically? Well, it's outdated by ~3 months on average compared to the latest, so telling people we try to be compatible is significant enough to mention IMO if we actually aim to support it. I have no idea how widely used it is though. BTW I restructured the page a bit as well, removing L3 and unspecified browsers (Opera and mobile) from the table, as that was redundant. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
On 07.08.2014, at 22:36, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I think what we are after is 3 tiers: - first class UX (we should aim to proactively fix these browsers and provide an equal UX across all) - UI testing failures here are considered major UI bugs - best effort UX (we will accept patches to fix issues and attempt to ensure there is at least one way to do any action with these browsers) - UI testing failures here are only considered major bugs if they completely block functionality, if the UX degrades but remains functional or if there is another way to do it, then it's a minor bug - no guarantees - no UI testing - UI bugs closed as will not fix So IE 11 should be first class, say IE 8 or 9 is best effort and IE 7 and below is no guarantees This looks like a good approach. Except maybe still accept patches for 'no guarantees', if it's simple enough and doesn't impact supported browsers, with no commitment to keep them working. Given Microsoft's recent announcement[1] and negligible Vista market share[2], we should be able to drop IE8+9 from 'best effort' sooner rather than later. Suggestions for first class UX in other browsers (in case this is ever relevant): * For regular Chrome and Firefox, working in the latest major release should be enough: It'll take changes ~2 weeks (for regular releases) to at least ~8 weeks (LTS) to reach users, which should be enough to update the browser to its latest greatest. * Firefox ESR support shouldn't be too much effort, given they're never older than ~1 year (Firefox 24 ESR was released September 2013 and is currently being replaced by Firefox 31 ESR). * 90+% of OS X users seem to be able[3] to have at least Safari 6.1[4] * No support for alpha/beta/canary releases. Make this explicit. What about Android, iOS, Windows Phone? 1: http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx 2: https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Desktop_and_laptop_computers 3: http://update.omnigroup.com/ Overall » Major Version 4: https://en.wikipedia.org/wiki/Safari_%28web_browser%29#Safari_7 -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
Right, I think this is a good approach + the caveats Daniel suggests. I think the policy around accepting patches should be along the lines of the level of guarantee we plan to offer e.g. for no guarantee on support we also offer no guarantee re accepting patches i.e. if we can reasonably accept the patch we will (no/low effort and risk etc), otherwise sorry. I'll create a wiki page based on this and we can start filling it in. I think maybe part of this will depend on the support matrix of some of the framework's Jenkins ui currently depends on e.g. YUI. On Saturday, August 9, 2014 11:09:31 AM UTC+1, Daniel Beck wrote: On 07.08.2014, at 22:36, Stephen Connolly stephen.al...@gmail.com javascript: wrote: I think what we are after is 3 tiers: - first class UX (we should aim to proactively fix these browsers and provide an equal UX across all) - UI testing failures here are considered major UI bugs - best effort UX (we will accept patches to fix issues and attempt to ensure there is at least one way to do any action with these browsers) - UI testing failures here are only considered major bugs if they completely block functionality, if the UX degrades but remains functional or if there is another way to do it, then it's a minor bug - no guarantees - no UI testing - UI bugs closed as will not fix So IE 11 should be first class, say IE 8 or 9 is best effort and IE 7 and below is no guarantees This looks like a good approach. Except maybe still accept patches for 'no guarantees', if it's simple enough and doesn't impact supported browsers, with no commitment to keep them working. Given Microsoft's recent announcement[1] and negligible Vista market share[2], we should be able to drop IE8+9 from 'best effort' sooner rather than later. Suggestions for first class UX in other browsers (in case this is ever relevant): * For regular Chrome and Firefox, working in the latest major release should be enough: It'll take changes ~2 weeks (for regular releases) to at least ~8 weeks (LTS) to reach users, which should be enough to update the browser to its latest greatest. * Firefox ESR support shouldn't be too much effort, given they're never older than ~1 year (Firefox 24 ESR was released September 2013 and is currently being replaced by Firefox 31 ESR). * 90+% of OS X users seem to be able[3] to have at least Safari 6.1[4] * No support for alpha/beta/canary releases. Make this explicit. What about Android, iOS, Windows Phone? 1: http://blogs.msdn.com/b/ie/archive/2014/08/07/stay-up-to-date-with-internet-explorer.aspx 2: https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Desktop_and_laptop_computers 3: http://update.omnigroup.com/ Overall » Major Version 4: https://en.wikipedia.org/wiki/Safari_%28web_browser%29#Safari_7 -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
It would be best to try to degrade gracefully on older or less functional browsers. If the page looks ugly, fine. If some JavaScript tricks do not work, fine, so long as there is some other way to accomplish the same task. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
On Thursday, 7 August 2014, Jesse Glick jgl...@cloudbees.com wrote: It would be best to try to degrade gracefully on older or less functional browsers. If the page looks ugly, fine. If some JavaScript tricks do not work, fine, so long as there is some other way to accomplish the same task. I think what we are after is 3 tiers: - first class UX (we should aim to proactively fix these browsers and provide an equal UX across all) - UI testing failures here are considered major UI bugs - best effort UX (we will accept patches to fix issues and attempt to ensure there is at least one way to do any action with these browsers) - UI testing failures here are only considered major bugs if they completely block functionality, if the UX degrades but remains functional or if there is another way to do it, then it's a minor bug - no guarantees - no UI testing - UI bugs closed as will not fix So IE 11 should be first class, say IE 8 or 9 is best effort and IE 7 and below is no guarantees -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com javascript:;. For more options, visit https://groups.google.com/d/optout. -- Sent from my phone -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
From a tools perspective I have always found browserling to be very useful. Free and open source On Aug 7, 2014 1:36 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Thursday, 7 August 2014, Jesse Glick jgl...@cloudbees.com wrote: It would be best to try to degrade gracefully on older or less functional browsers. If the page looks ugly, fine. If some JavaScript tricks do not work, fine, so long as there is some other way to accomplish the same task. I think what we are after is 3 tiers: - first class UX (we should aim to proactively fix these browsers and provide an equal UX across all) - UI testing failures here are considered major UI bugs - best effort UX (we will accept patches to fix issues and attempt to ensure there is at least one way to do any action with these browsers) - UI testing failures here are only considered major bugs if they completely block functionality, if the UX degrades but remains functional or if there is another way to do it, then it's a minor bug - no guarantees - no UI testing - UI bugs closed as will not fix So IE 11 should be first class, say IE 8 or 9 is best effort and IE 7 and below is no guarantees -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Sent from my phone -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
Hi Emeric. Thanks for the response. +1 to everything you said there. On Friday, August 1, 2014 9:37:54 AM UTC+1, evernat wrote: Hi Tom, In my opinion, we should not try to support IE8 in UI refresh, because it would be foolish for a user to still use IE8 even on WinXP. Perhaps some slow companies still pretend that IE8 is their mandatory browser [1] (and never respect that themselves). But in my opinion, your UI refresh should not be blocked or slowed down by the mandate of these slow companies, for which they just need to acknowledge a better mandate or exemptions. [1] https://issues.jenkins-ci.org/browse/JENKINS-14749?focusedCommentId=198375page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-198375 Emeric Le jeudi 31 juillet 2014 14:26:05 UTC+2, Tom Fennelly a écrit : In particular... how far back do we want to support Internet Explorer. I think IE9 for sure, but what about IE8? It's a real PITA :) -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
+1 The browser support matrix would be great. In addition to IE, it will allow to limit the fun with custom browsers. Firefox, Chrome, Safari and IE would be enough. Unfortunately, many plugins have their own browser compatibility issues (especially with IE11). It could be useful to somehow store and publish this information (e.g. via pom.xml properties) Perhaps some slow companies still pretend that IE8 is their mandatory browser (and never respect that themselves) My company uses IE8 (and I also know companies with IE6 X_X), but I also vote to increase the minimal supported version to IE9 or even IE10. Actually, the IE8's JavaScript interpreter performance kills the Jenkins user experience in any case. Best regards, Oleg Nenashev среда, 6 августа 2014 г., 0:53:10 UTC+4 пользователь Tom Fennelly написал: Hi Emeric. Thanks for the response. +1 to everything you said there. On Friday, August 1, 2014 9:37:54 AM UTC+1, evernat wrote: Hi Tom, In my opinion, we should not try to support IE8 in UI refresh, because it would be foolish for a user to still use IE8 even on WinXP. Perhaps some slow companies still pretend that IE8 is their mandatory browser [1] (and never respect that themselves). But in my opinion, your UI refresh should not be blocked or slowed down by the mandate of these slow companies, for which they just need to acknowledge a better mandate or exemptions. [1] https://issues.jenkins-ci.org/browse/JENKINS-14749?focusedCommentId=198375page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-198375 Emeric Le jeudi 31 juillet 2014 14:26:05 UTC+2, Tom Fennelly a écrit : In particular... how far back do we want to support Internet Explorer. I think IE9 for sure, but what about IE8? It's a real PITA :) -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Should we come up with a browser support matrix?
Hi Tom, In my opinion, we should not try to support IE8 in UI refresh, because it would be foolish for a user to still use IE8 even on WinXP. Perhaps some slow companies still pretend that IE8 is their mandatory browser [1] (and never respect that themselves). But in my opinion, your UI refresh should not be blocked or slowed down by the mandate of these slow companies, for which they just need to acknowledge a better mandate or exemptions. [1] https://issues.jenkins-ci.org/browse/JENKINS-14749?focusedCommentId=198375page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-198375 Emeric Le jeudi 31 juillet 2014 14:26:05 UTC+2, Tom Fennelly a écrit : In particular... how far back do we want to support Internet Explorer. I think IE9 for sure, but what about IE8? It's a real PITA :) -- You received this message because you are subscribed to the Google Groups Jenkins Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
