Owning Comments..

We (Kele, Alison, Michelle C. and I) had an interesting discussion the other day that was focused on how we evaluate e-portfolio systems that wandered (of course) into all kinds of things…

One of the thoughts I wanted to capture and remember though, was the comments discussion — it pointed to one of the differences between weblogs and e-portfolios or perhaps the challenges associated with morphing a weblog system into an e-portfolio system.

It kind of harkens back to an earlier post on the need for a robust content management system under the e-portfolio hood.

A robust e-portfolio system allows you to store objects — which can be a variety of things like pieces of information (e.g., your name, employment history, education, etc.), artifacts (files, sets of files, etc.) or reflections (often associated with a specific artifact) – in a database (your working eportfolio). Then, using the presentation tools of the eportfolio, arrange a subset of these objects into a private or public representation (in a web based portfolio — a web page). This flexibility is quite nice — you can specifically tailor a view of your e-portfolio to a particular audience. You can invite someone to review this “instance (view)” of your e-portfolio. For web-based e-portfolios, the reviewer goes to that specific page, and comments/reflects on what they see.

Now who owns these comments?

In a weblog system, comments on posts inherently belong to the person who owns the weblog. If you want to maintain rights over a comment, as Michelle C. pointed out during our discussion, you would post on your own blog, and use a trackback.

Some weblog systems allow moderation of comments (I as the weblog owner can approve your comment for display).

In an eportfolio system, particularly in an instructional context, “comments” translate to what a reviewer does. More mature e-portfolio products, allow the “reviewer” to specify whether or not a comment in an eportfolio can be made public. In addition, the e-portfolio owner can decide to publish a comment or not.

Mental note: We usually think of this as an instructor making comments on student work, but this should also apply to a colleague (fellow student) commenting on another’s work. As we evaluate product requirements I think we need to check how this reviewer capability actually plays out in products. In products dedicated to instructional context, often there is a layer introduced where the instructor has more capability than the student. This drives me nuts sometimes with some course management systems — give the student more capability and ownership and gosh, it’s funny what happens… (but I digress).

So in this case – when we look at the capability of a product, we need to make sure that students have this same right of control on their comments… need to check this out in our requirements matrix…

In an eportfolio system, then, we should think about building/looking for a dual capability into the systems:

  1. the capability for public comments (typed directly into a specific eportfolio “instance (view)”) like a weblog has, where the person does not care if others see the comments and cedes control of the display of the comment to the owner of the e-portfolio.
  2. Create a new “comments” content type within the e-portfolio database – (in addition to artifacts, reflections, templates etc.).

    Actually, a comment could be considered a subset of “reflection” — it is different because rather than being viewed within the owner’s eportfolio, it would be viewed within another’s e-portfolio.

To me, what is interesting about this new content type is that whether or not a comment is displayed is not as much a permission issue as it is a negotiation between the two e-portfolio owners:

  1. Owner 1 invites Owner 2 to comment (reflect) on a specific e-portfolio
  2. Owner 2 elects to comment, then decides if the comment (reflection) can be shared
  3. Owner 1 reads Owner 2’s comment/reflection, and decides, if owner 2 has permitted public display, to release the comment for display.

These objects would live in an interesting space between two the owners of the e-portfolios — only shown with the tactic agreement between the two parties.

Technical thought.. we’d need to think about data integrity (what would happen if Owner 2 disappeared from the system?)…

Maybe (probably) people already have thought of this…

mainstream portfolio products have this capability, but I don’t know if it is thought of as a “content type” in the database…

This post is more for me to record these thoughts so that I remember to look for this functionality as we evaluate systems/processes.

As we develop our own blogfolio concept, we may want to think of this key requirement of ownership of “comments”… and build a flexible capability into the systems.

Thoughts on a Saturday…

This entry was posted in Electronic Portfolios. Bookmark the permalink.