Keeping the Dev Centers Fresh with Social Bookmarking

Comments

# a-foton » Keeping the Dev Centers Fresh with Social Bookmarking said on July 22, 2008 3:34 PM:

PingBack from http://blog.a-foton.ru/2008/07/keeping-the-dev-centers-fresh-with-social-bookmarking/

# seema said on July 23, 2008 4:55 AM:

Hi

Your blog is very informative n helpful .. thanks…..keep it up.

<a href="http://www.seostep.net">www.seostep.net</a>

# cslemp said on July 23, 2008 12:06 PM:

I hope that everyone doesn't have to think about it hard either, Beth :) It should just be part of the standard workflow on the web.

# Greg said on July 24, 2008 6:27 PM:

Tags work great but are no substitute for indexing reference material/technical documentation on a professional basis.

Secondly, relying on tags and blogs instead of producing professional level framework, API documentation is not a good thing.  Blogs, tags, etc. decay and dissapear.  Technical documentation at a professional level does not and given the 5+ year lifespan of an API call makes more sense.

Third, relying on video to teach new topics is ok but does not get rid of the requirement to produce  professional written technical documentation.

Writing good professional level technical documentation will force OS, API, techology  producers to make higher quality products.  

# Beth Massi said on July 24, 2008 6:48 PM:

Well said Greg and I totally agree. This is exactly why we feature the social bookmarks on the *community* page. Microsoft library documentation will never go away, that is the authoritative content. However when was the last time you found a solution from the community, like on a blog for instance? We need both.

Personally as a developer I search the internet for any code I can get my hands on to try it out. A lot of times I find better code from the community than in the library. And wouldn't it be nice to see what other people like me are reading? what are the ratings? etc? Social bookmarking creates an ecosystem of content and people and it's pretty cool, but not to replace the library, I agree.

Cheers,

-B

# Greg said on July 25, 2008 2:28 PM:

I use the usenet group microsoft.public.dotnet.language.csharp and microsoft.public.dotnet.language.vb mainly for community content via google groups (sorry, the MS search feature for groups is overly slow and requires much more paging through topics to find useful posts).

The groups avoid the spam, registration needed and especaially articles that just parrot a MSDN page.

My original comment on professional level documentation with decent professional indexing is prompted by two things a) I've been surveyed on the MSDN web site with what appears to be a set of questions to ask whether or not MSDN should be organized as user linked/tagged documents (facebook) style or have indexed API/technology documentation.  The second reason is that .NET 2.0 framework API documentation in many areas is little more than what you would get by reflecting over the DLL assemblies and emiting all of the fields, data types, names into HTML.  This is more disheartening because that means that many API calls have no useful documentation other than fucntion signature.  

The image file handling, creation, compression, parameter setting, etc. parts of .NET are poorly documented for example.  Find how to open a TIFF file and save it as a jpeg with compression quality level 80.

I'm impressed by the overall .NET framework quality and thank you guys for it as it's been much better to me than the years I spend doing win32 and U*nix GUI, device drivers and system level programming in C / C++.    

I've rated and tried to make useful commments on many of the .NET api documenation pages with emphasis on providing better quality sample code and descriptions.  These suggestions seem to go nowhere since it appears that the documentation for the current framework version is not really updated for 8 months before the new frameowrk version is released.  This means that releasing a .NET framework every 16 months or so means you do not really update/improve the documentation other than in trivial ways once a framework api version is released.

Can we get consolidate documenatino that lists the .NET frmamework 3.5, 3.0, 2.0 and 1.x all on a single page with older topics archived at the bottom of the page.  That would make it easier to see that many API help pages could be comined since framework versions 1.x, 2,0 and 3.0 are almost idential for basic operations (e.g., file io).  This will cut down on the multiple duplicate and near duplicate search results youget for for API name searches.

Leave a Comment

Name (required) 

Your URL (optional)

Comments (required) 

Remember Me?

About Beth Massi