Why is MSDN Search so painful?

Since leaving Visual Studio, I have been using MSDN Online as my Help system. (I don't use integrated Visual Studio Help for reasons I'll spare you). As a Win32 programmer, I find MSDN Search a huge PITA. Its not that it can't find things, but the order it presents the results seem to be the exact opposite of what I expect. Needless to say Google, which doesnt know I am a programmer, or anything about me at all in fact, presents the results in a much more sensible order.

I am doing a lot of DirectX coding, and MSDN for some reason carries many copies of the DX documentation. All but the latest is marked as "Archived content. No warranty is made as to technical accuracy" and are obsolete, however the Search engine doesnt care: it will list page after page of obsolete content before it gets to the current content, often on the next results page, or worse. Crazy. What makes it even more frustrating is that you often cannot tell whether content is archived or not until you follow the link.

Some of the DX docs are for the managed APIs, which I don't use. Again these docs come before the native DX docs, and often the Archived versions.

The other problem that has been going on for years, and remains to this day, is the preference for Windows CE docs. I dont have anything against CE, but I do have several grudges agains their documentation team. They manage to make their docs show up before the classic Win32 docs. They have multiple verisons of their doc set (imagine what the Win32 docs would be like if there was one set for XP, another for W2K, another for Win64, etc) instead of one version with a little box telling you which versions support which features. Again it is often impossible to tell CE docs from Win32 ones until you follow the link.

Actual content problems are much less than they used to be. I still get a few pages which are frankly broken content-wise, but they are rare.

Some things are actually impossible to find due to their over-use: try finding the Win32 ListBox control, for example.

What makes it more galling is that these search results are all from the exact same MSDN produced content, its just the presentation of the results that differ.

For the last couple of weeks I have been collecting some of the worst of my MSDN Search results, and if you are interested, here are my results using MSDN Search and Google. The number shows where in the results list the information I wanted came, so lower is better.

GetSurfaceLevel

  • MSDN: #7- lists 3 archived managed APIs, four archived native APIs before the real one.
  • Google: #1

CryptoAPI: (I am after the summary of the API)

  • MSDN: #21 - various articles using the API, CE docs, all kinds of stuff.
  • Google: #1

D3DCOLOR

  • MSDN:#4 - archived copies preceed it
  • Google: #1
  • The content for this is lacking too. I would expect a list of the macros containted in d3d9types.h or something. More than a typedef anyway.

wcsicmp

  • MSDN: Infinity. MSDN cannot find this, even though it maps to _wcsicmp in reality. You have to know you need the underscore to find it. With the underscore, MSDN scores #1.
  • Google: Unknown. As MSDN doesnt have any content about it, Google just finds references in other places. To be fair this is hard for Google as this is not a Windows-specific function.

DirectX Merit

  • MSDN: #4. Finds three archived articles first
  • Google: #2 - even Google gets archived content first for this one, a rarity.

ColorFill

  • MSDN: #28: No less than twenty-seven archived managed APIs (the same few repeated almost infinitely) before the real one
  • Google: #4 - the first three are not even programming hits, so its really a #1 result in context.

Is it just me? Is the world in fact full of Windows CE and/or DirectX 7.0 programmers who love the order of the search results? Let me know. And the MSDN team: they want to hear from you too, give us Comments.