1. Relevence. There is a simple reason why I tend to Google for most of my searches, a lot of the documentation I am seeking has either been removed from MSDN or is out of date.
2. Delivery mechanism. Personally I don't care whether the content is delivered via web pages, PDF, chm, sliverlight etc so long as I can find what I want easily and quickly. However I'd probably prefer something not integrated with studio
(other than support for F1) as I normally have multiple studios open and am happy only having one MSDN open.
3. Off-line availabililty. I work for a UK company who is owned by a Swedish parent - our net connection therefore goes through a proxy in Sweden and can be tempermental. (I also do the occasional burst of development on a laptop which is
only on the web when I'm within range of my WiFi connection at home.) If I install the MSDN library I want to be able to find the information I want whether I am connected to the web or not. Perhaps the web can be used to provide for supplemental information
or an effective errata list between MSDN releases. I'd like to see this information merged into the shipped MSDN library at every release which would keep the reliance on the web low.
4. Install size. The MSDN library is huge - it is possible to filter by topic, would it be possible to split the installer to allow selection of which topics to install. Perhaps if a topic was not locally installed then the help viewer could
search the web. It would be nice to be able to select say language and or platform and install topics from those.
5. Quality. The quality of the library is variable - I suppose this is inevitable given the number of pages but particularly for some of the C++ API documentation the quality is very low - many topics almost read like stub pages which people
have forgotten to expand. We also have a standing joke in the office about the code quality of the samples - I know a lot of the code is fairly crude in order to keep the sample size down but its not a good example to give novices reading the MSDN trying
to learn to code. The library needs to be reviewed not just by technical authors but by area specialists who can write! (I'm a geek so I know how most programmers hate writing).
6. Searching/Library Organisation. Whilst the searching capability has improved in recent years its still not easy to find topics in the library. I've lost count of the number of times I've found something in the index only to find link to
the page ends up with the equivalent of a http 404 error. The organisation of the library takes some getting used to as well - it is almost organised for an experienced developer trying to refresh knowledge rather than how a new developer would like to find
stuff. A rule of thumb I have is that if you roughly know what you are looking for use MSDN otherwise use a search engine.
7. Legacy platforms. I get the impression that once a new flavour of the month comes along then the whole MSDN library is recompliled to reflect that. Currently it is .NET technology. Previously it was Windows Mobile and CE. The MSDN library
team need to learn that there are still some of us splunking in old unfashionable tech who still need to look up documentation relevent to say programming C++ on windows 2000. If I do a search for C++ material I don't want have to be reliant on searching
the mobile C++ APIs and guessing whether the function works the same on other window versions.
8. Learning Resource. IMO the MSDN library has never been a learning resource. This needs to change - it is criminal for someone spending a lot of money (in the UK about $1500) for Visual Studio 2008 and then having to buy books to learn the
languages because there isn't enough introductory material in the help. When I started with Studio back in the days of version 3 or 4 we also had Borland C++ in the office. Both Borland and Studio were about the same cost, Borland came with buckets of documentation
and introductory material, Studio came with a CD that wasn't any help. Fortunately it wasn't my money so I bought some books. If I had been a hobbist paying out of my own pocket I'd have stuck with Borland.
I thought the discussion about market penetration/pricing model was flawed.
One of the fundamental reasons that the market penetration for tools produced by the likes of Compuware et al is so low is the cost.
I have worked for big (70,000+ employee) and small (8 employee) organisations and the "good tools must cost a lot" argument in my opinion doesn't stack up. Also I've found bigger organisations actually spend less per developer.
You want market share - stack em high - less em cheap to paraphrase a well known saying.
Incidentally here in the UK the predicted cost (around £1700 = approx $3000 US per user) of Team System made the front page of Computer Weekly. The article made the point that at that cost not many people are going to buy into it.