I hate to be the detractor here, because getting rid of IE6 would be great for everyone, but do we really expect discontinuing Google Docs and Google Sites to have any effect on IE6 market share? They're mostly corporate users, which means they're probably using MS Office (and have a web team or contractor) anyway.
I recall reading an article a few months back that MS has begun their own campaign to get IE6 users upgraded (to IE8 of course). This is really not a big blow to Microsoft.
I noticed that when I open IE6 for testing (using iesforlinux actually), about 1/3 of the time it redirects to an IE8 download page, rather than showing the home page I have set in the options.
Also, some of MS's own pages on bing/live throw scripting errors in IE6! If they're not paying attention to IE6, I hope that means I don't have to any more, either.
I would agree. I never saw so many bad things happen when my
friends upgraded to IE6. It wasn't that IE6 was bad it's just a lot of things security wise came to a head at the same time
and IE6 was sitting in it's path.
'We hear that Google will be phasing out IE6 support for the remainder of Google’s major products, including Gmail and Calendar, over the coming year.'
That be would twisting a knife - and I would love to see it happen. Pulling support for some new features in Docs/Sites isn't that significant.
It's not really about all those enterprise-y intranet sites that "only" work on IE6. It's likely that the amount of effort necessary to make those sites work on IE8 is, on average, not that great. The problem is more the environment those sites were created in. Hidebound, fear-based bureaucracy combined with very little development talent.
Most such sites are burdened by crushing change-control processes. Those change-control processes exist as a somewhat reasonable bulwark against the very real harm that an unskilled, talentless development team (which, sorry to say, is the norm in the enterprise) lead by unsophisticated, incompetent management can do. This creates a double-whammy for corporations who want to move away from IE6. In principle the work may not be that difficult or extensive, but the dev. team may be too incompetent to even be aware of what the right work is or what the risks are, and the testing process alone would be extremely costly and time consuming. Not to mention the tricky cross-coordination between multiple teams that may be required. It's a perfect storm of just the sorts of things that can halt enterprise-y organizations in their tracks.
Note that the even bigger problem of updating all of the sites on the web so they worked in more modern browsers (even back in the day a multi-billion dollar problem) has already largely been solved. Because site owners knew they had no choice so they rationally invested enough effort into keeping up with the times as was necessary. It's not the size of the problem, it's the capability of the people and organizations tasked with solving it that's the problem.
I've seen lot of things, but still never encountered one of these rumored 'enterprise IE6 only intranet'-apps. Do these things really exists? And why have they not been rewritten yet? These things must be 10+ years old. I rewrote couple internal apps that were a mess of php tucked together with mysql.. they worked.. but hell.
If I'll come across one of these IE6 apps, I'll be the first one to lobby for a rewrite.
They exist. They are payroll, timesheet, and scheduling apps built in the early days of javascript and css when cross-browser compatibility was much harder, and sold to companies who has IE 4 or 5 or 6 on all machines anyway, so what's the big deal if it doesn't work in Netscape?
I'm sure even the people who wrote them never imaged they'd still be in use ten years later.
Yes, they do unfortunately. Often they are relics of some old homespun solution no one understands and everyone is afraid to touch, maybe a product of a dead company, or simply ancient versions that haven't been upgraded in eons because it's cheaper and easier to keep IE6 installed.
The lingering of IE6 is not inherently a "hidebound bureaucracy" problem (though hidebound bureaucracy doesn't help), and has little to do with "crushing change control processes". It's the natural consequence of a number of very sensible business decisions.
If you're developing internal-facing web apps in an enterprise with 15k+ desktops, all of which run a known software stack that includes IE6, your apps are going to target IE6. There's no reason not to -- even if company policy allows folks to install Opera or Netscape on their own, support for those browsers isn't in your project requirements and it isn't in your budget. You aren't necessarily going to INTENTIONALLY do things that ONLY work in IE6, but you aren't going to go out of your way to avoid them either. And if there are IE6-only features, add-ons, ActiveX controls, etc. that make your application work better/faster/etc., you KNOW FOR A FACT THAT YOUR ENTIRE AUDIENCE CAN RUN THEM, so you're going to take advantage of them.
Then Microsoft sits back and enjoys their "win" in the browser wars. So your org has five years -- 2001-2006 -- to develop apps that assume IE6 as the native operating environment.
Big companies can churn out a lot of internal-facing web applications in five years.
Then Microsoft wakes back up and announces that IE7 is on the way -- time to start planning the upgrade. And here's where everything goes to hell in a handbasket: IE7 is not designed to coexist with IE6. You can run one or the other, but not both. (There are hacks that let you get around this, but you don't last long in enterprise desktop software management by encouraging people to run critical business applications on a scaffolding of "hacks".)
So this is what your company's migration from IE6 to IE7 will entail:
* You can't just install IE7 because it'll break things. Probably critical things. If reps come in on Monday and can't take customer orders because you deployed IE7 over the weekend and its updated rendering engine has decided to display the payment field somewhere off the right-hand side of the screen, you will have Failed.
* So, developers need to regression-test everything in your company's portfolio of web applications to make sure they all behave sensibly in IE7's updated engine. Most probably require minimal remediation, but you can't assume that -- you have to check.
* EVERYTHING you develop between the start of the migration and the day IE7 hits your users' desktops either has to work in BOTH IE6 and IE7, or has to be held back from deployment until the day IE7 goes live. Which you can't do until you know everything important has been remediated.
* If an app needs major changes for IE7, any bugfixes and enhancements that can't wait for the IE7 launch have to be made in both the live source and the remediated source. You'd better have good source control practices, and developers who actually bother to follow them.
* Apps that can't easily be made to work well in both IE6 and IE7 have to be deployed at the same time as the browser rollout. One big Flag Day. Hope you didn't miss anything important, because if you did, rolling back to IE6 will not be pretty. And will break all the apps that were rolled out at the same time because they assume IE7.
* Multiply this by hundreds of applications, many of which probably haven't been touched in years, and whose original developers are long gone. (Your ASP.NET devs are probably LOVING having to root through all that legacy ASP Classic code!)
And here's the killer: all this time and effort and remediation is in service of a goal that HAS ABSOLUTELY NO DIRECT BENEFIT TO YOUR COMPANY'S BUSINESS OPERATIONS. Ultimately, people will be doing the same work in the same applications on Day IE7+1 as they were on Day IE7-1. Nobody's job is going to be made easier, no department's bottom line is going to see an uptick. There are second- and third-order benefits from the change (security, etc.) but they don't show up well on a balance sheet...maybe you're lucky enough to be in a company that values them anyway, in which case you have a nice win. But maybe you aren't.
Do you begin to understand why, under some circumstances, NOT replacing IE6 might be a reasonable decision?
I was one of those poor bastards in a corporate IT department six or eight years ago arguing passionately that the standards were in the RFCs and not in "the way Microsoft does things" and we shouldn't design the intranet nor buy expensive products dependent on IE 6 nor rely on postback for GET requests nor etc., etc., and I was pretty consistently shouted down. Any schadenfreude I might enjoy now at the results of one or two particular projects I worked on are overshadowed by regret at missing what we could have done.
In such a situation your choices are either: buckle and become a cog; do it anyway and ask for forgiveness later, if anyone notices (good luck); get the eff out as fast as you can.
I would bet you every last dollar I own that IE 6 users are, on average, the most lucrative users out there. You know how people here say "who looks at ads?" You can't click ads you don't see. And remember, standard user studies say that a large segment of Google users think the ads on SERPs are actually search results.
In short, IE 6 users are dumber than users of other browsers and Google's revenue is juiced by dumb users who click their ads.
I know that IE users are more likely to click on ads, but I haven't heard much about which versions are more likely to click through. Most of the visitors I get to my sites via adwords are on IE 7 and 8; but that's just anecdotal evidence.
So, if you've got something that says IE 6 users are more likely to click on advertisements than any other version of IE, I'd love to see it - maybe we should still be paying attention to them.
As much as a part of me would like to see that happen, that'd really be an odd precedent -- not just not going out of their way to continue making something work on an older buggy browser but actively blocking it from working when, presumably, it otherwise would. I'd be happy for them to pull any extra hacks/workarounds though and make the IE6 experience worse.
I think the implication is that if a user is trying to use Google Docs or other "advanced" features, then either they themselves or their support staff are likely to be willing and able to upgrade their IE client.
Search is more lowest common denominator, hence it's ongoing compatibility.
I actually like the lite version more than the regular one. Apps bug the hell out of me. They're all noise in my signal-to-noise ratio, and I try to keep that as high as possible. Facebook tends to hit the extreme-low side.
Heck, one of the first things I did when the news feed appeared on my home page was to hide it with CSS. I've been updating it every time I need to, and I'm ridiculously happy not seeing all that crap every time I need to check FB for messages (some people just don't comprehend email). Several of my friends use it too, and all have remarked how much nicer FB is without the feed.
Just because Google did it on a couple of their minor properties doesn't mean doing the same won't bight you in the butt. Don't be foolish, they haven't discontinued IE6 support on their search service so obviously they still like having those customers.
No I'm not foolish! I want to help Google kill IE 6. Perhaps it'll bite me in my butt, perhaps it won't, but I think the last person to know that would be you.
I'm kind of surprised that IE6 has actually been actively, not just accidentally, supported somewhere in the recent years. Microsoft has released two new versions after 6 so MS can't be blamed either.
How many of the people still using IE6 also use Google Docs? Aren't all IE6 users either in a corporate environment (where, surely, they have a copy of Office) or, uh, not savvy?
I wish Google could spend some of its ad budget on educating the general public on what a browser actually is. Their current Chrome adverts confuse people like my Dad.
Websites are built on standards. Standards make them usable across lots of browsers. IE 6 doesn't adhere to standards, therefore deserves no special treatment.
IE 6 supports HTTP 1.1 and HTML 4. If your resources are completely unusable (not merely ugly) whenever optional features like scripting aren't available, maybe you can cost-justify not finishing the work, but don't blame IE when your resources don't even work in ELinks.
Even IE6's support for HTTP 1.1 is broken. Sometimes it doesn't send host headers with redirects; there are several different scenarios in which it doesn't treat cache directives correctly; etc. Same with HTML 4.
There's just no excuse for using IE6 or 7 in 2010.
Nah, I'll blame IE when my site works in every other browser besides IE. IE doesn't follow standards. IE8 doesn't follow standards. Any argument you make about it being my fault is going to be wrong because IE just doesn't follow standards. And "optional" languages provide a(n) UI. You may prefer to not build those into your sites, but most of the development world would disagree with you.
IE6 doesn't support HTML 4 properly and it especially doesn't support CSS 2.1 properly. The effect is that whereas normally the cost to support a given browser is relatively low (especially more standards compliant browsers such as those based on webkit) the cost to support IE6 is very high, especially if you demand that the appearance on IE6 should be treated with equal importance as other browsers. The result is that even though IE6 usage is maybe 20% of internet users as a whole (and perhaps less on a given website), supporting those users is vastly more expensive than supporting other users.
I love you.
Signed, Web Developers Everywhere