Browser Support and Testing

[Justin Obara]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20111118/dcef7ebb/attachment.htm>