Forum .LRN Q&A: Response to An educational blog app

First of all, I don't think that the app itself has to (or should) have a publishing mechanism in it. From a functional perspective, yes, users need to be able to publish up the community-level hierarchy. However, that's actually a general problem throughout dotLRN, and I suspect that we'd want a generalized publication mechanism that could be utilized by this and other apps. In other words, we need to think about publication in our design considerations here but we don't necessarily need to cram that functionality into one piece of code.

Second, I'd want to put pretty sharp bounds on the degree to which we think of this as a document management tool. For the most part, I'm imagining that the typical content item that would be hammered out for group consensus would be something the length of a typical blog entry or discussion board post. Now, you could certainly use the tool to discuss document drafts, but I think management of those drafts themselves probably belongs in a separate module, like file-storage.

It might be more accurate to say that I want to build an app that helps manage the workflow of the conversation. Do you need to build consensus on an idea? Do you need to have occasional feedback on your train of thought as you develop it? Do you need a strong moderator who can close one avenue of conversation and open another one? Different educational conversations have different flows to them and correspondingly different traffic rules. What I'm really casting about for here is an app that shows some sophistication in terms of supporting those different traffic rules.

As Stephen points out, what this could end up looking like is a highly configurable threaded bboard with some blogger-like features (e.g., referrals) thrown in, and maybe a collaborative rating/voting system. At set-up time, you allow the instructor to decide who can start threads, who (if anyone) can end them, and how the threads are displayed in the UI. S/he also decides whether the participants can rate (or vote on) each others' posts. That's pretty much it for the app itself (though the devil is in the details).

For publication, you can pretty much hook into the ratings system, particularly if it can distinguish who did the rating (as is the current proposal for general-ratings). You have an aggregation portlet at the class level that pulls all content items that meet certain ratings criteria. Maybe it pulls all the ones that were flagged by the professor or TA. Maybe it pulls the ones that got the highest aggregate rating from the members of each group. Etc.

I recognize that there is a real danger of an overly broad scope here, and it may turn out that a blogger is a blogger and a bboard is a bboard and never the twain shall meet. However, I do think it worthwhile to make sure we're not being overly narrow in defining the educational problem we're trying to solve.