KNotations

First off, note that some of the categories for this post have "kind=" prepended to them. This is my way of exploring the social and writing 'feel' of using multiple kinds of metadata for categorising entries and resources. In brief, I feel that my own blogging would be improved by being able to denote for a post not only what it is about, but what it is, what kind of communicative purpose it is intended for - eg whether I worked hard on this as considered prose, or spit it out as micro-documentation. There are many other reasons to want to allow multiple metadata schemata to be used (lord knows I've spent enough time in the dim past on this issue to recognise it :o), but at minimum it allows spontaneous writing while giving the reader a way to sort microdocumentation from serious writing.

I've dumped the rest of this long message into the extended text for the entry...

RE the proposed development of a system for discussion and agreeing categories:

I was hoping to actually implement discussion of categories as-categories this weekend, ahead of launching the upgrade to the sigossee site and deploying Alan's work-related learning activity tomorrow. But it's been a ton of work getting the sigossee site upgraded, and I won't be able to do the changes to the trackback system needed, let alone all the extra little templates and query methods :o(

On the other hand, it occurred to me early this morning that, instead of linking categories with entries with trackback to effect the 'other direction' of associating entries and categories, we could either have a special subclass of entry, or just a flag to say that 'in this post, the post is about the categories, not the other way round. Then we could assign a pseudo-category to these entries of 'discussing categories', and render special links for the categories into the entry - pointing to an aggregation interface which shows discussion of those categories etc.

The obvious flaw with the simple flag approach, is that it is easy to envisage cases where there are some categories about the entry and a different set which the entry is about. I shudder at the thought of subclassing the entry types - especially at the thought of making the entry forms even more complicated, but this might be the right approach. there are plenty of other cases for which I've thought of subclassing post : events for instance, or XML structured data like our old lit-review objects.

Needs more thought :o)

Of all the many dozens of features we've worked hard to add to knotes lately, and found no time to document as they were added, why am I bothering to document this one? Because it illustrates a point: basing knotes on a robust existing suite of site-manaagement tools like Plone does make it easier to wrap our work in a context of existing features. This of course does not change the fact that the main advantage of leveraging Zope, the CMF and Plone is placing knotes content and users in the context of community sites and serious content-building.

As noted in the lead-in, I've just added a send-this-entry link in the blog entries template. It appears at the far left of the posted information below the content of an entry, and took exactly 3 minutes to implement (and that was mostly spent double-checking the id and size of the Plone mailto image :o)

Enjoy...

The release of a fully productised and robust core knotes has fallen a bit behind schedule recently because we've been very busy making use of it in some of the community portals we maintain, and in adapting it to new purposes. One very interesting use we've been trying out is as a framework for portal comments. Our users have always hated the default Plone talkback mechanism: 'Discussion Item' entries do not allow rich text, active links, attachments, or post-submission editing, and they tend very much to get orphaned. On the other hand, the idea of posting a comment is very easy and intuitive for most users, there is an affordance to do so right in the pages, and it provides a simple means for user to post their own writing in a prominent place (without understanding workflow, etc :o). We briefly tried using CMFBoard as a portal_discussion handler last year, but its treatment of the issue was profoundly misconceived, not to mention buggy and veeeery slow, and was disastrous in real sites. So we've made do so far with either turning off discussion_allowed, or with the robust but feature-poor default portal_discussion. Last week, we started experimenting with replacing add-a-comment with shared weblogging, and demonstrated this to some of the key editorial people in our main sites. For the first demos, all we were doing was displaying trackback details for pages instead of comments; as luck would have it, an interesting weblog post had been made about an article in the NGRF site, and the editors were blown away when they saw external commentary summarised in their page.

So we decided to go ahead with a very quick and dirty takeover of portal_discussion. We've done this in two new sites, and one site that already had extensive comments (we wrote a little script to make new weblog posts and replies to them from existing comments).

How to set up knotes for portal comments ( the quick & dirty way )

1 - make a new weblog to hold the comments

- This one is easy. Just add-item:WebLog wherever you can make Plone content. Of course, you'll probably want this somewhere prominent in the site content hierarchy, and prominently linked-to, perhaps from site_actions.

2 - give all site members contributor privileges to that weblog

- This is a bit tricky at the moment. It is very easy to give contributor permissions to a group or a set of members using the local role form (Weblog Contributor role), but giving all members the required permissions is a bit harder. We have implemented something similar for the moderation interface for discussions in knotes, but not yet for blog entries. You have to go into the ZMI for the weblog you want to allow all members to post to (not for the entire portal!), open the Security tab, and manually tick the 'member' column checkbox for the following permissions:

• Add Portal Content
• Add KNBlog
• Add KNLink
• Add KNExFile

3 - turn off the display of the 'Reply' content-action

We always hated this pesky content_action anyway, since it forces a box around content for logged in members who can only choose between the view and reply tabs. If you are going to replace talkback with blog-this-page by changing the viewThreadsAtBottom.pt template, you have to get rid of the competing action from default talkback machinery. In the ZMI for a portal, just open portal_discussion, then actions, and untick the 'visible' checkbox for the reply action. See the screenshot:

4 - customise the viewThreadsAtBottom template.

The viewThreadsAtBottom.pt template is what is called in page rendering by Plone to display the comments and add-comment etc content. A very crude, but working, replacement template is attached to this post: that template displays trackbacks instead of comments, and has as its form action for Add-a-comment the creation and editing of a new blog_entry, with initial link details filled in with the details of the page it is called from. A list of weblogs in the site which the member can contribute to is also provided; the comment will be posted into the chosen blog.

5 - import any existing comments

We have written a little python script to convert comments into weblog entries, and a little page template to call it from. The script takes as an argument the weblog to post into, which you enter from the form field in the rendered template. Run the convert_comments template FROM THE DOMAIN NAME OF YOUR SITE (eg www.my.domain.edu/convert_comments), and it will create weblog entries for all top-level comments (tracking back to the pages the comments were about), and making replies (as Discussion, not blog entries) to those new entries from any comments-on-comments threads. It will add entries in the members SQL table where needed. We've tried this in a production site, and it certainly seemed to work. It may take some time to run if you have many hundreds of existing comments - try it in a copy first!

6 - remove any aggregations you may have made of comments, for instance portlets

You probably do not have to worry about this, but if you have been displaying information about recent comments, or adding comments-on-items to listings, you'll have to take those out or change them to get their information from the trackback machinery instead of the talkback machinery (ie grabbing trackback entries from knotes' SQL methods instead of comments from portal catalogue :o) It is very easy, using CMFSin, to include a recent_comments portlet from the RSS for the weblog you use for comments. It is your choice whether to use the RSS with-discussion or without (knotes provides both options for syndication of blogs). Use the RSS rather than the atom feeds for CMFSin.

Ta-Da! In these simple steps, you've got a whizzy weblog behind your portal comments machinery. This makes it a lot easier to see comments as a whole, to post items which are not specific to a particular page, and to give a sense of community and activity. As a very useful side-effect, your site's pages will display any trackbacks they may receive from other sites, which can add a real sense of being part of a wider community of communities.

You can see this in action at the National Guidance Research Forum site. NB - this links to the NGRF Community Comments weblog instead of the NGRF top of site; I did not want to pollute the top-of-site trackbacks with links to technical posts like this (and knotes does not display top-of-weblog trackbacks yet :o)... please do not send trackback pings from technical blog entries to the NGRF top of site.

0.4.6 alpha - 20/01/05

Steve made radical changes to the SQL methods to protect against python-script in member-folder snoopers and hackers

Mike changed weblog aggregate view templates to clean out convenience links, make markup tighter, and leverage javascript to generate convenience links onload

Minor change to KNDiscussion class file makeRSS to pretty-print information about in-reply-to or blogname

Steve changed edit / fetch categories to break categories down by source (site, personal, blog)

- these show in API clients as prepend of 'site - ' etc

Graham has just noted a very good idea for combining communities of interest across different projects to share online portals. Noting that, with the online 'communities' built for small projects, the ...Problem is many of the so called communities have little to bind them together - other than that as individuals they have all joined an on-line community. But they do not 'know' each other - neither do they usually work together on a collective task..., he goes on to suggest an interesting new approach:

The answer - I think - is to encourage clusters of projects to share common community portals. These clusters which obviously need some areas of commonality in their work - could then focus the public areas on the services and tools their projects are producing - whilst economies of scale should allow the deployment of reasonably sophisticated communication environments for project development.

I've noticed, since we started see trackbacked comments and knotes weblogs in the NGRF site, that the potential for a sense of wider, cross-site community is large when two-way linking (trackback) allows discussion and commentary to span multiple sites. This will be very interesting to explore!

In other words, though each project may have its own online presence, the people participating in the project may participate actively in several other online activities; two-way linking can give a real sense of emergent communities which span several projects while growing the core content and activities within each project's site. I reckon both approaches are worth investigating, and that some combination of combined, multi-project portals, and multi-portal emergent communities will evolve.

Links to open by-category view appear in the entries and also in the categories sidebar.

When these have structure - like the one associated with this entry - it would be good to have each node in that structure as a separate link: eg 'development' / 'knotes' / 'categories' as 3 links.

This will bloat the pages a bit, but adds some value... perhaps js to traverse the links and split on the category names?

Mind you, until we have a taxonomy browser / editor for adding sturctured categories, it's up to users to discover that they can use '/' to make taxonomic structure, and this will likely not happen with many users :o).

We've been testing knotes in production sites for some time now, but only recently started having public blogs available to large numbers of tech-naive end users. The feedback has been extremely valuable, though much of their frustration comes from the absence of features we've long planned, but don't get time for because of site admin :o)

One of the problems users encountered was that they could not see how to reply to a blog post. We've just added some 'tips' which appear just below each entry. These explain what the 'permalink' and 'Discussion' links are for. We'll be adding more helpful tips and how-tos over the next week. We're also working on making the actions for replying etc more streamlined.

Changes are being made very rapidly at the moment - big changes to the categories and permissions system over the past two days which I must blog about sometime :o)

We hope to be in a position to confidently let strangers try to install, maintain and make good use of knotes by the end of January!

One of the main aims of knotes is to create good interfaces for resources: for the collection, annotation, discussion and tagging of links, files etc which members want to share among themselves or provide as a repository service. So far, we've had to concentrate hard on the basics of blogging in collaborative contexts, but for the big port of the SIGOSSEE site, we realised that we had to provide at least the beginnings of a resource-centric interface.

See the Open-Source in Education - Links and Resources weblog for an example. There is much work to be done yet, of course. We have not done anything about file resources, or for special search interfaces for 'resources'. But this is a step forward which we're hoping will allow SIGOSSEE members to really start adding and sharing link resources.

I just figured out something that makes me quite excited. Experience has taught me that a good resource repository requires a means for the social negotiation of the classification conventions or taxonomies to be used, but this is an issue I have not tried to do anything about for 6 years. After some head-scratching about bending existing technology into supporting some special activities for the NGRF and SIGOSSEE communities, I realised that knotes can quickly be adapted to make all categories inherently (cross)-discussable, and to provide an interface for the social negotiation of a categorical structure!

I'll be posting here in KNotations on this issue as we get the details sorted out.