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...

Extended text for this entry:

Our current system for associating categories with objects in knotes is almost ready to handle this properly. And I have some tried and tested techniques for using SQL to efficiently but generally handle the management of assorted structured metadatas while keeping an efficient association of MD and items. This one we'll likely have to explore later, though, because there are so many user-interface difficulties in presenting that many choices to the user / tagger / searcher. I will want to do a simple exporation of the way we can represent this through the dumb old APIs though - thus we'll be trying to organise things for the API like this kind= gubbins which I hand-edited into my categories, but handling it programmatically in the web interfaces. The semantic terrain to try this on is the one we already treat programmatically - the different sources of categories ( my personal vs blog-specific shared vs site-wide shared (and, a bit later, other-users-added-in-this-blog). It would greatly clarify things to contributors if they could easily see where the different categoriescome from - for one thing it helps them see the communicative/marketing intent of the categories.

Other smallish notions:

Listings of external-link resources

We need a bit of SQL method to quickly fetch the external-link resources for a blog (or any path). This will be crucial when teams or projects are trying to collect shared bookmarks by blogging about external sites; without a quick way to scan the external links that have already been noted, this becomes impossible as soon as there are a couple dozen items in the blog. For now, the following will do:

• a new SQL method to fetch blog entries which contain a KNLink with a non-local remote_url ( we want the remote_url, but also the details for the containing weblog entry or discussion item, since that is where the users will be writing about the external site etc
• a listing convention for seeing terse rowset display for as many of the resources as possible in one eyeful. This will be easy when we've gotten further with feature-completion of fast_folders / forums, but for now I've decided to list these through the blog interface but to change the rendering of the aggregator views to only show leadins, and to add some javascript to allow the user to collapse even those in order to see just titles. Not as effective as fast folders would be, but avoids other problems and gets us an initial way for users to see what resources they've put in
• eventually, this might all be controlled by metadata - eg kind=resource, to let the contributors decide what comprises a resource
• and of course, similar displays for file-upload resources

Terser listings in blog aggregator views when N-items is 'large'

Noted this above really - when displaying entries under a category for instance, the number of posts rendered can be large. Instead of handling these like current-posts view (show everything except extended text), show a terser display for each entry. This would also be a good option to have for user to choose for surrent posts - see more posts but less of each. See below for an idea for a sidebar where we could put a link for that option.

It would be very nice if we could have an acquirable preference for this kind of thing: how big is 'N'? - how many entries does blog manager shown in current posts view? How many entries before terseness kicks in?

Stats sidebar for blogs; stats summaries for Site Content listings of blogs

An easy bit of grinding really - when displaying links to weblogs in site content views, it would be very handy to show:

• N posts
• N authors
• N categories
• last post info

This would also make a useful sidebar in the blogs. In the case of authors and categories, the entry in the sidebar could be used as the UI affordance for getting interface for discussing categories or viewing author-information.

A simple enough query can fetch this on the fly, but since the information will be needed in possibly frequently-hit site content, I suggest we keep this information in an efficient-to-fetch way, possibly adding columns and update-after methods

Turning blog entries into organised site content

Two bits of background:

SIGOSSEE / JOIN site:

how do I give the JOIN editors the freedom to create content and get their uploads in, but then allow them to make real site content by re-organising or 'promoting' some of the blog entries

The NGRF focus-group * team-task * editors => site content process.

The NGRF site content came from a very interesting process. They funded a series of paid-for expert focus groups to find out what kind of site content the end-user community wanted. They then had those focus group members participate in a more extended online dicsussion to throw content into a pot. Then they had paid professional editors sift through that, summarise some content, and suggest structure. Then the very talented people at IER Warwick, with KnowNt working very closely with them in realtime, created content.

We here at KnowNet spent a lot of effort last summer developing a content-management => render framework on top of plone's to make this possible. Plone out of the box is impossible for this kind of editor to make good use of. (That framework is still awaiting productising for wider release - we'll get to it though :o) For the upcoming NGRF and EGCRF-Leonardo and TLRP Work-Related Learning activities, we need to understand this methodology even better, and make it easier for other folks to construct good site content from ad-hoc pots of posts.

In local server development, we've already begun adding features for moderators like 'summarise this thread', but much more needs to be done. In fast_folders on local server tests, it is very easy and convenient to do cut / paste, move-up etc gestures, but in the case of blog entries or discussion into site content, we'd also need to change the portal type of the new objects, etc.

This is a biggish problem and will take a lot of experimenting to get right with end-users. Bit I predict that it will be one of our main efforts later this spring. Other questions include whether some kind of categorising might be co-optable into virtual content structures (like the Plone Topic way...)

Controlling trackbacks with acquirable properties

We now have a checkbox in the TTW edit form for knlinks. Soon we'll pay attention to the API on this per-post pref.

But we do not yet havea way to control whether trackbacks are attempted at a folder-level or blog-level.

I noted in an extensive email last week why this is crucial for really 'private' weblogs or work areas.

It occurred to me yesterday while working on the SIGOSSEE resource-collecting blog that this will also be very useful for non-private but in-development blogs and areas. The particular case I have in mind is as follows:

SIGOSSEE's resource collecting weblog has a few dozens of items imported from the old plone links. We'll be training the members (ha!) to effect link-collection with blog entries now. Since I use ecto and have the ectoise bookmarklet ready in my browsers' bookmarks bar, I could very easily collect a few hundreds more in spare time. But I would definitely not want to swamp the existing entries with that lot; rather I'd want to keep them in a temporary blog of my own for illustration purposes, and then later move them into the real shared weblog. (By the way, here's another way that Zope/CMF?Plone pay off bigtime - you really can cut and paste blog entries between blogs).

But the cut/paste entries approach falls doen where posting has implications beyond our system. IE trackbacks sent to remote sites. It would be great to be ble to extend the TB standard to allow retraction or moving of originating content, but til then the natural answer is to not try TB within the temporary blog. When pasted into the real blog, the pasted knlinks will generate their own trackbacks.

So I want a way to at least set the default pref on entries in an acquirable way - and that has to apply to entries through the API.

Well... enough of these notes... this blogging takes a lot longer than my old 'throw text into FC conferences' method :o(