I think it's a reasonable proposal, and long overdue. +1
What do others think? Colin On 2012-01-27, at 11:13 AM, Justin Obara wrote: > Colin and I talked a bit more about this in the channel, and it led to a > revised proposal. > ( see: > http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2012-01-27 ) > > We could probably spend a while talking about browser support in detail, but > in a nut shell it covers the following: > > • we test with each supported browser > • we actively fix bugs which affect any of the supported browsers > • we will block a release on fatal bugs affecting any of the supported > browsers > > We've found in the past that we spent a substantial amount of time covering > those 3 points in older versions of IE, not to mention all of the extra lines > and complexity of code that is added. According to Microsoft, IE6 support is > down to 7.7% worldwide. In fact, outside of a few countries, the worldwide > usage is rather negligible. > > The new proposal would be to amend Colin's with dropping IE6 and IE7 support > completely. This is to clearly state that we do not actively support IE6 and > IE7 anymore. > > What this means. > > • IE6 and IE7 won't have browser support as defined above > • as we come across IE6 and IE7 specific code, it will be deprecated > and marked for clean up at a later date > • if an issue comes up in IE6 or IE7 we may fix it, but it will be > determined on a case by case basis > > Thanks > Justin > > On 2012-01-27, at 10:20 AM, Colin Clark wrote: > >> No, by "new components" I mean components that aren't already in the >> Infusion 1.4 release. Put another way, components that don't already support >> IE6/7. For Studios projects, I agree with you--no reason to put any >> limitations on browser support there. >> >> If you think segmenting will be confusing, can you suggest an alternative >> proposal? Sounds like you'll have to be a little bit more radical than I was. >> >> Colin >> >> On 2012-01-27, at 10:01 AM, Justin Obara wrote: >> >>> Hi Colin, >>> >>> Thanks for bringing this back and trying to clear it up. >>> >>> I have some questions about what is meant by "new components". Do you mean >>> components that aren't part of infusion, but are part of the Fluid Studios? >>> If this is the case, I think we should let the browser support be whatever >>> the active developers want it to be, but with the caveat that it should be >>> clearly laid out in a readme and could influence its ability to be brought >>> into Infusion. However, if you mean, new Infusion components, I think >>> segmenting support may be a bit confusing; both to us and our users. >>> >>> Thanks >>> Justin >>> >>> On 2012-01-26, at 7:34 PM, Colin Clark wrote: >>> >>>> Hi all, >>>> >>>> Infusion's browser support policy and the amount of work we're willing to >>>> put into supporting IE 6 came up again this evening in the fluid-work >>>> channel. The general impression was that our previous attempts to craft a >>>> proposal on this issue haven't been clear or definitive enough. >>>> >>>> So, in the spirit of clarity, here's another proposal for us to consider: >>>> >>>> 1. For new components (such as the Video Player), we will only develop, >>>> test, and support on IE8+ as well as our usual modern browsers (Safari, >>>> Chrome, Firefox). No testing, no coding, no guarantees that it will work >>>> on IE 6 or 7. >>>> >>>> 2. For stable, current components, we'll continue to support and test on >>>> IE 6 and 7. If major new features are planned for such a component, we may >>>> choose to move it to this more modern support policy as needed. >>>> >>>> 3. If users have a strong need for IE 6/7 support, and they are willing to >>>> lend a hand with testing and development, we'll do our best to try to add >>>> support for it. Undoubtedly this will be a collaborative effort. >>>> >>>> Likely, the biggest downside to this approach is that it doesn't address >>>> the cost of our QA testing surface in the short term. It should help a bit >>>> over the long run as IE 6/7 support slowly trickles off, but it certainly >>>> won't lower the time it will take us to test Infusion 1.5. I'd be quite >>>> supportive of alternative proposals that reduce our testing efforts on IE >>>> 6 and 7, too. >>>> >>>> Thoughts? >>>> >>>> Colin >>>> >>>> On 2011-11-18, at 11:45 AM, Justin Obara wrote: >>>> >>>>> Thanks for sending this out Michelle. >>>>> >>>>> I had been waiting for others to respond first, but I figured it was time >>>>> to push this up a bit. >>>>> >>>>> I'm not sure we fully decided what to do with older browsers. I know we >>>>> discussed the merits of a degraded version, but there were also concerns >>>>> about the complexity of trying to develop degraded versions of all our >>>>> components. >>>>> >>>>> Smashing magazine had an interesting article about IE support. >>>>> ( >>>>> http://www.smashingmagazine.com/2011/11/03/“but-the-client-wants-ie-6-support” >>>>> ) >>>>> It is really taken from the point of view of a freelance web developer, >>>>> so it's not fully applicable. However, there are some good points to >>>>> think about. Here's a snippet of the article talking about factors >>>>> affecting the extra development time. >>>>> • You >>>>> How modern are your development techniques? The more cutting-edge they >>>>> are, then the more effort you will need to put into making good fallbacks >>>>> or coming up with alternative techniques for old Internet Explorers (but >>>>> less effort to make the original prototype) >>>>> • The project >>>>> If it’s a brochure website, the main thing that will need extra effort in >>>>> order to work in old IEs is the styling. If it’s a Web application, it >>>>> gets way trickier (and more time-consuming). >>>>> • Level of support >>>>> Supporting a browser is not black and white, either no support or full >>>>> support. How good your fallbacks need to be will greatly determine how >>>>> much extra time you have to spend on them. >>>>> I think we need to assess each of our components based on these points. >>>>> Also what will it mean to our framework, can we simplify code for the >>>>> render, IoC, or other parts? If so, what would a degraded system look >>>>> like for that? >>>>> >>>>> I hoping that this isn't just rehashing old debates, but will spur on the >>>>> discussion of this important topic. >>>>> >>>>> Thanks >>>>> Justin >>>>> >>>>> On 2011-11-07, at 5:01 PM, Michelle D'Souza wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> At a recent community meeting, we talked about our browser support >>>>>> strategy for Infusion. I offered to share our conversation here so that >>>>>> we can come to consensus. >>>>>> >>>>>> We talked a little about the identity of Infusion, which is both forward >>>>>> looking and accommodating of many platforms and configurations. This >>>>>> requires a true balancing act considering all our possible users, along >>>>>> with a practicality regarding our limited resources. Since we build >>>>>> tools for other people to use in their websites and applications, we >>>>>> must be conscious of their users' requirements. We currently don't have >>>>>> an extensive list of people who are using Infusion and in fact it may >>>>>> not be feasible to gather such a list. >>>>>> >>>>>> We touched on several aspects of our current development process. This >>>>>> included the cost of QA particularly when we modify the framework or >>>>>> upgrade jQuery. It takes us about a week to complete a full QA cycle >>>>>> which ends up being a significant deterrent to making framework changes >>>>>> and doing frequent releases. We also talked about the amount of time we >>>>>> are spending on supporting older browsers. We estimate that at least a >>>>>> month of development time during 1.4 was spent on making UIO work in >>>>>> IE6. >>>>>> >>>>>> The final proposal we came to was two part: >>>>>> 1. We would stop trying to provide the same rich experience on all >>>>>> browsers and platforms. Instead, we would move to a simpler, stripped >>>>>> down experience on the older browsers. Practically speaking this will >>>>>> mean designing and implementing a simpler version which would of course >>>>>> also need to be tested during a QA cycle. >>>>>> >>>>>> 2. We would move to testing fewer combinations of browsers & >>>>>> platforms. Likely we would test the latest Firefox, latest Chrome, >>>>>> latest Safari, IE 8 and IE 9 on what ever OS the tester feels like >>>>>> testing. We would address issues that crop up in other browser and >>>>>> platform combinations when integrators or users find them. This strategy >>>>>> means that some amount of testing burden would fall on integrators that >>>>>> require a browser that we don't QA. >>>>>> >>>>>> Everyone, please comment on whether you'd support a move to this policy >>>>>> and those that were at the meeting please correct any mistakes I've made >>>>>> or add detail where it's needed. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Michelle >>>> >>>> --- >>>> Colin Clark >>>> Technical Lead, Fluid Project >>>> http://fluidproject.org >>>> >>> >> >> --- >> Colin Clark >> Technical Lead, Fluid Project >> http://fluidproject.org >> > --- Colin Clark Technical Lead, Fluid Project http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
