The Great Child Blog Opportunity

Currently, the Blog module implements a concept called “child blogs”.  These are sub-blogs of a parent blog, which are broken out in the user interface as separate sections, each with its own administrative rules.

Since the Blog module doesn’t currently support the idea of categories or tagging, a lot of people use the child blog functionality as a means of providing a categorization function.  In fact this is often the recommended use of child blogs.  IT Crossing’s lovely metaPost product takes this one step further, by integrating the categorization function in LiveWriter to the child blog capability in the Blog module.  Unfortunately, this misuse of the existing functionality is going to have to change, and the sooner, the better.

Currently, the Blog module implements a concept called “child blogs”.  These are sub-blogs of a parent blog, which are broken out in the user interface as separate sections, each with its own administrative rules.

Since the Blog module doesn’t currently support the idea of categories or tagging, a lot of people use the child blog functionality as a means of providing a categorization function.  In fact this is often the recommended use of child blogs.  IT Crossing’s lovely metaPost product takes this one step further, by integrating the categorization function in LiveWriter to the child blog capability in the Blog module.  Unfortunately, this misuse of the existing functionality is going to have to change, and the sooner, the better.

What the Hell is a Child Blog Anyway?

I can’t read the minds of the original designers.  However, a peek at the database helps to shed some light on the issue, and it reveals an altogether different (and better) purpose for child blogs than categorization.

Child blogs are implemented as complete blogs in their own right, the only difference being that they have a “ParentID” that points to an uber-blog.  This parent-child relationship allows child blogs to “roll up” into a parent blog in a very useful way.

Why is the child blog structure a poor place into which to pour the concept of a category?

1. Blog entries can belong to more than one category / topic
2. Categories, as a concept, do not possess all the other managerial attributes of a blog (e.g. “allow anonymous comments” is not an attribute of a “category”)
3. Categories do not have “owners”
4. There can be more than one category hierarchy (for example, an auto-review publication might have an index of cars by manufacturer, and another index of cars by car type)

It seems apparent to me that a category scheme for blog entries ought look a lot different from that of a child blog.  In summary, there ought to be an organized list of category “topics”, with a many-to-many relationship between blog entries and topics.

What, then, are child blogs?  And how should we steer their use going forward?

To me, it’s clear that child blogs represent “sub-publications”.  In a large publishing organization, say, a newspaper, different sections of the paper are managed by different organizations.  They all roll up into a single publication, but by and large each publication is an almost stand-alone entity.

Consider the sports section of a major newspaper.  It has its own editorial staff, its own submission policies, maybe even its own index.  There really isn’t any reason that it couldn’t be sold separately as a sports-only specialty newspaper (and some are), except for the fact that it’s bundled together with the rest of the content.

Or consider the test-drive section of a car magazine.  There is a dedicated team of reviewers who do nothing but drive and rate cars.  They have their own procedures for this.  They’re answerable to a Practices editor who manages the review practices for fairness.  They have their own team of people who manage the pipeline of new cars that need to be tested and evaluated.  Really, there could be a publication that is nothing but car reviews, except that the auto magazine has decided to include it with all of the other sections in a bundle.

I think it’s clear that child blogs ought to represent “sections” – pieces of the publication that are broken out for arbitrary business reasons, and not necessarily because they relate to common topics.  Now, a given publication might very well like to split out its publication according to some major topical divisions, and child blogs could be the right way to handle this task.  But in this case it’s simply a coincidence that child blogs are split out according to major topical divisions.

The other thing that a child blog shouldn’t necessarily be is a set of entries by a given author.  Of course, it may be useful in a given publication (a moblog, for example) to give each author his own child blog and let each one be individually managed.  But it shouldn’t be necessary.

Child blogs really map to the idea of organizational structure.  Some companies are organized by product.  Others by function.  Some are organized geographically, others by technology.  Some are split in order to serve government customers separately from private industry.  In every case it’s a mistake to confuse the org structure (e.g. “product organization”) from the thing itself (e.g. “actual products”).  Likewise, child blogs ought to be used to solve the arbitrary managerial or organizational needs of a publication – which may map to high-level topics or authors / author groups, but only by coincidence.

Get to the Point Already

Where am I leading this?  Let’s get to the punch line.  I want to separate the semantics from the presenation.

Categories and tags – which I am increasingly beginning to think about collectively as “topics” – represent ways to chunk the content by its meaning, organizing it hierarchically (as with a category) or flat (as with a tag).  There are different user interface widgets we can employ to get at the content by topic, including widgets that display “index views”, widgets that display “tag clouds”, and widgets that display “related entries”.  Ultimately, however, we’re just talking about different ways of doing the same thing – grouping entries by topic.

Child blogs – which I am increasingly beginning to think about as “sections” – represent ways to chunk the content according to arbitrary managerial need.  Child blogs should allow a large publishing team to segment the ownership of pieces of the publication and roll up the content into a coherent whole.  In fact the current design of the Blog module comes surprisingly close to this goal.  If any workflow capability is attached to the Blog module, it’s clear that child blogs represent the set of structures needed to pull it off, each offering its own set of editors and authors, approval workflows, roll-ups to parent teams, etc..  As with “topics”, there are different user interfaces we can employ to get at the content of “sections”, including widgets that allow individual child blogs to live on different DNN pages (each with its own look and feel) while rolling up to a “summary” page elsewhere, widgets that roll up the child blogs together by section (rather than grouping all the content together chronologically), or widgets that provide category “indexes” within a given section (like a sports section index).  Ultimately, however, we’re just talking about different ways of organizing content according to an arbitrary managerial need.

Authorship – which needs to be thought about independently from “blog ownership” and “sections” in a multi-author publication system.  Authorship is an attribute of an “entry”, while “editorship” is an attribute of a “section”.  While a given publication might create a different “section” for each “author” (e.g. a moblog) I think that ought to be the exception instead of the rule.  A given author might create content in various “sections”.  Yet there remains a need to be able to find content by author.  Ideally, we should provide widgets that can display content by author – even allowing a publication to create “author pages” – without necessarily creating a child blog for eah author.  So, for example, a moblog like CuzWeSaidSo would probably create one section per author – because that’s the idea behind the publication – whereas a product-review magazine like ProRec would have sections like “From the Editor”, “Product Reviews”, and “Industry News”, with a given author publishing content in any or all sections.

The Pain of Change

One reason I mentioned metaPost earlier in the article is because I believe that improvements in the blog module, as well as its support tools like metaPost, will lead more people to choose the DNN Blog module for their publication needs.  Let me be blunt: what we have now is a sort of bastardized system that solves none of the above problems well at all.  The longer we go on without making these critical structural changes, the more we doom the Blog module to a second-class existence.  Conversely, the sooner we tackle these problems, and the sooner we address the pain associated with making these changes, the easier it will be.  Delaying these changes only means more pain later on.