That works fine for your blog, but what percentage of customers are you willing to turn away from your web business?
Everyone keeps saying that, but I have never ever seen numbers to back it up.
Letting it all blow up in the user's face is not an option to me. And I do business with publicity agencies, they don't give a fuck about this stuff, as far as they know everyone owns the latest macbook.
Now we have segmentation in experience, help documentation, and support.
It's expensive as fuck.
1) 90% of our visual front-end bugs come from IE, sometimes only showing up in certain versions of IE7.
2) Our mac developers either need a license for VMware fusion or multiple boxes/VMs to test IE 7/8/9 which of course behave very differently. Maintaining these boxes, Windows licenses, and VMware licenses adds additional stress to IT, and the context switching for our developers is expensive.
3) For the ones that do run a VM, we've had to upgrade their RAM so they could run the app and the VM at the same time. RAM is cheap, but its still money for each new mac-based frontend developer we have.
4) A lot of our distributed application message passing is actually done through the browser via client-side javascript. This makes it even more of a pain to test since automating this is difficult and expensive (more setup code, and capybara tests), and needs to be run in each supported browser.
The point is - even that solution costs time and money.
Is there anywhere it fails to meet your teams needs? Genuinely curious if it's a product fail or a marketing problem.
Disclaimer: Used to work at Sauce Labs, not anymore.
(And your internal network is all wifi? Seriously? With designers shuffling big files around? Then you have bigger problems)
2) As others have said, there are "free" (of course, there's a cost in setting up) alternatives.
3) Indeed, we bumped every iMac RAM here as well. It's very cheap, though.
4) Well, not really. Any logical piece of software can (and should) be isolated to run by itself. That's how you unit test them. This is the kind of thing that you build once, test everywhere and stop worrying about it until you have to change the set of features.
My point is: why don't we all serve a lo-fi version of our apps based on the features present in the current agent? This way we can stop worrying about release numbers once and for all. If nothing, it usually result in a more stable code base.
2) Nothing is free if you are buying more hardware. Considering the costs of supporting Chrome/Firefox are very incremental, doing anything other than running the browser natively increases time and cost.
3) Cheap yes, but you have to do it, and its not like buying one piece of hardware. You have to do it for every person. Better, but not great. No one likes running VMs on their boxes because it still crawls, even with 2 cores and 8GB ram.
4) Don't disagree with you at all. I was against this design decision from the beginning but lost that battle. It doesn't change the fact that we need to test all of it.
2) The hardware issue was addressed in 3. Also, I don't follow, what do you mean by "the costs of supporting Chrome/Firefox are very incremental?"
3) That's a fallacy, actually. You're both proposing and confirming that "No one likes running VMs on their boxes because it still crawls". I, for one, run Windows XP VMs on my 4GB Core i3 iMac with no burden on the host OS at all. Some people might suffer with it? Yes, but some people could try tuning their setup for their needs.
4) Agreed.
Anyhow, we both know that the kernel of your argument is the first topic. I could convince you that the benefits outweigh the costs in 2, 3 and 4. But if your mindset is focused on giving the very same experience to every agent that can reach your app, or giving no experience at all; this argument is already over.
Also, saying that Apple does X or Y means absolutely nothing. Even if your company were almost exactly the same as Apple in every competitive aspect, nothing can assure that copying its culture would also lead you to a successful path. Actually, I believe history tells us the opposite.
Chrome frame takes about 30-45 sec to DL & install. Doesn't require a browser restart and doesn't require admin rights. Its incredibly slick. and then you're free to work with HTML5 and CSS3 in ie6+
So they're stuck with IE6, because that was the latest & greatest when large custom web-based applications really took off, so they're all certified for IE6 only and would have to be replaced at enormous cost before the users can be allowed to upgrade (or install chromeframe, for example).
It's a big barrier.
No, that isn't that difficult.
Try to do an interactive webap.
Or they'll go with your competitor.
Obviously, if your users are all home users, this probably isn't a factor. If you want people using your site from the office, it might be.
Where I work, we support browsers with over 2% of traffic, which means IE7,8,9, Chrome (latest), FF (latest and possibly 3.6 or something like that) and Safari (latest, IIRC, possibly latest + 1 older version.) The last 4 are largely the same, except for small bugs, and minor visual degradation is fine for the IEs. If your work requires you to support every browser, maybe you should start trying to build a case against that by making clear that requiring you to support every browser is a poor business decision.
But at some point, it becomes a zero-sum game. I believe this is what is happening with jquery: the amount of effort to support new features on older browsers (yes, that includes IE8) becomes less and less of an advantage. Hence their decision to compromise and support two versions of jquery, and have all or most of the new features implemented in the 2.0 version.
OK, make your new website work in Netscape 4.
Now many of the things I do involve Canvas and SVG for information display. Try a map of the United States with a few layers of SVG with a few thousand datapoints. It simply won't happen on IE <= 9. You can try all the shims all day long. It just won't work.
Saying "it's not that hard" means you haven't tried anything more than CSS2 box model stuff.