Every now and then, I run into a customer situation where the ACT data collection agent causes an application on the desktop to stop working correctly. This happens because the compatibility evaluators in ACT use shims to collect this data, and some applications do not behave correctly when shimmed.
In the past, I have just recommended that the customer don’t use compatibility evaluators in that case, in order to avoid that challenge. They can still collect inventory (that doesn’t affect applications like compatibility evaluators would), and the data from compatibility evaluators, while potentially helpful, isn’t so valuable that it’s worth losing productivity.
But apparently, somewhere along the line, we added a feature which lets you exclude applications which don’t work with the compatibility evaluators:
Troubleshooting Application Failures When Running Data Collection Packages
I wasn’t even aware that we had added this feature! (I felt a little better when I later discovered that the Program Manager for ACT similarly wasn’t aware that we added this feature.)
For those of you who are attending MMS 2011 in Las Vegas next week, I have a couple of sessions I will be presenting there:
Internet Explorer 9 in the Enterprise Friday, March 25 10:00 am Lagoon L
In this session, we will be providing an overview of Internet Explorer 9 for the Enterprise. We’ll summarize the experiences of the TAP customers who have already deployed thousands of seats of IE9, and focus heavily on app compat (the #1 challenge in moving browser platforms). Is IE9 right for you? Come and find out! Will it be nerdy? Definitely.
Windows Deployment Live Game Show Friday, March 25 11:30 am Lagoon J
This is always a fun session! We take the top deployment and app compat experts in the world, put them in front of an audience, and then try to stump them with questions so hard that no sane person would ever get them right. Then, they see how many of them we get right. If you want to close out MMS by watching geeks squirm, then this is your session. I’ve won at the past 2 conferences (TechEd Europe and TechReady 12) – it’s about time someone stepped up and put me in my place…
Hope to see some of you there!
We recently announced that Internet Explorer 9 will be available starting Monday, March 14. Naturally, if you are a geek (which, statistically speaking, is true for a fairly large percentage of folks who happen to be reading my blog), you are asking yourself, “where are all of the nerdy details about changes which might affect my applications?”
Well, chances are that most of your applications will do OK if you leave them in one of the compatibility modes (Quirks, IE7, or IE8), which you can do easily enough using the X-UA-Compatible header/tag. In fact, the success rate we’ve had with that with pilot deployments in our enterprise TAP program has been phenomenally high. But what if you have an existing application where you are choosing to invest in an update, perhaps to leverage some of the great new capabilities in HTML5?
The place to start is the Internet Explorer 9 Compatibility Cookbook.
Getting customers off of Internet Explorer 6 (IE6) is certainly one of the priorities within Microsoft – how many other products have countdowns to its demise? But who would have thought that one of the biggest challenges for app compat that keeps people on IE6 is actually a bug fix and not new code or rules?
What’s the bug? In IE6, a DOCTYPE declaration is only ever read if it is the first line of code in the markup. Now, DOCTYPE is what switches you from quirks mode (the default) to standards mode, and the standards say that it does not have to be first. We can’t very well have the standards mode switch not itself be standards compliant, so we kind of had to fix that. But here’s what happens. Let’s say you have markup that starts like this:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head>…
Looks perfectly good, right? In fact, I copied and pasted it from here. But, on IE6, what happens is that we ignore the DOCTYPE and we render it in Quirks mode. Quirks mode has a completely different box model, and renders entirely different from standards mode, even IE6 standards mode.
What I usually find with pages that start like this is that IE8 standards, or even IE7 standards isn’t what breaks them – the pages don’t even lay out correctly using IE6 standards. No, the problem is that the web pages are Quirks dependent, not IE6 dependent – and we still have a Quirks mode!
Of course, there’s no super easy way to jump back to Quirks mode, but you do at least have a few options.
First, if you are modifying the source code, you can just remove that DOCTYPE and get quirks in every version of IE, because you are no longer dependent on the IE6 DOCTYPE bug to land in Quirks mode. If I do that, I also like to tag that website with X-UA-Compatible IE=5 to leave metadata indicating that this outcome was intentional.
If you can’t touch the source code, then you can instead just modify the web server to output the X-UA-Compatible header specifying IE=5.
If you are in the unfortunate position of not being able to touch the server or the page, then there is a hotfix available to allow you to configure web sites to run in Quirks mode via group policy, available here:
A webpage is not displayed correctly when you browse the webpage by using Internet Explorer 8 Standards mode or Compatibility View in Internet Explorer 7
Whatever path you choose, there is often a quick way to get some of your applications working more quickly and less expensively. Not that I recommend Quirks mode as something desirable, but updating to support the latest standards takes time and money – ideally you can choose to support the latest standards for applications you introduce, without being forced to reinvest in your entire existing application estate, where the business return for this investment may never materialize.
One of the most common questions I get while working with enterprise customers is: should I leave Compatibility View turned on for the Local Intranet zone?
We have an awful lot of guidance that seems to be pushing for standards, standards, standards everywhere, and this has a tendency to get customers a little scared – will this compatibility mode go away at some point, and am I just delaying the inevitable? I don’t want to finish a migration, and then have to go back and do it all again.
There are two forces at work, and my recommendation is ensuring you consider both when developing your strategy.
First, there is business value in adopting standards. Think about it – how many college hires do you know coming out with deep IE6 experience? If you are developing externally facing websites, you can’t afford to ignore modern, standards-based browsers – so my internal web developers must have a different skillset from my external web developers. There are benefits to leaving the past behind, including more efficient markup, less code branching, etc.
At the same time, do you really want to go back and revisit every single one of your web applications each time that you move your browser? Compatibility with your existing web properties is, after all, one of the core value propositions of Internet Explorer. Having to uplift your entire application estate each and every time standard change is an expensive and time consuming proposition, and while adopting the latest standards in general is a good principle to follow, adopting it for each and every application may not have a business case to justify that investment. You shouldn’t have to touch every single app every time you want a new browser, even if the standards changed.
So, my recommendation when moving forward to a new browser is the following:
Start with your policies configured to make the majority of your applications work without touching them
The default configuration for both IE8 and IE9 is to place the Local Intranet zone into IE7 compatibility, and this typically makes sense. More of your apps work out of the box this way, which means you can choose to invest in standards for the applications where there is business value in doing so, and not have to do so for all of them because you have no other option.
Tag your sites each time you touch them
Defining your heuristics to place more web sites into a more compatible mode is certainly a good starting point, but why should we have to guess at all? You’ll want to eliminate the guesswork, particularly as the compatibility infrastructure grows to support compatibility with more previous browsers. If you tell IE which rendering mode works best for you, then we can take on some of the burden of keeping that compatible.
Tag each of your websites, if you are touching them anyway, with the X-UA-Compatible header.
This metadata provides evidence for future versions of the browser as to what they could do in order to keep your application working better.
It is also important to know about this because, if you default to IE7 compatibility mode for all of your internal web sites, this is the one and only way to opt a site into more current implementations of standards! If you want to play with the significantly more HTML 4.01 compliance in the IE8 rendering mode, then you need to tag your internal site. If you want to leverage the full power of HTML 5 in IE9, then you’ll need to tag your internal site.
Providing metadata that gives evidence around your design – breadcrumbs, if you will – is always a good idea.
Implement standards for new apps and significant enhancements
Having compatibility with IE7 as the default is great for most existing application portfolios, but you don’t want to keep building dependencies on dated standards and implementations thereof, do you? I recommend putting a quality bar in place for new apps, or significant updates to existing apps, to require that they adopt at least IE8-level support of established standards, and possibly IE9-level support of emerging standards, so that your application estate moves forward – gradually, organically, and manageably.
The periodic drop of a new browser could result in an expensive manifestation of punctuated equilibrium, but by leveraging the compatibility infrastructure of Internet Explorer 8 and Internet Explorer 9, the enterprise can tame these periodic bursts of investment and better approach the phyletic gradualism that provides more predictable IT management costs. It is important to keep moving forward, embrace standards, and welcome interoperability – at a pace your business can afford.