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.

 

Comments (20)

  1. shaunbed says:

    I was wondering why the MSDN blogs search was so painful.. I am not sure whether it is Telligent or MSDN.

    Shaun Bedingfield

    blogsb.blogspot.com

  2. Andy Pennell has a pretty thoughtful posting on his blog about some of the problems with relevance and…

  3. Andy says:

    Yep, I’ve complained to the DX team about it a couple of times. My theory is that the MSDN indexing can’t cope with have 6 archived SDKs a year. Normally the updates are small targetted ones or huge once every couple of year type things. The DX docs rev every 2 months and MSDN just doesn’t have a plan.

  4. I’m a .NET developer and have similar experiences. The MSDN table of contents buries things in places I’d never expect to find them. When searching I find Google the best way to get answers. If MS wants to compete with Google, they can start with a search engine that works well on their own content!

  5. anon says:

    MSN Search is working on getting MSDN start using that system (right now the two are unrelated). Once that happens things should improve.

  6. TC says:

    I’ve seldom got a useful result by searching directly in MSDN. When I need the docs on a normal win32 API, I go straight to google, type the api name plus MSDN, then hit [I’m feelin’ lucky]. It always works, for the searches I do.

    TC

  7. Piotrek says:

    I agree MSDN search is not perfect 🙂

    But these past 3 months I noticed that google was beginning to give worse results, especially when you have many common keywords (3-5)

    Gess where I am going to find my results now…

    Altavista.com (yes it still exists!)

  8. MTW says:

    I agree, I find the MSDN search to be near useless. I generally prefer to use google to find the result for me.

  9. Jeff Parker says:

    I stated this same problems a long time ago when people were compairing MSN search and Google. Even MSN search will turn these low. However what typically ticks me off the most is error codes. Anywhere in the knowledge base. You get a specific error code you may get back 200 docs on the search and none of them even relevant to the error code. Google will return specific information and usually point right to a direct fix.

  10. Jeff Parker says:

    Oh yeah and another example of this was the first day I downloaded beta 1 of the 1.0 framework. I got a System.NullReferenceException. Try searching anywhere on msdn back then for a null reference exception was usless. I don’t know how good it is now but again google came to the rescue. I personally think the search on msdn could be removed. Now Dynamic help under visual studio does a great job. but no msdn search does.

  11. Jason L. says:

    I have the same sentiment as above. I often go through the same process to find the API documentation… it is especially bad when I’m trying to find documentation for a call that I know starts with _ in MS land.. (_stricmp, etc..)

  12. TC says:

    http://www.google.com, _stricmp msdn, [Im feelin’ lucky!] takes me straight to it 🙂

  13. Andy Pennell says:

    I tried the above keywords on MSN Search, and its results were worse than both MSDN and Google. It could not find the right ColorFill AT ALL, except, ironically, this very blog page, which came as the #1 result!

    That’s it: maybe I should cut & paste the docs I want into my own blog, so then MSN Search can find them. A brilliant idea don’t you think?

  14. LOL, I’m just happy then can actually search for C# correctly now –

    http://blogs.msdn.com/danielfe/archive/2003/07/25/51777.aspx

    For better searching, try restricting to a site, like this

    site:msdn.microsoft.com colorfill

    #1 result is DX for Google and MSN.

    -Dan

  15. Ivo says:

    Especially the F1 help is useless for Win32! It opens the MFC, .NET, WinCE topics, but not what I want. If I press F1 on a keyword and if that keyword is the title of a topic, then that’s what I expect to get! Instead if I press F1 on WM_SIZE I get CWnd::OnSize. Usually the topic there is not very informative and has a link to the Win32 page for the real juicy details. Another example: F1 on DeleteObject goes to CGdiObject::DeleteObject. There is even no link to the Win32 function!

    In Whidbey the search is even worse than before. If you type multiple words it searches for ANY of them. That usually yields 500+ results. Totally useless. As of Beta 2 there was no way to force a search for ALL of them.

    The online MSDN is not much better. It doesn’t display the number of the results, just lists the first 10, and a Next> link. I don’t know if I should add more keywords to narrow down the search or not.

  16. Lushootseed says:

    It is not just you Andy! I as a Microsoft employee has been grudging about the fact that it is hard to find content in MSDN and so I ended up using Google as choice to search MSDN and it finds most of the time what I need (I usually append the keyword and MSDN as the search terms). I also wondered just like you on why C.E docs are getting a preferential treatment!!

  17. Joku says:

    For years I’ve had a custom default homepage, which uses Google but uses radioboxes to point the search to site:blogs.msdn.com or site:msdn.microsoft.com etc.

    Here is example result that might give you some idea for doing your own specialized search.

    http://www.google.com/search?q=colorfill&domains=blogs.msdn.com%3Bweblogs.asp.net%3Bmsdn.microsoft.com%3Bsourceforge.net&sitesearch=blogs.msdn.com

  18. happy says:

    Genuine incompetence. Microsoft has been designing poor API’s and providing poor documentation since as long as I can remember. Only recently with C# has there design started to become more robust. The way I see it:

    General Windows API: obfuscated often unintuitive poorly documented hidden functionality

    Direct X: Many versions not only to add functionality but to make long winded rambling initial API design somewhat more concise. ( for design OpenGL still wins for me )

    VisualBasic: Cludgy language needed to be updated several time not only for functionality but because basic design of language was lacking.( Mainly object oriented ) considering the superior Delphi / Object Pascal inpelementation that already existed you have to wonder what do the guys at Microsoft spend all of there money on. By the way major Delphi/ Object Pascal designer were contracted by microsoft to aid in developing C#.

    In a market economy the theory is someone with poor service or inferior product will not survive against the competition but instead the opposite has happened.

  19. Very valid complaints here. I experience the same level of "usability" from almost all Microsoft documentation, including the built-in VS help browser, the Platform SDK documentation e.t.c. I have since started to write my own reference documentation for most API’s from Microsoft that I work with on a regular basis, using a plain single-file HTML document. And it really works better IMHO. And MSDN. That’s a whole new can of worms on it own. Frames, horrible AJAX-ified search that can’t be properly keyboard-navigated… And not to mention the fact that once you find the page for control X, you actually have to navigate four other pages just to get to function call reference, parameter list e.t.c. Just pray you have a tab-enabled browser…

Skip to main content