views:

45

answers:

2

At my place of employment, we are increasingly finding it difficult to develop for IE, which was historically the easiest browser to target, from an intranet-app point of view.

  1. It was already deployed.
  2. It already understood NTLM authentication, thus well integrated with our domain-level security.
  3. It had neat, albeit non-standard features such as XMLDOM and XmlHTTP.

Now, we are increasingly irritated by issues presented by IE:

  1. There are several versions: IE 7, 8, and soon 9 beta, which all have slightly different issues related to performance, functionality (especially re:security and zones), and aesthetics.
  2. IE 7 and 8 are slower than Webkit-based browsers. Period.
  3. There are technology limitations such as missing canvas element, CSS bugs, etc. that make it hard to use 3rd party packages or even consistently write code across IE versions.
  4. Users are increasingly using Firefox or Chrome, even for intranet use.

Does anyone have experience with making a transition?

Any advice would be welcome.

A: 

My method of development has always been to write for Firefox or Chrome and it kind of just works in IE. I know, it's counter-intuitive, but it worked out for me more often than not.

AngryHacker
+1  A: 

Firstly, check all current intranet apps with a Webkit-based browser. If you are going to make an intranet site that will be broken on IE (eg, using canvas), then you better make sure that you fix any legacy intranet apps that are broken on modern Webkit-based browsers before you force everyone to need to run a non-IE browser.

Make sure the browsers function correctly on your corporate network as well. For example: Chrome still has some outstanding issues with NTLM/Kerberos. Although this is a small issue if it means you can drop IE. Depending on your user base however, never underestimate the user attention that will be needed for those who have used nothing but IE.

I use a Webkit-based browser at work, even though we have a ton of crappy/broken IE only sites. I have to occasionally open IE to complete tasks on those sites. Now, I'm okay with it because I'm use to it and prefer the minor pain to be able to use Chrome with everything else. Non-technical employees however are not and would prefer to just sit in IE (since in their eyes, it is Chrome's fault the site doesn't work {since it has worked fine for several years [a point hard to argue with from a business perspective (without bringing in 'technically mumbo-jumbo' that they dismiss)]})

So, sure, do it. Just make sure you plan it out so that it goes as smoothly as possible first time around. User buy-in is what you want, not backlash.

Dan McGrath
Two words: Chrome Frame.
Jeff Meatball Yang