Tag and Recommender widget considerations

Within the project proposal of the DEVELOP project two different functionalities / widgets are mentioned, which both are conceptually working with the content of courses within Blackboard (BB), making it easier to navigate and find content for students.

Tagging, within the context of the proposal, should be available to the instructor of a course to tag content and therefore create a different / alternative structure within the course content, making alternative ways for students to find and learn from the content. The recommender functionality is then a widget that recommends content to students based loosely on interests and/or statistics of the students.

In the scope of this post I’d like to present a few considerations concerning this:

Tagging: It has been proposed to allow tagging for students, allowing a flexible individualised tagging platform within BB. This is an attractive idea, which several 3rd party companies have already created tools for, i.e. Scholar (specifically for BB).

There are several problems with this within the scope of this project is:

  • It presents a completely separate use-case scenario, which constitutes a separate widget functionality. It might not seem so, but actually allowing a lecturer to tag content within a course, compared to allowing students to do the same across BB presents a huge difference in scope and difficulty. The biggest being the scope of viewable content. How should the system practically present content that the student has tagged that suddenly become non-reachable because a course has been made time limited? Or how should the tags be shared between students with different rights? More technically problems arise when looking at how to induce functionalities to tag content, which the user doesn’t “own”. The newest service pack from BB v9.1 has a non-documented, first draft, API for doing this, that George Kroner from BB has shared with us. The tech team is concerned, however, that if the solution relies on this, that it will change in other service packs thus deeming it unsustainable in the long run. For instance even a small (and very likely) change in this “library” will make the functionality unusable, maybe even break it so that it doesn’t work at all!
  • URLs are not used in an open way within BB because it heavily uses iFrames. This is a technical problem, which really makes it practically impossible to link to content within BB from the outside world. This means that it is difficult to tag content using services such as delicious and diigo consistently between different users. This is the main reason why this, that the student related tagging problem arises. It is also difficult to reuse the tags, in a meaningful way, outside of the scope of BB, especially when sharing them with 3rd parties, which is highlighted if one think of the problems of content becoming unavailable creating dead links. And if it was possible what would the legal implications be for sharing potentially copyright protected material to 3rd parties?
  • Scholar is enabling student tagging already, and it seems wrong to do exactly the same as a third party provider, unless there is a very good argument to do so, e.g. they have gone out of business, their functionalities aren’t covering what we need (i.e. they don’t support lecturer tagging in a structured way for students) or there is a need to open the functionality in an open source environment.

Recommender: It was the idea from the beginning that the recommendation functionality would be based on the tagging functionality (I personally contributed to that part of the proposal), and it would use the tagging “connections” somehow to allow recommendations. If the tagging and recommendation functionalities were to be separated it would result in a desperate user experience where the tagging and the recommendations wouldn’t be connected to each other, and it seems that it is a mutual beneficial situation to connect these in some way allowing a richer user experience.

The scoping documents of the project have suggested to connect the tagging and recommender in one building block. This does not imply that it becomes the same functionality, on the contrary, what it means is that the recommendation functionality can easily build on the functionalities of the tagging.

The current (first) recommendation prototype functionality is a feature which enables students to “bring in” or “point at” content from outside sources sharing links with other students/instructors based on the tags that the course instructor has set up. This actually provide some of the benefits of student tagging (although not fully) to the tagging functionality, thus allowing an explorative learning experience within BB. We have showed this to both Cindy Becker and Karen Ayres who both saw some interesting teaching angles to this approach.

The technical benefit of doing it this way, is that we remove the flexible functionalities from the (awkward) content management approach, which isn’t based on URLs, within BB, thus potentially enabling a wider and easier extension of recommendations. For instance it will be possible to extend this to include outside tagging folksonomies such as delicious tagging repositories, if the user is already using these.

I hope this describe the current considerations of the tech team, and I’d be very happy to receive critique and suggestions.

This entry was posted in Recommender, Tagging. Bookmark the permalink.

1 Response to Tag and Recommender widget considerations

  1. Guy Pursey says:

    Thanks for writing this out so clearly Karsten. I’m only just catching up with the blog and project e-mails since returning from Leeds but this lays out the reasoning behind the two widgets’ relationships to one another very well.


Leave a Reply

Your email address will not be published. Required fields are marked *