KNotations

I've always thought that the daily-post-oriented publishing system was a great idea; by collapsing the tricky bits of building navigational context into simple chronology, it puts expressive web publishing in the hands of people who want to write. But somehow I never had the time to blog, though I very frequently found myself making quick notes about web content and ideas to FirstClass conferences, which amounted in many ways to blog posts.

Part of the problem was that none of the personal publishing systems really appealed to me - collaboration and shared organisation are crucial to the way I would naturally annotate the web. So, for years, we've been thinking of writing or adapting a weblogging system to suit our own ways of writing. We've finally done it! 'knotes' for Plone will be released within a week or so (on which subject much more to come.. :O). This blog, of course, is powered by knotes.

So it's time to start blogging! Watch this space - and perhaps some other blogs which I'll document here - for thoughts, documentation, argument and discussion about the kind of things that matter to me: mostly about how to improve web technology to enable effective collaborative knowledge-development (of which I see learning as a special case), especially about harnessing the power of Open Source and Open Standards initiatives to create blistering new kinds of software that unleash the creative potential of real people.

As a newcomer to blogging, I'm still not sure as a user which of the many desktop blog-management tools I prefer. But as a developer of server-side implementations - which means a frequent tester - I have had some experience. I would very much like to see a good open-source client for every platform, but it is a lot of work to make one of those things feature-complete against all the APIs (and all of the implementations of the APIs :o) so it may take a while.

For me, ecto stands out as the best OS-X client app, and well worth the £10 it costs. It integrates well with bbedit, plays well with my categories, and allows very simple gestures for getting images up and into the entry. Since I never had that much trouble getting images up and into content (I always have powerful management tools open), this says a lot: ordinary users are going to find that this makes all the difference. WYSIWYG is not important or even appealing to me, but ecto seems to do a decent job of simple styling.

ecto also has a Windows port, but my colleague Steve Tufail says that the Windows version is not very usable, and prefers other Windows clients.

I'll be back with more to say on this issue later...

here is a little movie... (just click on the thumbnail to view it)

this ought to be an mp3

this should start playing... :O)

There is a discussion going on in the new-features discussion document which bears on some of the issues I've been exploring recently with ecto.

Adding a couple little features in the midst of some more important work on bugs (and on trying to get some use-cases and design requirements for tam-task-like collaborative blogging in knowledge-development or resource-assembly contexts).

Just added:

Management interface for editing title, description and about text

This just meant putting in a link to the edit-form for the weblog object itself, and changing the TAL expressions which look for the about-me to fetch it from the body text of the weblog object (which has a rich-text property to hold this)

Management interface to guide user through setting up weblog API clients

This is a must I reckon. Steve worked very hard to get a very thorough implementation of the API, including autodiscovery, so most clients only require the weblog's URL to auto-doscover the interface. I also had to try to point users to clients, but am not really qualified to do so. If anyone knows of more recommendations for good clients for different OS's, please trackback to this post with them.

When you open detail for one entry, the calendar now shows the month that entry was made in.

By the way, did you know that the calendar in knotes blogs is written by javascript. This means that even in very busy blogs the calendar carries almost no markup load, and does not pollute the source with td's... all that is written to the page is pure data [day,count] for days in that month which had posts. Of course, this means that the calendar will not be available to non-javascript enabled devices, bu there is plenty of alternative navigation to supplement the calendar, and the sacrifice is worth it to save markup load and serverside rendering

Collapsibility for the different kinds of information in the sidebar

I'd noticed this in a couple blogs I like. It can be very handy when blogrolls and archives get very long. Nothing fancy to start with; just traversing the sidebar in javsacript to create toggle-icon links to collapse/expand each sidebar item. Of course, we should make a cookie to remember these toggle states, but that'll have to wait :O)

The problem was that apostrophes were appearing as high-ascii characters like acute-accented letter-i's.

The current implementation of knotes uses default settings for Zope's XML-RPC engine and underlying XML parsing, which coughed on these characters.

We might be able to change the settings at the server, though I expect they already accept any valid unicode characters.

So, as a temporary stopgap, I explored ecto's settings... it is indeed possible to preprocess the nasties, encoding them as html entities. See this screenshot:

The results will not always be as expected for these weird characters. By the way, where do they all come from, all these special quote and apostrophe characters generated especially by MSWord? Just when I think I've seen them all, another pops up. :O)

You can see the html entities that have been made from those odd apostrophe's in graham's nissus-generated content here

We need in the next few days to have at least a mock-up of using blogs in 'team-tasks' for demonstrating in a couple of our project sites ( team-tasks are knownet's first stab at a goal-directed discussion and resource-development component, not yet productised ). One feature of our current ad-hoc implementations of team-tasks - which do not use weblogs - is a special tool which appears everywhere in the task's content and interfaces, for switching between the discussions, resources, and seed-content. I'd like to have a simple way to get that kind of context-sensitive tool into weblogs.

A natural solution would be to do as the Plone folks did with 'left_slots' etc... a machinery to marshall all the content specified in a ZMI-editable property, fetching content from macros in context. This would be a great way to add sidebar elements to weblogs. In fact it would be a great way to handle the customisation of the sidebar in general. We could have an omnibus macro to call which assembles all the default sidebar elements, which could optionally be replaced as a ZMI property by a series of finer-grained macros for individual elements. This would make it a lot easier for site-admininstrators to customise ( I had envisaged this happening by their customising the sidebar_macros template). The only things I do not like about this are

• the way that the entire slots property would be what acquisition noticed, rather than individual elements - though this could be overcome by combining slots customisation with template customisation within content
• the oddities of trying to combine this with user-configurable slots - I suspect that we could make sense of this by having a hierarchy of macro calls, with some common sidebar elements combined in one macro, to effect a mix of fine-grained customisation and sensible acquisition of sitewide defaults or higher-level content-area customisations.

The only other problem is that I never did figure out how the magic of slot marshalling happens, but I suspect it can be done with a wee bit of python :O)

It turns out that all you have to do is go to ecto preferences / editing and change the default editing mode to html, and then ecto will refrain from trying to understand your markup. Of course this means giving up wysiwyg by default, but that is fine by me - and it is easy to switch modes.

This isa constant problem for WYSIWYG editing: doing visual editing of content that has been marked up 'properly' to begin with, using for example nice semantic markup with definition lists, acronyms etc etc. We had a big problem with kupu and the NGRF site content development; we had yound Mathew slaving away bulk converting MSWord content into clean, semanticall marked-up web documents, then an editor would fix something in kupu and destroy a lot of markup. We had to fiddle with kupu to try to get it to understand the markup, but this is made hard because of the way the native browser contetEditable works :O(

anyway... below is an example of using markup ecto does not know how to edit, and editing the post aftwerwards without problem...

testing a definition list, and edited

this

def of this

that

def of that