Last week, we updated the Windows 7 Application Compatibility List for IT Professionals on our download site. It has been a while since we have done this (April, I believe) and I know a lot of people were looking for an update. The newest iteration includes data from 17 markets, and being more global was a significant investment for this release.
I figured I would use this announcement as an excuse to answer some of the FAQs I hear around our compatibility data, to try to explain what we are offering you and how it might help.
What does it mean for an application to be listed as compatible?
The word “compatible” is a difficult one to wrap your arms around. We sometimes toss it around so casually as to imply that there is some qualitative state of being that is “compatible.” Well, there isn’t. To be compatible means to have no bugs on a particular platform which stops you from getting your work done. Now, since all non-trivial software has bugs, we must concern ourselves with only those bugs which stop you from getting your work done. Not knowing what you do, we can never be sure of that. If you’re on Windows XP and you raise a software helpdesk ticket, technically that’s a compatibility issue … with Windows XP!
So, since we can neither proclaim software as bug free nor claim with certainty that you can get your work done (whatever that work is), we have to focus on a slightly different definition of compatible: supported by the vendor.
So, if an app is listed as OK here, then that means the vendor supports it. If it’s listed as not OK, it means that the vendor doesn’t support it. Note that this doesn’t mean it won’t work, it just means that if it doesn’t work, they’re not going to go out of their way to help you. But it may very well work.
Where does this data come from?
Ah – that’s the next challenge. There is no registration process for software on Windows. There is no mandate that software developers at other companies submit status reports to us, take our calls, or cooperate in any way. So, we often have to go digging for this information. See: The Long and Sordid History of Vendor and Community Data in the Application Compatibility Toolkit 5.5.
We are nothing more than a data aggregator. The final authority on support is your vendor, and vendors (in what’s not an unreasonable request) feel that they can manage their relationship with their customers directly, thank you very much, and politely decline to enlist Microsoft as an intermediary in that relationship. That works fine when looking at a handful of apps, but when you’re looking at a few thousand applications, most customers aren’t terribly interested in making a few thousand phone calls – they’d prefer to automate that process! To automate, somebody has to build a list against which you should automate, we’re the ones who are causing the churn, so they think it should be us. Again, perfectly reasonable. So, customers want from us what is somewhat hard for us to deliver – being a data aggregator from not-always-cooperative data sources. That just means we have to try harder.
How do the 3 compatibility lists differ?
We have built 3 different means to look at vendor compatibility data: a web lookup, a downloadable list, and integration with ACT. Some people look at all 3, and they see some differences and wonder, “did they really build 3? Which one is authoritative?”
Believe it or not, we actually have just one! The web site (http://windows.com/compatibility) points at the live database and will have the latest updates immediately. We then build out a spreadsheet … well, I guess I can’t say much more than “occasionally” in light of our recent delivery, but we hope to get that back to “periodically”! Finally, we translate information to feed into ACT.
Translate. Ah. There’s the rub. You see, the AppID scheme used by ACT is different from the one used in our back-end database, so we have to use some heuristics to transfer that data over. And heuristics can, and will be, incomplete. So, you lose some matches in that transition. This is particularly noticeable as people look directly to where they have the highest hopes: Microsoft applications. What’s most visible there are Office and SQL Server. Not because SQL Server is so critical on the client, but because both Office and SQL Server have this tendency to leave around 20 entries each in Add/Remove Programs, this leading to 20 entries in the ACT inventory, thus filling a screen with the Microsoft name displaying 40 rows to essentially indicate 2 “apps” in the sense that you actually care about. We didn’t used to match well on Office 2007, we tuned to make that better, and the tuning for Office 2010 is still in progress. (Office 2010, by the way, works great on Windows 7 and is fully supported, in case those 20 blank entries are worrisome to you.)
What percentage of my apps should I expect to see on the list?
Honestly, I’ve never had anyone share with me the outcome of a manual match with the Excel sheet. The only data point I have seen is the ACT match rate, which (in the large Enterprise accounts I work with) averages somewhere around 6%. In an organization with 5,000 applications, saves you looking up 300 applications (statistically speaking), which, if you spend 2 minutes of time looking things up manually, would have saved you 10 hours of work.
I hope this FAQ is helpful to some of you – enjoy the new Excel list!