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 _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
