Blogging Portals - useability and finding stuff

Tonight I was feeling really crappy about MS Project.  I was thinking about all the ways that I'd just love to get the box and squash|crush|kill|destroy it... {some mental karma excercises}... ok, better now.

Anyways, after a while I thought, "No!, I'm wrong, I must find the blog of the MS Project PM; read it; learn about project management and inner peace and be a better person.".  So!  Do you think that I could find the blog of the MS Project PM?  No, I couldn't.

You wouldn't think that it would be that difficult really.  I mean, this is a portal full of MS bloggers.  Now, either I'm right and the MS Project PM is so busy trying to work out how to use the product that they don't have time to blog about it, or, Weblogs just aren't good enough at providing layered services over their aggregated content.  This ties in nicely with some thoughts that I had about blog portals back in June:

     http://weblogs.asp.net/dneimke/archive/2004/06/02/146261.aspx

... and, on a similar note, Justin's follow-ups a few days later:

    http://weblogs.asp.net/justin_rogers/archive/2004/06/05/149336.aspx

1 Comment

  • To clarify my post with respect to this problem, the act of categorization alone doesn't necessarily solve the visibility issue. Visibility is all about aggregation and having a way to logically display grouped data in a short, terse form that is easily navigable by the user... A couple of data groups might be:



    1. Authors

    2. Teams

    3. Keywords



    Can categorization in turn bring these groups to surface? Well, authors is easy right. It is nothing more than the blog roll itself. Searching by an author is trivial. Some blogs have multiple authors though, so you should take this into account. In general parsing an existing RSS feed is suitable for #1, assuming you know the authors name and they've applied the appropriate adornments to their name.



    Teams is a bit more difficult. How do I lock down the entire Teams categorization to prevent fraud? Well, that is something the categorization engine has to think hard about. First, does it really matter if someone shows up on a team listing when they really aren't? What happens when a user changes teams, or are members of multiple teams? There are security models for this entire process. For instance, the categorization server can easily ensure guid/author combinations allowing the blog reader to validate a feed item. Now someone has to admin the categorization server, but the process of having one, where people can create teams and allow users to join isn't hard. In fact, MS can host their own, and the public can have a version.



    What about Keywords? Keywords are best aggregated by searching the content, but sometimes the content never mentions the *category* or *keywords* that the author thinks is important. Keywords/categories can also be scoped so that the Performance category type in my local blog is different from the Performance category type in the global index. This last grouping identifies the need for some global control over the categorization and keyword process. Otherwise blog readers can't effectively process content into meaningful categories for the client. The other option is that group categories into local categories is really a one time process. Only when you see a new category on a post, must you actually do something, this is really just another simple screen with a listing of posts, categories, and the identity of being unassigned to local group. A default local group of uncategorized can be used when you don't care to aggregate a category into a local group. Remember here that the general hiearchy is still in place where you can go read all of the postings for a specific blog, the goal here is just aggregating, at the client level, a series of blog posts into a reading or search group when you don't want to have to read the contents of every author's blog.

Comments have been disabled for this content.