Browser Support and Testing

Fri Jan 27 22:15:03 UTC 2012

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