+1 On 2012-01-27, at 5:59 PM, Michelle D'Souza wrote:
> I like this proposal too. +1 > > Michelle > > > > > On 2012-01-27, at 5:15 PM, Colin Clark wrote: > >> 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
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
