Keeping the Dev Centers Fresh with Social Bookmarking

Keeping the Dev Centers Fresh with Social Bookmarking

  • Comments 6

Last week Chris Slemp from MSDN/TechNet interviewed me and 3 other top bookmarkers about how we use the Social Bookmarking Preview and how we'd like to see it evolve. In this post he also has some interesting stats and analysis on how poeple are using social bookmarking (scroll down for the interviews).

To be honest, I don't really think about social bookmarking all that hard, it's become part of my routine (and I'm hoping others in the community start to feel that way as well). I use it for organizing all the great content I produce and manage so it's pretty easy for me to be in the habit of tagging things.

It's also made the Dev Centers a lot easier to maintain and keep fresh so I'm loving it. Give it a try, the more you tag things "Visual Basic" the more great content will show up on the Visual Basic Dev Center Community Page through this feed. This allows everyone in the community to see what Visual Basic content is popular anywhere on the web. Pretty cool. Of course there are still features to add and bugs to fix but I think it's a great preview so far.

Enjoy!

Leave a Comment
  • Please add 3 and 3 and type the answer here:
  • Post
  • PingBack from http://blog.a-foton.ru/2008/07/keeping-the-dev-centers-fresh-with-social-bookmarking/

  • Hi

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

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

  • 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.

  • 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.  

  • 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

  • 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.

Page 1 of 1 (6 items)