why does msdn search still suck?

I was at vslive and the msdn search team asked, "How many people use google to search msdn?". The majority of the room raised their hands and the msdn  group humbly chuckled. What I don't get is why the msdn team doesn't take a hint and get it together. The msdn search has sucked for a while and continues to do so.

I mention because I was looking for a reference for the api to local.live.com (which BTW is the best mapping service on the web and if you don't agree you are wrong and will be smited). Anywho search "local.live api" on google and it is the first result. On msdn however I am not sure wtf the results are. I am really getting tired of the msdn search being such a POS.

I've seen on an internal mailing list (and possibly also on an external blog?) someone announce themselves as the new program manager for MSDN Search. This was in the last few months. I remember thinking at the time "hooo boy, there's a job I wouldn't want..."

Ahhhh, here we go.  http://blogs.msdn.com/msdnsearchblog/

And they've got a beta implementation of MSDN Search that uses MSN Search technology (http://lab.msdn.microsoft.com/search/)

Sadly, "local.live api" still gives precisely 0 hits...

For the visual studio products 2005 I think MSDN is GREAT!, online searching, message boards, local search, it has everything, a HUGE improvement over VS2003's MSDN.


But I never use the actual msdn.microsoft site so I can't comment there.

Yeah it is a pretty tough job, the balance is to make a search that works well across a couple of million documents in tens of languages for a few dozen technologies all using the *same* terminology - e.g.  what does Window, SELECT, INPUT mean?

Live.Local API - unlike other Service APIs (Mappoint, Search etc.) isn't documented on MSDN yet.  I guess that Live isn't ready to commit formal docs up there until they release. 

I've just adding local.live.com/help to our test environment's search scope though it introduces some noise to the rest of developer search (much of /help is interface help rather than url reference)

If that works out I'll put it live later tonight.  The urls it returns give a bunch of script errors (i'd assume because they need other page structure to work).  We'll work with the Local guys to see if we can make that better.  It'd be cool if they had a development center on MSDN of course.

We're working on a bunch of different projects to improve crawling discoverability, ways to slice/dice/filter results, and in general improve the quality results for customers searching on ours and external search engines.

As I've said in other posts on C9 and on our blog, send me mail, comment on our blog, or blog about MSDN Search yourselves.  We're watching, listening, and responding.

stephbu wrote:

As I've said in other posts on C9 and on our blog, send me mail, comment on our blog, or blog about MSDN Search yourselves.  We're watching, listening, and responding.

A few days ago, I wanted to create an OpenSearch Provider for IE 7... and did an MSDN search on "opensearch" -- got 5 results, none of which were related to OpenSearch.

Today I get 6 results -- one of which is related, but it's just the word appearing in a chat transcript...

I originally thought this was due to the quality of MSDN search.  I eventually realized it was probably because MSDN didn't have any documentation on OpenSearch.   (I eventually found what I needed by doing a Google search on "opensearch," which led me to the AddSearchProvider method.)

If you know enough to search MSDN for the AddSearchProvider method, you currently get two hits, both of which say

If you would like to add/implement access to your site's search provider, implement the window.external.AddSearchProvider(URL) call in your webpage to prompt the end user (see our Internet Explorer blog).

If the IE Blog is where we're supposed to go for this information, maybe MSDN Search should crawl it...?

(When searching for "AddSearchProvider," Google points to the IE Blog as well...)

I typically use Google to search MSDN.

site:msdn.microsoft.com <search terms>

Search for MSDN2 seems to be offline right now.

There's also a very annoying bug on MSDN2 I discovered recently. You can't get to pages of any type with "null" in the name. Try it; go to the MSDN2 page and try to navigate for instance to System.ArgumentNullException, and you'll get a 404 error.

I reported this yesterday via e-mail.

Karim wrote:

stephbu wrote: As I've said in other posts on C9 and on our blog, send me mail, comment on our blog, or blog about MSDN Search yourselves.  We're watching, listening, and responding.

A few days ago, I wanted to create an OpenSearch Provider for IE 7... and did an MSDN search on "opensearch" -- got 5 results, none of which were related to OpenSearch.

Today I get 6 results -- one of which is related, but it's just the word appearing in a chat transcript...

I originally thought this was due to the quality of MSDN search.  I eventually realized it was probably because MSDN didn't have any documentation on OpenSearch.   (I eventually found what I needed by doing a Google search on "opensearch," which led me to the AddSearchProvider method.)

If you know enough to search MSDN for the AddSearchProvider method, you currently get two hits, both of which say

If you would like to add/implement access to your site's search provider, implement the window.external.AddSearchProvider(URL) call in your webpage to prompt the end user (see our Internet Explorer blog).

If the IE Blog is where we're supposed to go for this information, maybe MSDN Search should crawl it...?

(When searching for "AddSearchProvider," Google points to the IE Blog as well...)

Yes Karim, finding Opensearch on MSDN document site seems pretty hard a the moment.  Investigating further, there is one article missing from the index, that should be addressed by some engineering we're doing to make the MSDN library pages more crawlable. 

Biggest issue is that the calls aren't documented on the main MSDN site yet.  Our approach at the moment is to segregate searching between "reference sources" like the main site, and community contributions like blogs, forums and other partner community sites. 

In this case the Blogs tab of the lab search did find "opensearch".

http://lab.msdn.microsoft.com/search/Default.aspx?__VIEWSTATE=&query=opensearch&siteid=0&tab=3

So I have an interesting question for the thread...  How important is the that differentiation between the sources? 

We're ideas around alternate searches around, e.g. Search main site and blogs with the same query - such that if you searched for say "Opensearch" you'd get the results for all sites back.  Of course this increases the signal to noise ratio somewhat though.  (for a general query like XML, combined it'd look like this...)

Another approach we're looking at is doing much broader queries and providing some neat one-click filtering options. 

We're in the process of identifying features for the next development cycle, as always thoughts and feedback really welcome.  (MSDN Search Blog)

Steve Butler
Software Architect
MSDN & Technet

Searched for SHParseDisplayName on the old search and the first result is right. Searched it on your updated one and the correct result is missing.

BTW - IE7 search provider addon was a good idea. I'll try to keep using the beta search to see if it gets any better.

MSDN has documentation for Virtual Earth which was its name before the Windows Live re-branding.  They should update it to have "windows live local" and "local.live.com" in the docs somewhere too for better recall.

I know it's not the same thing as what you brought up... I think the search thingie in Document Explorer 2005 is way harder to work with than the search thingie that came with whatever shipped with VS2003.

It can't be so hard to make a useful search UI (especially in Win32 code) but apparently this is the best they came up with.

PetKnep wrote:

Searched for SHParseDisplayName on the old search and the first result is right. Searched it on your updated one and the correct result is missing.

BTW - IE7 search provider addon was a good idea. I'll try to keep using the beta search to see if it gets any better.

Thanks Pet for the participation and feedback ... 

A large part of the project is exposing an area of missing documents buried in the fabric of the original Library system (ASP circa 199x...)   Generally documents linked to by external sites or crawlers with "MSDN Shims" were discovered in this soup. 

Piece-by-piece we're moving these documents to the MSDN2 platform where crawling works and we get much enhanced metatagging for some of the fun we'll have in future releases.

I'm glad you like the IE7 search too - we're working on a slew of ideas around exposing search as an XML data-provider.

Steve Butler
Software Architect
MSDN & Technet (http://blogs.msdn.com/msdnsearchblog/)

*dupe post*

Steve,

I know it's not directly related to search, but could you please check on the "topics with null in the name are inaccessible" bug? For example, the link from the TOC for the System.ArgumentNullException is http://msdn2.microsoft.com/en-us/library/system.argumentnullexception.aspx, but following this link gives a 404. This happens with every type with null in the name. I reported this a few weeks ago via e-mail, but I have received no response and it's also not fixed yet.

As a search related sidenote, searching on MSDN2 for System.ArgumentNullException returns the topic for the type on the old MSDN1 site (for .Net 1.1) as the top result, but the topic from MSDN2 itself isn't in there at all.

I would appreciate it if you could at least let me know if you're aware of it and working on a solution.

Hi Sven, yes I can confirm that this issue was raised, and has been fixed for release in early April.

Titled, "Aliases for types/members containing with "null" don't work", the bug impacts any friendly-named URL with Null in the name.
e.g.

Impacts "ArgumentNullException"
http://msdn2.microsoft.com/en-us/library/ArgumentNullException(VS.80).aspx">http://msdn2.microsoft.com/en-us/library/ArgumentNullException(VS.80).aspx

Doesn't Affect "Nullable Generic Structure"
http://msdn2.microsoft.com/en-us/library/b3h38hb0(VS.80).aspx">http://msdn2.microsoft.com/en-us/library/b3h38hb0(VS.80).aspx

Search is reacting to the 404 the bug generates by dropping it from the crawl, leaving the existing Everett document as next best match.

stephbu wrote:

Hi Sven, yes I can confirm that this issue was raised, and has been fixed for release in early April.

Titled, "Aliases for types/members containing with "null" don't work", the bug impacts any friendly-named URL with Null in the name.
e.g.

Impacts "ArgumentNullException"
http://msdn2.microsoft.com/en-us/library/ArgumentNullException%28VS.80%29.aspx">http://msdn2.microsoft.com/en-us/library/ArgumentNullException(VS.80).aspx

Doesn't Affect "Nullable Generic Structure"
http://msdn2.microsoft.com/en-us/library/b3h38hb0%28VS.80%29.aspx">http://msdn2.microsoft.com/en-us/library/b3h38hb0(VS.80).aspx

Search is reacting to the 404 the bug generates by dropping it from the crawl, leaving the existing Everett document as next best match.

I got this post from here
I tried doing a simple search on new alpha version of MSDN Search and it doesn't work period.

Here's my test click here

Hope to see this improves....

stephbu wrote:

Hi Sven, yes I can confirm that this issue was raised, and has been fixed for release in early April.

It doesn't appear to be fixed yet, or has the fixed not been deployed yet?

Double post