This position is even worse than the junior developer's, I hate developers with a 'You're doing it wrong because even I know how to do it' attitude. This guy's an accessibility developer , it's his job to know this shit.
First, he's delusional if you think you can learn Html, Css or Javascript in an afternoon. HTTP? Good luck reading through and understandinghttp://www.w3.org/Protocols/rfc2616/rfc2616.html in an afternoon.
I'd happily wager money that of a cross section of people who are employed as 'web developers' only a small percentage would know what a http response even looks like.
But the real killer is that he may work for companies who can increase their profits sufficiently by supporting IE6 that they can pay for all the extra mental effort involved in supporting IE6, but I don't.
I'm not doing it wrong by writing sites that aren't IE6 compatible. I'm deliberately deciding their business isn't worth the extra engineering or testing cost.
In the end Html5 is coming and people are starting to stop supporting IE6. We're already beginning to see the trickle of 'we don't support IE6' of major sites before the flood hits.
It's not poor engineering, it's just the future. I felt sorry for the junior web dev, he should have checked, but this guy's attitude is worse imo.
> I'm not doing it wrong by writing sites that aren't IE6 compatible. I'm deliberately deciding their business isn't worth the extra engineering or testing cost.
That was the whole point of the article. Don't drop IE6 support because all the cool kids say you should, or because yourfavouritewebsite.com has; actually look at your browser stats and other metrics and make an informed decision.
From the second paragraph in the article:
> The browser support of your website must be directly correlated with your target audience.
Browser support should be based on research and business realities, not developer whim.
Be careful about defining your target market as those people not using Internet Explorer 6. What is important is what browser they are using at the point they want to convert into being a customer. That doesn't necessarily mean IE6 is their main browser, just that that's the one they are using right then. As more and more people are perusing the web from home and work, typically from different hardware devices, there is a fairly good chance they are using more than one user-agent. So a Safari user is an IE6 user at a different point in the day.
With your chosen approach, no visitor can become a customer when they have IE6 as their browser. That means it doesn't really matter whether they use other supported browsers from other locations that you do happen to support. If they use IE6 when they are in the buy moment it won't be you benefitting.
> In the end Html5 is coming and people are starting to stop
> supporting IE6.
And everyone stopping support of IE6 needs to weigh up very carefully the business implications of that choice. Just like any other discriminatory measure.
> We're already beginning to see the trickle of 'we don't support IE6' of major
> sites before the flood hits.
Be careful, Google's approach for their core business service is very pragmatic - IE6 gets fully working core functionality, they lose some of the new features of Search. And I don't see them removing support for IE6 from their Ads platform.
Where they've forgone IE6 support is in sites that are not critical to their business: Google Apps, YouTube.
Facebook - well UK Government organisations are still celebrating Facebook's move (and YouTubes's). They have one effective firewall to stop their employees spending working time there. That's hardly going to convince them to upgrade, since losing that is nothing compared to the cost and effort required to switch browsers without losing their core systems.
Where I stand, rejecting a customer because they work for a government organisation isn't smart business.
This isn't about "web development discipline," it is a rant about how people should support IE6 cheerfully, with the idea that it is normatively incorrect not to support it.
Whether or not to support IE6 is reasonably a business decision based on your audience and resources for implementing. That balance shifts over time (note that we are not having this discussion about IE3, 4 or 5 any more).
If you need to support IE6 then yes, support it from the beginning. If you don't need to, then don't.
There is a valid role for advocacy and social pressure here, it is not writ from God that "thou shalt support IE6 even if it be costly with little benefit."
I think it's less the fact that the development process is undisciplined, and more the fact that it is just a bore to recode something beautiful for people who couldn't care less about it.
The point of the article is that if you're "recoding something" then you're not approaching cross-browser development in the right way. Dismissing IE users as "people who couldn't care less" and writing off proper cross-browser support because "it is just a bore" really doesn't (or shouldn't) have a place in professional web development.
I have worked as Head of Development at a 3-person agency, as a Senior Developer and Front-End Architect at Yahoo! and now as Web Architect at a medium-sized company. On all the sites I've worked on (with their varied budgets and development team sizes), dropping support for IE6 would have been putting our desires as developers ahead of those of the users who are still using that browser. In the end, supporting IE6 actually wasn't that hard; you just have to control what "support" means.
Yahoo!'s Graded Browser Support gets this right. Though it no longer explicitly categorises the browsers it lists into A- and C-Grade, those grades still exist. Rather than Yahoo! prescribing which browsers should get the full experience and which should get a core experience, they leave it up to you:
> The GBS focuses on specifying which browsers need a verified usable experience based on factors such as market share and influence. Defining what is “usable” and specifiying acceptable levels of degradation are left for teams to decide.
That's not to say the GBS is perfect. Using global browser market share may make sense for an international behemoth like Yahoo!, but you really should make your own decisions based on the browsers your users are actually using. Make sure you're looking at unique visitors rather than page hits though, because if a user comes to your homepage and sees an obviously broken layout they're not likely to hang around very long.
In short, supporting IE6 is actually easy if you can justify giving those users just a core experience (minus bells and whistles) and have a development team that knows what they're doing.
I guess I misunderstood the point of your article. Sure, if your IE6 user base is large enough, you pretty much have no way to get around providing support for that browser.
And I agree it is easier to test IE6 compatibility procedurally, after each coded page or measurable milestone, rather than at the very end of the website's development.
First, he's delusional if you think you can learn Html, Css or Javascript in an afternoon. HTTP? Good luck reading through and understanding http://www.w3.org/Protocols/rfc2616/rfc2616.html in an afternoon.
I'd happily wager money that of a cross section of people who are employed as 'web developers' only a small percentage would know what a http response even looks like.
But the real killer is that he may work for companies who can increase their profits sufficiently by supporting IE6 that they can pay for all the extra mental effort involved in supporting IE6, but I don't.
I'm not doing it wrong by writing sites that aren't IE6 compatible. I'm deliberately deciding their business isn't worth the extra engineering or testing cost.
In the end Html5 is coming and people are starting to stop supporting IE6. We're already beginning to see the trickle of 'we don't support IE6' of major sites before the flood hits.
It's not poor engineering, it's just the future. I felt sorry for the junior web dev, he should have checked, but this guy's attitude is worse imo.