November 04, 2005

Towards a Managed Social Bookmarking Environment in Higher Education

As followers of this blog will know, one of the topics I keep doodling about is social bookmarking in an academic context. In this post, I want to start considering how we might use such tools at scale in a managed environment.

A couple of services promote themselves as being directed towards educational users (I'm thinking of Scuttledu - Online Bookmarks Manager for Educators and Connotea in particular) but at the moment their focus appears to be on recruiting individual users, rather than offering a 'solution' at a cohort or even institutional level.

So - let's get to it: a first stab at identifying some of the issues that are likely to arise when considering how to integrate a social bookmarking system into a managed, institutionally administered, loosely coupled VLE. The sort of environment where it falls to sysadmin to says who's allowed where, and possibly also who can say what.

Just to ground my thoughts, I shall assume that the system we're going to adopt will be something based on Connotea, in part because the code for an early version at least has been released under an open content license (you can download the Connotea source code from Sourceforge).

To provide even more context, let's assume that we're might want to use the social bookmarking within an institution in the following ways (this list is not necessarily complete):

  1. By registering all the students on a particular course to the system so they can use it in course related exercises;
  2. By registering every student who joins the institution so they can use it as a resource throughout their registration period, and even beyond (i.e. when they graduate);
  3. To allow the system to integrate with pre-existing authentication systems;
  4. To allow students to share knowledge between cohorts (e.g. so one year's coohrt can leave a legacy to the next cohort);
  5. To provide an environment where student project teams or tutor groups can share bookmarks and comments privately amongst themselves;
  6. To provide a bookmarking component in an e-portfolio system;
  7. To maintain a needs-serving link with graduates/alumni by continuing to host their bookmarks (perhaps supporting this service by advertising relevant courses or fundraising initiatives to such alumni at a future date;-);

Additional constraints may arise as a result of working with particular cohorts, such as minors or vulnerable groups.

For example, suppose that there is a requirement to ensure that all bookmarks are moderated. Let us assume that there are several possible levels of moderation:

  • strong moderation, by which we mean that a moderator must approve every link before anyone can click-thru it (including the person who saved the bookmark);

  • intermediate moderation, in which a user may follow their own bookmarks but a moderator must approve them before they can be shared; and

  • weak moderation, whereby bookmarks may be shared within a group but must be approved by a moderator before they can be made public.

  • no moderation - users are free to bookmark what they like and may choose whether to keep it private, share it with one or more groups, or make it public.

Taking Connotea as an example, how might we implement these various levels of moderation?

In the first case - strong moderation - all bookmarks could be held in an 'awaiting approval table', which contains all the fields used to store a bookmark, plus the user's ID and a moderation approval state flag. When a moderator approves the message, the 'approved' flag is set and the bookmark can be saved to the user's bookmark list.

In the second case - intermediate moderation - the bookmark would be saved to the user's bookmark list as a private bookmark AND a lock would be placed on the bookmark preventing the user from sharing it (this could be managed within a 'lock this bookmark' table recording the user and bookmark ID, and the lock state). If the user attempted to share the bookmark, the system would first heck the 'bookmark lock' table to see if the bookmark had been opened up by the moderator for sharing. In terms of usability, it would be courteous to inform the user when a bookmark had been enabled for sharing, or even automatically share it as soon as received approval if that preference had been previously expressed by the user.

In the third and final case - weak moderation - the lock state within a lock table may be used to characterise the level of locking applied. For example, one might imagine being able to lock the shareability of the bookmark to the extent that it was locked against public sharing, locked against sharing with one or more specified groups, or opened up to sharing with particular groups (and by implication locked against sharing with all other groups).

There may also be a place for an enforced privacy regime in which users are not allowed to share bookmarks with each other at all, ever, yet still require strong moderation. A 'bookmark lock' table would be enough to support this facility.

A weaker view might enforce restricted sharing in which the user was only allowed to share bokmarks with several groups. Once again, a 'bookmark lock' table with lock states set for each group ('shareable', 'shareable when approved', 'not shareable') should be enough to support this facility.

For completeness, we may also want to consider the extent to which comments may be shared. The simplest assumption, of course, is that comments and links share the same sharing privileges, but this is not necessarily so. For example, there may be occasions in which you want users to share links, but keep their comments private, perhaps until some embargo date.

How would students use such a system, and what sort of sharing should be encouraged (for example, should we have global public sharing, sharing within cohorts but not across years, sharing within tutor groups but not between tutor groups and so on)? Allied to this are questions relating to providing users with default tags to tag resources (i.e. tags which are automatically applied depending on student context).

Scuttledu takes the approach of automatically tagging resources with a grade level identified from a user's personal profile. It's easy to see how such a technique could be used for a student on a particular course, but problems arise if a student is registered on more than one course at a particular time.

Another approach may be to follow services such as del.icio.us which offer recommended tags to a user whenever they bookmark a resource.

The provision of separate bookmarks for a student to bookmark resources with different default tags (e.g. different bookmarks for each course, or for just personal use) is another possible strategy. (I'm not yet clear how much further this could be taken by embedding bookmarking tools in a browser, for example as Flock has done.

Finally, I guess I should also say why we might want to run a social bookmarking system in such a managed, or controlled way? Some of the reasons that come to mind (mostly as a result of my uninformed, stereotyped view of central computing services and beancounter' views in general!) are as follows:

  • social bookmarking could become a value-adding service, the reliable provision of which forms part of the institution's contract with the student; as such, liveness and reliability need to be guaranteed; uniformity of provision (and a guaranteed high quality of provision) to students

  • if social bookmarking is to be introduced as part of the learning strategy, some would argue that its use needs to be carefully managed to ensure that it is capable of delivering whatever the learning designer requires; (unfortunately, this approach reminds somewhat of unintended learning as a bad thing);

  • integration with other cohort related batch processes (e.g. registering all new students, or setting particular group privileges for a particular cohort);

  • Educational establishments need to be wary of what gets published on their domains. List of links to adult resources, for example, are unlikely to be tolerated.

It will fall to another post for me to reflect a bit on the contents of the lists braindumped above...

Posted by ajh59 at November 4, 2005 06:15 PM
Comments