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
