1.  I really like the RSS feeds.  I can think of several ways, especially by product or technology, to consume those RSS feeds on our technical portals at the office and on my blog. 

2.  The autocompletefeature is very useful if you’re unsure of how something is spelt or want to browse through a namespace.  For example, if you knew what you were looking for was in System. Web. Caching, you could type that in to the search box and let autocomplete simply return what falls under there.  I’m not sure if this was the intended use, but it works quite nicely. 

In addition, for those who know exactly what they’re looking for, the delay is enough that it doesn’t hinder a quick search. 

Dislikes

1.  I wish I could pre-refine my topics from the initial search page.  Searching and THEN refining requires two steps, two page reloads, and, in it’s current build, about 15–20 seconds in page loads.  If I’m searching for a query and know ahead of time that I just want to look at the MSDN Documentation, let me set that. 🙂

2.  Filtering by Language sometimes filters out “correct” results.  After our discussions, this appears to be less of a matter of the search engine and more to how articles and posts are tagged within the libraries.  With this in mind, filtering by a specific version of language is almost useless. 

3.  Not being able to use the autocomplete functionality with FireFox is a real drag.  I’m honestly not sure if this is an issue with FF3 or the MSDN search site, but from Firebug’s POV, I get a 400 error when I try to query. 

UPDATE: 4–5 refreshes of the page in FireFox and it seems to work.  Why?  I’m not really sure.  It seems the 400 error is more of a timeout than an actual error, but the GET request is only 200ms each time it fails.  Odd. 

4.  Not so much a “dislike” as an “hmm”—I use the browser built-in search bars a lot.  I rarely open up to a “search page” because of it.  Unfortunately, the cool features of MSDN Enhanced Search (autocomplete, refinements, etc) require you to be on the page to use them.  Perhaps a new searcher toolbar that adds these features into IE and FireFox could be made available OR a search bar (similar to Desktop Search) for Windows that I could toss down and always have access to MSDN resources. 

Suggestions

1.  Work on reducing the number of requests and load times (already discussions about this in the forums, but adding it to the list).  We’re on a dedicated OC-3 line here at the office, but I’m impatient. 🙂

For example, the Google query requires 5 requests and 948 B for the first result page to come up (905 B of that from cache). 

Repeating the same query over again narrows it down to only 7 requests (65 KB), but doesn’t seem to speed up the returns. 

2.  It’d be great if “Refine By’s” allowed you to toggle them on and off.  In the current build, refining is an all or nothing.  You can’t refine by “Blogs and Forums” by checking each one—you have to refine by Blogs, check the results, go back, refine by Forums, check the results.  Time consuming and painful.  On the forums, they’ve already noted that they’re checking into this—and I’m excited to see the results. 

3.  Work with the MSDN Documetation groups—if I parse out and am searching just for C# results, then have those preslugged as the language settings on the MSDN documentation.  That’d be great!  Per #2 in Dislikes, it’d be nice if I searched for “Func<T>” and filtered by C# 2008, that I’d get the C# 2008 (or .net 3.5) documentation for Func<T>. 

4.  It’d be great if, in future versions of MSDN, that searching for help in Visual Studio and other Microsoft products worked similar to Enhanced Search.  Currently, the “help” in most Microsoft products leaves much to be desired and, like VS2008, is simply redirecting to msdn.microsoft.com anyway. 

5.  Different versions of documents are hard to disseminate unless you look at the URLs—which gets painfully slow if looking for a quick answer.  In the example below, both documents point to information on System. Net. Mail; however, the first is for VS2008/.net 3.5 and the second is for VS2005/.net 2.0.  You can only tell by the URL. 

Conclusions

On a matter of scope—I see MSDN Enhanced Search as a means of searching MSDN documentation and, to a degree, forums.  If I need to know what methods are part of an object or a specific syntax, this will be the place to come.  I really do like the Enhanced Search over all other existing Microsoft searches. 

Unfortunately, 9/10 of the information I search for tends to come from sources outside Microsoft (non-MSFT blogs, forums, etc)—non usage/technique queries.  It’s hard to justify using MSDN Enhanced Search to JUST search Microsoft materials and then go “oh, well, didn’t find it, guess I’ll hit Google”—and then have to wade through those same Microsoft materials as well as the rest of the world.  Just food for thought. 

I want to thank Chris Slemp for the opportunity to provide feedback and test out the new functionality for the MSDN Enhanced Search.  While I’m a Googler to the core, I look forward to seeing how the MSDN search evolves and improves—and how I can integrate it into my searches. 

Like this:

Related

Hi David – great feedback!  I’m on the MSDN Search team & help to define our search features going forward.  You’ll be pleased to know that the same suggestions you’ve asked for match almost exactly our top priorities for the future of MSDN Search. 

Some progress you can see already:
– “Different versions of documents are hard to disseminate unless you look at the URLs” – have you seen our latest search UI.  We place matching refinement links under each search result, so you don’t have to look at the URL anymore. 

– “reducing the number of requests and load times” – we’ve worked really hard on this one.  initial requests are down by 1/3 from a few months ago, bytes are down by 1/3, and “warm cache” (2nd request) requests are way down– as few as 4 requests per page down from over 20.  We’ve also rolled out CDN caching which helps folks on slower networks, especially outside the US. 

We’re working on the other things you asked for as well– not just because you asked for them but because other users have asked for them too.  Thanks again for the feedback.  We are listening! 🙂