Google Twists Knife In IE6, Pulls Support From Docs And Sites(techcrunch.com)
techcrunch.com
Google Twists Knife In IE6, Pulls Support From Docs And Sites
http://www.techcrunch.com/2010/01/29/google-twists-knife-in-ie6-pulls-support-from-docs-and-sites/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29&utm_content=Google+Reader
58 comments
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.
No, but this makes it just a little bit easier for web developers to convince their boss or client that IE6 isn't worth supporting.
I think phasing out IE6 is actually good for MS as well.
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.
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.
The official link is here: http://googleenterprise.blogspot.com/2010/01/modern-browsers...
'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.
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.
Well, who is going to feel the knife is the IT departments that keep prohibiting FF, etc. on their employees' systems.
...and the poor slobs who got sold software that would only work via IE6.
...and the poor slobs who got sold software that would only work via IE6.
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.
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.
If I'll come across one of these IE6 apps, I'll be the first one to lobby for a rewrite.
Go to any Wells Fargo branch. Ask a banker to pull up your account. Notice the little blue 'e' in the upper-right corner.
That's over 6000 retail locations using ie6. To handle your money.
That's over 6000 retail locations using ie6. To handle your money.
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.
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?
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.
It's about time. If Google is willing to take a stand against China this is the least it can do back home.
if they discontinue support for IE6 on Google.com home page, that would really kill off IE6.
That would hurt Google earnings a lot since IE6 is ~20% of global browser market share (http://en.wikipedia.org/wiki/Template:Msieshare1)
Who knows how much it would hurt Google's earnings. These aren't people who are out buying new computers, who says they're clicking on ads?
I'm sure that some are clicking, but I don't know that IE6 users are necessarily as lucrative to Google as users of other browsers.
I'm sure that some are clicking, but I don't know that IE6 users are necessarily as lucrative to Google as users of other browsers.
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.
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.
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.
Search is more lowest common denominator, hence it's ongoing compatibility.
Considering how simple the google.com homepage is, is there really much to support here?
Docs needs a heavy amount of JavaScript to do it's work.
Docs needs a heavy amount of JavaScript to do it's work.
How about Google release a benign virus that would install FF and make it a default browser... and release the virus on Google.com homepage.
Well they already released Chrome Frame, which turns MSIE into Chrome: http://code.google.com/chrome/chromeframe/
i wish Facebook would follow suit and toss all IE6 users into their lite version.
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.
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.
Google, I owe you one.
As usual the source document http://googleenterprise.blogspot.com/2010/01/modern-browsers... is more concise and wastes less of my time. Starting March 1 key functions may no longer work on IE 6 and other older browsers.
This is good news for my company. It hastens the day when we can drop support for IE6.
This is good news for my company. It hastens the day when we can drop support for IE6.
This for me officially means I no longer have to support IE 6 for my app. Whew, bullet dodged. Sure wasn't looking forward to fixing those bugs.
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.
Edit: spelling
Edit: spelling
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.
So, does this mean that Google will no longer be testing on IE6, or that they will actively block/disable their products on it?
Google doesn't need a knife, it needs a stake. IE6 is like the vampire of web browsers.
IE6 is slowly heading to hell. This is my personal wish.
ABOUT TIME!!!!
The other day I found out that MSN games don't support IE6. Google and Microsoft are allies on this one.
The irony is: nothing will put more cash in MS pockest than forcing those corporate lame-ducks to finally upgrade.
Isn't upgrading IE free? Or is it really old versions of Windows they run, that can't be upgraded? Which ones would that be?
[deleted](1)
I love you.
Signed, Web Developers Everywhere