We are big fans of del.icio.us here at KnowNet, and maintain our own bookmarking pretty avidly (see for instance my linklog). We're also proselytisers for the 'data outside' approach to managing the different aspects of a project's content-management needs, and we've worked hard to train our project colleagues in the use of social bookmarking systems. This inevitably leads to people having multiple del.icio.us accounts that they have an interest in, which can become awkward.

Of course, that's what the del.icio.us API is there for :o) Yesterday we wrote a script (python) which we've started using to copy items with certain tags between mutually trusting accounts. We've run it to create the beginning content for three project accounts so far (pulling this content in from four main accounts in various combinations), and have set up chron jobs to maintain the synching workflow nightly.

The first screenshot shows the simple form used to do a batch copy between accounts (the chron jobs just use the same parameters as arguments in a url). The second screenshot shows a tag cloud displaying tags for a project account which includes many items pulled in using the API script. See EGCRF's del.icio.us bookmarks. We'll be publicising the nookmarks tag clouds for other project sites soon.

Please let us know if you're interested in the script. For historical reasons, it requires Plone and a little product of ours called KNUtilities.

Apologies for this hasty post - we really have been hammering at the paid-for-projects recently, so haven't got much time for documenting our progress. The good news on this front is that we are about to draw lines under the administrative work for two very labour-intensive european projects; when that's complete we'll have much more time to spend on documenting progress, building connections with other developers and community-site managers, and collaborating on experiments using knotes as part of educational and community-building experiments. The text below is taken from the brief announcement I just made on our knownet site:

Knotes is now available in a new milestone: version 0.85.

See our Knotes download page for download files and other links. There are quite a few new or improved features in this release.

We will be writing up the new features - and producing an outline of our roadmap for Knotes - as soon as we get a chance (sorry, we've been working very hard on paid-for project deadlines, which makes knotes-documentation-time hard to come by).

Please note that we have had to put the date back to Friday June 9.

We have been extremely busy improving, testing and just plain using KNotes... though we have not been doing a very good job of blogging about it :o)

We've been hammering out many new features in several areas: collaboration / social software / community building / profiling and portfolios. Many of those features are not yet being used in our production version, but over the next months expect to see an increasing number of special-purpose blogging scenarios and features in our portals.

Our public, mature version of KNotes is about to take a small leap forward as well. We are almost finished preparing and testing a new public beta - 0.85. The tarball will be available here by Monday. SourceForge's site has been having a lot of problems lately, so we're not sure when the CVS version will be updated; please use the tarballs released here for the time being.

I'll try to document some of the new features in this weblog. If you have any questions please feel free to email me -- mike AT theknownet DOT com

Sometime in the next week, I'll also - finally! - be announcing KNotes within Plone.org. Many apologies to the hard-working Plonistas who've had to nag me to get round to this; our procrastination has been in part down to wanting to make the documentation more complete and the skin-ability more thoroughgoing :o}

I plan to work hard over the next 10 days on roadmap documentation. We'll also be starting either mailing lists or special blog_forums for users, administrators and developers, and sometime this summer knotes.net will at last get the facelift it needs.

KNotes can be a very powerful and user-pleasing addition to a Plone portal. Knotes + Plone makes a great platform for experimenting with educational or other applications which combine weblogging with social software and/or other functionalities. If you would like to try making use of KNotes, please let us know how you get on. If you feel you can help with development, documentation, or best-practice illustration, we'd really love to hear from you!

I wrote the other day about progress towards microformats and structured-blogging support in knotes:

Steve has the Event microformat type working in a test installation now. Another few days should see tests within our main knotes production version. Other special types should be coming thick and fast after that, some of them for very special uses such as within learners' eportfolios, some of more general use. Exciting developments!

More progress to report. The editing interfaces and scripts have matured - for instance objectless-editing is now possible (so that users can safely and swiftly invoke the editor formlets and then change their minds) and Steve has a generic macro-based way to creating the formlets. New formats are also supported in his tests: hreview, and our own google-video-clip format (we have clients who are putting workplace-learning video clips into google-video and we want to make it easy to embed the information and players for these in our own content).

This development strand is especially important for our planned e-portfolio work, and for anyone wanting to make it easy to add special kinds of structured content in their weblogs. Watch this space for more progress reports.

In a post on Monday I noted that it now seems to "just work" when you copy and paste knotes content within a Plone site.

We moved a number of blogs and a few indexFolders full of blogs (and nested folders full of blogs, etc), and merged three blogs into one. All of this "just worked" using copy and paste TTP (through-the-Plone interface). We encountered and repaired two small issues.

Yesterday we had another fast-action-request to move a year-old knotes weblog from one portal to another. You cannot use TTP copying and pasting between portals (note that by TTP or CMF-wise copying/pasting we mean through the Plone interface - by going into folder_contents view on enclosing folders while in ordinary website view). To copy content between portals it is necessary to go into the ZMI (Zope Management Interface) view and either use ZMI copying and pasting or export and re-import the weblog. We had run into problems with these advanced actions before, and have not tested them in a long time, but thought we'd give it a go.

It just worked. Exporting to a .zexp file from one portal and importing that into another worked fine. Caveats: the weblog was small and had no comments, just blog entries; and we made sure that there were corresponding users in the target portal and imported with the 'save existing ownership information' option.

This is good news for busy site administrators. It means that you should be able to let uysers create weblogs wherever they like, safe in the knowledge that you can move them later, even onto different servers and portals. We are eager to have some help testing advanced admin actions like this - please let us know if you can help.

I've mentioned a few times recently that we're working towards using microformats / structured-blogging to allow users to represent special kinds of content within their knotes weblog entries. There are many reasons for taking this route: it allows users to see content-creation as more homogeneous and spontaneous; it represents special content structure in interoperable machine-readable formats; it allows us to generalise the notion of special content types from the point of view of knotes' own interfaces and leave the details to special-type plugins...

The first few special structurings we'll be looking at are: event, google-video clip and embedded RSS, after which we'll be looking at variants on review. See my earlier post in elearning2.0 for a sketch of the merits of embedding live RSS to augment a blog entry (eg as reference list or background-resource links ). See this post in the work-related learning blog for an illustration of embedding google-video content in blog content. Event as a structured-blogging type should be pretty obvious: roughly, it takes the place of the Plone 'Event' content type allowing users to denote upcoming events in an ad-hoc but machine-readable way so that they integrate with portal calendar and can be aggregated into iCal syndication.

Events as microformats embedded in the blog content have the additional advantage that 3rd party harvesters can discover the event-wise information directly from the rendered html / rdf of the blog entry.

Steve has the Event microformat type working in a test installation now. Another few days should see tests within our main knotes production version. Other special types should be coming thick and fast after that, some of them for very special uses such as within learners' eportfolios, some of more general use. Exciting developments!

I've been meaning for weeks to repair a little glitch in firefox for windows. For some reason the webdings font is not applied to the internal navigation convenience links - togglers for the sidebars, next/prev/top for the entries. I thought I'd be saving some traffic by using one-character 'icons' for these, but soon realised why I'd avoided webdings for all those years...

I have real images to replace the webdings with, and will be making this repair along with a few planned stylesheet improvements as soon as I get a chance - within days.

We still have much work to do in documenting the features and tricks of managing and customising knotes for site-admin folks. There's also a lot of work remaining to be done in making end-user capable skinning interfaces for knotes blogs. But let's not forget that, being based on Zope, Plone, ZPT, python etc, knotes is already pretty easy to adapt and customise for those with some ZMI skills.

By way of illustration: yesterday morning one of our regular end-user advocates got in touch to complain that the external links in this NGRF weblog entry were not opening in a new window. Sigh. We'd more-or-less forgotten that this was an outstanding feature-request - being web-standards types, we personally hate the idea of targetting external links into new windows and feel it is the user's choice. But we know that it is an important feature for a lot of site managers; in fact we've been through several iterations improving the spoecial handling of external links in the main site content of the NGRF.

We had a good javascript solution in hand, but needed to get that javascript code into the NGRF blogs, and have an onload handler added in those blogs, without stepping on the default behaviour of knotes blogs in other sites. So we made the following simple changes:

• In the product, we added a dtml-var include near the end of the blog_utilities.js.file, to test for the existence of a site-custom javascript file and include it if it exists (the name of that file is knotes_blog_utilities_extras.js).
• We added a custom version of that file in the NGRF portal skins / custom folder, and added the javascript code and onload-handler addition there

Since a little bit of CSS was also required by our external-links-handling solution, we added that rule to a site-wide custom css.dtml file which is included if present in the main screen css for knotes weblogs. Note that the knotes screen css includes both a site-wide custom and a blog-specific custom css file if present:

• knotes_weblog_weblogCustom.css.dtml
• knotes_weblog_sitewideCustom.css.dtml

All in all it went very quickly, with the change to the product being the time-consuming step. We'll add a similar customisation hook to blog_forum.js.dtml, and will have a close look at the customisation hooks architecture when time allows. We welcome feedback from site managers and developers about how best to add hooks to make it easy for them to meet the needs of their users.

By the way, you may want to check out the little javascript solution - it is a big improvement on the default plone link-scanner because it offers the user extra information and an option to over-ride the behaviour ( a rollover that shows the destination content type and a checkbox for 'open in new window' ). So users can opt out of the new-window behaviour for particular content types (for instance, pdf files may download to their disk in their browser's settings), and the visitor at least can see that the link will open in a new window if they do not untick the checkbox. We'll happily share the javascript code snippet if anyone wants it (about 7K of js).

One of the big advantages of developing knotes as a product within Plone / Content-Management Framework (CMF) / Zope is that it enables very powerful site-admin actions, including implementations of the copy and paste metaphors extended over large chunks of content. It turned out to be quite a lot of work ensuring that the metaphor would be sustained for objects and transactions as complicated as knotes requires, but we've done and tested that work as we went along.

In the National Guidance Research Forum (NGRF), we have been using knotes in anger for over a year now. In the process of exploring the uses that site managers and end-users can make of weblogging and discussion, there was a proliferation of weblogs over time (one of the other "advantages" of CMF is that it is very very simple for users to create new weblogs - maybe too simple :o).

In advance of a major symposium Friday, and following on from the big improvements we've recently made to usability, we were asked to rapidly re-organise the main weblogs in the NGRF. See the NGRF group discussions area for the end-result: there are now just 3 weblogs in the main public area. We moved a number of blogs and a few indexFolders full of blogs (and nested folders full of blogs, etc), and merged three blogs into one. All of this "just worked" using copy and paste TTP (through-the-Plone interface). We encountered and repaired two small issues.

This involved hundreds of blog entry and discussion objects, and worked very smoothly and quickly. We're not sure what would happen if tens of thousands were involved, but even at that scale it should "just work".

Last week, we completed pushing the recent improvements to knotes into the CVS version and tarballs at the knotes sourceforge area. We've been intensively testing in our own user communities as well as in a variety of test installations. It seems to just work, and end-users seem to just get how to use it, so we feel we're approaching a really useful product. To reflect this, we've incremented the version number to 0.8 BETA. Well done and many thanks to Steve and to our beta testers!

Still to-do are the writing of better admin documentation and end-user help, and the provision of developer forums, issue-tracking, etc. We're attending to those requirements as quickly as other work allows.

We are confident now that other Plone admin folks should be able to install knotes easily and make good use of it to add dynamism, discussion and user-expression to Plone sites. Please do try it out and let us know of any issues you encounter.

We're also confident that knotes with Plone provides a rich and flexible platform for experimental projects looking into variations on the theme of blogging - into uses in learning and community building where the basic behaviours and building blocks of blogging need to be enhanced or contextusalised. That's why we built it, and we're already starting to make progress with some ideas of out own that make use of knotes 'plus'.

If you are an educational researcher or community developer, please get in touch with us and share your ideas; we may be able to help. We're particularly keen to explore lightweight services-oriented approaches in the "web2.0" style - adding microformats, integrating with social bookmarking, etc. We are also eager to enhance the profile-building and user-glu aspects of the knotes member-profile, and to explore the use of knotes + Plone for e-portfolios and personal learning environments.

Within a couple hours, we'll have our production version of knotes in shape and suitable for deployment on other peoples' zope/plone installations. Huzzah!, phew!, and none-too-soon! :o)

We now have to carefully merge our production version with the CVS at the knotes sourceforge area, and make a new tarball to put in our own downloads areas, based on that CVS version. We expect it to take the rest of this week, given other demands on our time - though we can hope for speedier progress.

Once we have a stable and highly-usable release on sourecforge, we'll concentrate on improving documentation, and on providing issue-tracking etc - we'll make an open blog-forum for developers to post queries and share ideas as well

Of course we'll also have to do some writing at our own product pages :o) I'd also very much like to get some time to do justice to the knotes.net site, which is an utter mess now. I want to use knotes.net as a text-case for a plone sitelet theme / customisation-policy, comprised transparently and attractively of just a blog or two and a few simple downloads/content areas (inspired by particletree.com).

I'll post a note here when we've upgraded the CVS version of knotes.

We're great fans of the Creative Commons system for denoting open content licensing. In educational settings especially, the simplicity of CC licensing can cut through a lot of silly obstacles to sharing.

We've now made it very easy to add Creative Commons licensing to knotes weblog content. There are new links in the Manage sidebar for managing a CC license (you need manage role on a weblog to see that sidebar).

If no license has yet been chosen, you see a link to "Add Creative Commons License". Clicking that takes you into a form delivered by the developer API at Creative Commons, which guides you through the choice. Click 'proceed' when done there to have the CC API contact knotes with the information about your license. The license you have chosen will then be rendered into all knotes views, both as machine-readable RDF and human-readable badge and link to the deed (see the screenshot for an example)

Embedding the RDF - "properly" adding the license to your content - is vital to having the legal import of your choice of deed made "ert". For instance, google will note the embedded RDF and thus will include hits to your content when people search specifically for creative-commons deeded content in google's advanced search.

If you have already applied a CC license, the "Add Creative Commons License" link in the Manage sidebar is replaced by links to change or retract the license.

We hope this helps users to express their intentions to share content. Please let us know of any other features that would help in smoothing the sharing of content, especially in institutional settings.

I've been quiet here for far too long - apologies.

It's not that we have been idle, though. We've been hammering very hard at knotes, working out a large number of fundamental improvements in response to real-world users' detailed comments and requests.

Yesterday I posted most of the changes to our production server's version of knotes. It all seems to be working very well., For instance, you may notice that the appearance of this weblog has changed ~(it is now getting 100% default knotes styling, so you can see what that looks like.

Over the next week or two we'll be tidying the product, adding documentation, and working towards a proper release of knotes. We're also, alkready, starting to do with knotes what we feel it is intended for --- adapt it for special kinds of collaborative activity, such as professional development planning.

I'll be posting here frequently for a while with updates and explanations. Sorry, but thiss post has to be short.

We have not yet percolated the changes to the CVS version. We'll be doing so over the next week. Please let me know by email if you want to try installing our own working version of knotes before then.

You should notice 2 new icons in the main sidebars: [ ] in the 'What is this? sidebar is meant to point to help content that explains what the user is looking at and how to do basic navigation. [ How to contribute ] in the Contribute sidebar is meant to point to help content that explains how logged-in members can post, reply, and set themselves up for making the most out of the weblog's features.

We still need to write the content for these help topics. My intention is that the help content will open in the quick-view area ( like the add-new-entry form does ). I think we can and should write quick-tips "cheat sheets" quite quickly, and then elaborate on these at our leisure. I'll be trying to get those cheat-sheets written today (though I have a stinking chest cold which is weakening the old brain-power).

Please note that these 2 icons/links join 2 that already exist - the little icon in the "posted info" pane under every blog entry points to a quick-tips sheet explaining the other posted-info icons and basic actions like replying, sharing a permalink etc ( this content needs updating ). And the blog_forum view has a prominent icon, intended to point to help for using the forum view; the content for this still needs to be written as well.

I welcome ideas about how best to approach creating the content to match these help topics / icons :o)

We've been aware for a long time that the javascript / DOM editing 'window' caused big usability problems for KNotes. Replacing it has taken some effort, but we're almost there with much improved solutions. I have to spend a lot of today on (sigh, yet again) admin, but I truly expect to be demoing alternatives in the NGRF testbed by mid-afternoon friday at the latest.

Some of the solutions are straight, accessible html - but they should load somewhat faster than most plone edit forms because they can avoid the rendering and markup load of the navigational context ( we can simplify the edit pages to remove much of that context ). Where possible, we're including simplest-case reply forms in the pages a user would be replying to, saving the roundtrip otherwise required to load the form. Some other solutions will be 'ajaxian', but will be much lighter-weight and more usable than the existing 'pswin' - and none will expect the user to drag dom elements around the page :o)

The replacement solution will be introduced in batches of cases, starting with reply, add-blog-entry and edit entry.

Back with a more complete update this time tomorrow.

By the way, this also mean that we are finally inches away from removing the fast-folders product dependency! hooray!