In a previous post I talked about the rationale and need for thinking about a taxonomy of educational aggregation projects. Something that I haven’t really given a lot of thought to, just yet.

About 15 minutes ago I posted this about “cooked” course feeds. WordPress.com’s “possibly related posts” feature (where it automatically appends 3 or 4 other posts from WordPress.com blogs which it deems to possibly related) included a link to this post entitled “Prologue as an eLearning Blog Portal”.

It’s a post by Mike Bogle in which he outlines one of the key problems we saw with using blogs for individual student reflective journals.

the main challenge for educators using blogs in their courses is how to keep track of them all. By nature blogs function completely independently of one another, so the prospect of monitoring the individual blogging activities of several dozen or more people presents a substantial time investment for instructors and students alike.

In the post, Mike outlines some problematic solutions before suggesting that the use of Prologue as a way to create a blog portal. The aim being create a “dynamic, interactive student network”.

It’s this purpose and some of the features Prologue provides and the possible applications these features can support that seem to suggest another place in a taxonomy of aggregation projects.

The “portal/community” aggregator

What Mike is suggesting could perhaps fit under the title of “portal aggregator”. Perhaps community rather than portal might be a better label – portal has too many connotations from the late 90s and corporate Web 1.0 centralised IT constraints. After all, the purpose of the suggestion is to enable the creation and maintenance of a community.

Community aggregators tend to provide many of the features Mike mentions including various filtering options and the idea of social tagging of posts.

This seems to be the category into which EduGlu would fit. There is now even a EduGlu sandbox which allows you to play. The workflow image in that post provides a good representation.

Perhaps this type of workflow might be the way to differentiate different aggregation projects?

Based on the little I know of it, I believe that Cloudworks probably belongs in this category as well.

What’s the difference? Is there one?

Suggesting a need for a taxonomy of aggregation projects assumes that there are different types of projects. The “community aggregator” approach seems to be fairly general, perhaps general enough to provide all of the necessary features. At the moment, I think not. I think some aspects of BAM identify a potential difference, though there is also some overlap.

So what’s the difference between BAM and tools like Cloudworks, EduGlu and Prologue? Well, apart from the quality of code and implementation, I believe the main differences are

  • An initial focus on the individual student.
  • The integration of institutional needs.

A focus on the individual student

The original rationale and design for BAM was to support and improve student usage of individual reflective journals and enable academic staff to be aware of student progress. i.e. the only people directly and regularly reading the student blog posts was their tutor. Hence the social aspects of filtering and tagging aren’t in BAM, because they weren’t immediately useful.

There are plusses and minuses to this approach. There would certainly have been benefits for student reflections to be seen and commented upon by other students. But there also would’ve been negatives.

In terms of Mike’s post the emphasis in BAM was on helping staff keep track of individual student blogs, rather than creating a “dynamic, interactive student network”.

That’s not to say that BAM can’t help support this approach. It was used to implement a simple form of the community approach for the portfolio and weblog networks on the Creative Futuring course site. But without the tagging and filtering.

Integration of institutional needs

D’arcy Norman in his post on EduGlu describes the magic combination of features for EduGlu as

Aggregation of feeds + Groups + Social Rating + Tagging

A summarised version of a similar magic combination for BAM would be

Aggregation of feeds + institutional needs

Where “institutional needs” gets expanded out into:

  • Institutional data;
    Students register their blog with BAM. BAM associates their student number and course with their blog. This then allows BAM to determine which staff member (actually its which hierarchy of staff membrs) is responsible for the student. It associates the use of the blog with the specific assignment for the course. This is all drawn from existing institutional systems and processes.
  • Institutional services; and
    The institution already has services such as a staff portal, online assignment submission and results uploading. BAM integrates the use of the blogs into these systems. BAM provides a marking interface for the student blog posts. The staff member accesses this interface through the staff portal. The marks are available via the online assignment submission and then at the end of term are integrated into the end of term results processing system.

    All this minimises work for the staff.

  • Institutional requirements.
    One of the most common concerns raised about using a blog service that is not serviced and hosted by the institution is the “dog ate my homework” fear. i.e. what happens if the external blog service disappears and the students’ blog posts are lost? To address this concern, BAM maintains a mirror of the RSS feed from student blogs on a institution system.

Where does BAM fit?

Does this mean that BAM is an “individual” aggregator? An “institutional” aggregator?

That type of labeling doesn’t seem to work all that well. Suggestions?