whats wrong with msdn?

its not only windows that needs some things fixed... - pls. be so kind and take a look at msdn. i think theres two major issues that need attention; and one of them has been an issue for _quite_ some time now.

1.) search sucks big time. for example, go to msdn.microsoft.com and enter 'userdata behaviour' in the search box. ( and yes, i _know_ its spelled 'behavior'. that is, _now_ i know. ). thats what you'd do incase you were searching: you know this stuff is there somewhere, but you don't know the exact spelling of it. (and you sure gonna misspell things incase us english isn't your native language in the first place.). so - guess what: search leaves you with zero results. zilch. none. now, switch over to our friends at google and type in: 'userdata behaviour site:microsoft.com'. guess what? _they_ _do_ get a result. well, two actually. at least its a start. from there, you'll finally end up at the right page on msdn, after you figured out how to spell that word... <sigh>. i can come up with more search related stuff like that...

2.) vs2005 and longhorn isn't here yet. but still, tons of stuff is beeing published thats related to vs2005, longhorn, yukon - and other technologies that simply aren't here yet. infact: its so much stuff that its getting hard to find information on technology that is available right now. you know, the tools that i'm working with to build applications that my users can use today.

WM_THXLISTENING
thomas woelfer

Thomas: thanks for your comments.

We know Search is a problem at MSDN. We've been working with the Microsoft.com search team to improve the experience but we've run into more stumbling blocks than we expected. As you can tell, Search is hard to get right. But we've got some changes coming in the next couple of months as we're preparing for the Whidbey Beta 1 release that should result in improvements for searches in the MSDN Library.

On your second point, we've already created a separate Developer Center[1] and location for the Longhorn SDK[2] to help both those who don't want to see Longhorn information and those who do.

Visual Studio 2005 will soon have its own Developer Center, too, that is separate from the current Visual Studio site. These will be merged when Visual Studio 2005 ships.

[1]: http://msdn.microsoft.com/longhorn/
[2]: http://longhorn.msdn.microsoft.com/

I got something to add here as well:

On every MSDN page I get a javascript error:

Line: 163
Error: Permission Denied

Which is:
 oInput.load(sContentID);

Comes from:
 function GetRateID(sContentID){ oInput = document.getElementById("RatingsStatus") oInput.load(sContentID); oInput.value = oInput.getAttribute("Rate"); }

I already got used to clicking No each time the error comes, but I want this fixed or tell me what I have to change at my pc to get it fixed (is it a cookie issue?)

Tnx

Managed DirectX docs!!!

Ah, feels good to get that off my chest

G.

I usually just search msdn using Google. As mentioned in the post it generally returns more relevant results. If this article is correct Microsoft, Google may go head-to-head then perhaps we can look forward to better search facilites in the future.

Does anybody know when msdn subscribers can get hold of alpha/beta copies of vs2005/longhorn/yukon?

My only problem with the MSDN is the lack of RSS everywhere. It would give me the info I need when I need it. Updates to products. New KB's. C'mon, give me the tools to find the info I know you want me to find!

Nothing like smacking yourself in public, eh? Thanks mate.

Hey cool, would like to add my wisdom too

I realy would like to update my MSDN Library online - if anything changes - automatically - I realy don't like to install every two months a new MSDN Library.

Oh yes, download mirrors in europe would rock !

Ah, and the File Transfer Manager should download more parallel - even one file.

Thanks for reading

Jerry

Not one of the devs here (THFTCBN) uses MSDN search; we all use Google. Invariably the Google Groups point to an MSDN article; why not license the Google Device?

1. The search.

2. Moving articles around. I was looking for an article that I have a hardcopy from a few months ago. I went to the location given on the print out but it wasn't there. I found it again after 5-10 minutes searching (with MSDN search).

3. Code samples; more of them please. More often than not when I'm looking for information on a particular function there won't be a code example with it. It doesn't have to be a 3 page essay either like the asp.net datagrid aricles, just a few lines would do nicely.

jimbo wrote:

I usually just search msdn using Google.

I do the same thing. I really only use msdn for the class library (not sure why I prefer it over the sdk Docs).

Everyone agrees the msdn search does not work as well as the google search. So lets live the SOA way, why can't MS just use the google API on the MSDN pages and save itself the whole lot of bother?
So MS, you gave us Web Services so we could use them, to pck the best information offering out there. MS is not a search company Google is, just use there api. think the unthinkable. Do what you preach.

I have to concur on the whole "vs2005 and longhorn isn't here yet" thing.  Same thing with Channel9.  It's not that I'm not interested, I am, but the sudden shift from information on what I need to do my job now, to information I'll need a year(?) from now makes me feel a little unsettled. 

Maybe this (Channel9) will help on that front.  It is understandable that the folks at msdn are focused on the "future" - it's what they are coding every day.  Me, I'm still finding new exciting | annoying things in 1.1.

Love.

As Tommy mentioned, online Search is a difficult space, given the amount of content that MSDN delivers. We do have some exiciting things planned for Search in the Whidbey timeframe, and this is what I'm working on now (or should be, if I weren't busy checking out Channel 9).
I did post a while back for feedback and/or suggestions for MSDN Search on my blog, so far haven't heard from anyone...

JerryP wrote:

Ah, and the File Transfer Manager should download more parallel - even one file.

It does; in the File Transfer Manager, click the "Options..." button, and go to the Connections tab. You'll see an option for "Maximum Concurrent Transfers" - by default this is set to 1.

HTH

I totally feel you here. I am using directx as part of a medical imaging application since GDI+ is a horribly slow API. The docs are appalling.

steve

IceFreak2000 wrote:

JerryP wrote: Ah, and the File Transfer Manager should download more parallel - even one file.

It does; in the File Transfer Manager, click the "Options..." button, and go to the Connections tab. You'll see an option for "Maximum Concurrent Transfers" - by default this is set to 1.

HTH

Yeah, and the maximum value is 2. And this means you can transfer 2 files at the same time. I would like to transfer 1 file split into portions of 1 - 6 chunks - so I could get the VS2005 2GIG file much faster

Green Bump