KNotations

We've just deployed a new method of handling comments by non site-members. If a comment is submitted 'anonymously', the email address given in the comment form is sent a confirmation email. If the special link in that email is not opened, the comment is not posted (see the screenshot). When submitting an 'anonymous' comment, a user can optionally ask to be registered as a member while the server is at it (by entering a username), in which case the confirmation email includes a server-generated initial password. Both anonymous commenting and joining-while-commenting are under control of site and blog properties. We're aware that some sites may have exotic registration policies or restrictions: in those cases the site manager should turn off the ability to join while commenting at the site level, using the KNotes tool in the ZMI.

I'm now beginning to experiment with having a one-form-fits-all add-comment form rendered directly into the one-entry views (most blogging systems do something like this). That form would cover all the cases: [I'm a logged-in-member; I'm a not-logged-in member; I'm not a member but want to join while commenting; I'm not a member and do not want to join].

We'll still include links for creating 'full-featured' discussion items (with extended text, categories etc), especially in the soon-to-come forums views. Watch this space ;o)

Have a look at my new personal weblog elearning2.0 ( 'putting the 'oh!' back into elearning' :o). I'll be developing a lot of interesting new content in that new blog, but that's not the point of this post to Knotations. The reason I'm posting this now is to point out the experiment in re-skinning that my new weblog represents.

We've been meaning to develop some serious styling options for KNotes weblogs, but never had the time. The new elearning2.0 weblog is a testbed for (a) developing a nice, open layout and styling for KNotes, and also for flushing out (b) rendering, (c) appearance/markup and (d) skinning issues in KNotes.

Alongside the work we've been doing (in tests) for streamlined renders and very clean discussion interfaces, this is pointing to a much more "come and use me" feel for KNotes in future. (We hope :o)

Sigh... I really didn't want to have to spend the time to implement this, but we decided it was made necessary by the nastiness of some of the trackback spam we've been seeing.

There is now a property in all KNotes weblogs, as well as a sitewide setting in the tool itself, for controlling whether trackbacks need approval before they are displayed. By default, this is set so that only approved trackbacks display. We will shortly be providing a weblog properties interface for managing this and other properties at the weblog level. The sitewide property is set through the tool in the ZMI - kndiscuss_sql (KNotes Config Tool). The sitewide property is acquired if the weblog property is not set.

There are new interfaces for moderating and managing trackbacks. See the screenshot for an example of the manage-trackbacks TTW (through the web) interface. If there are pending trackbacks, managers will see a portlet (in Plone content) or a sidebar (in KNotes content) for Managing Trackbacks. The number of pending trackbacks is listed there, along with a link to the TTW management interface. The manage-trackback RSS feed noe includes an indication of the workflow status of each item. We'll be adding links from there directly into setting the status - currently there is a link to delete each trackback but not for approving or rejecting. We'll also be adding interfaces for managing trackbacks wherever they are displayed ( in detail views, sidebars, portlets and plone-content comments views); and will also consider an interface for non-managers to report offensive trackbacks.

By the way - We've also been making a lot of progress on other aspects of KNotes recently, but that will have to wait for another entry here :O)

We've been remiss in keeping the documentation of progress flowing into this weblog. Apologies for that - but it's durned hard to do it and write about it at the same time :o) - So I'm going to try re-using content to help spread the word. I posted into the site-editors weblog for the National Guidance Research Forum this morning with a list of pending and in-progress to-dos. Most of these will also become core KNotes improvements, so are worth noting here.

This post is a copy of an email I sent this morning, briefly documenting some small and large jobs we agreed in the meeting in Bangor but which have not yet gotten attended to or are still in progress

Do you know other sites that suport trackback ?? It's important to test the way other website could suport trackbacks ! I understand that this is an important feature, so maybe it's not so comumn to a website to have this killer function If anyone knows anything about it !

Testing trackback can be a pain if you do not already have access to another blog publishing system with trackback enabled. There is a publicly available test service, though - if only I could recall the URL. Steve has the URL, but it's the middle of the night and he's off ill anyway. I just googled for it and got too much noise in the results - aha! Just tried del.icio.us/tag/trackback and one such service was near the top. In the web2.0 world we have to start thinking different :o). I've collected that link into my own tag del.icio.us/Mike_Malloch/webtech/trackback as well, and will try to collect other useful resources there in the near future. The form is at No-Host Trackback.

I'll also trackback to this entry from some other sites (I am admin in a lot of them so can get away with that kind of abuse). And here are a couple examples of KNotes entries that have been linked to from outside KNotes ( scroll to the bottom of the entry to see trackbacks or click the 'just trackbacks' link. At some point I'll think to add an internal anchor in the main templates' markup to allow urls like url-of-main-blogview#trackbacks, but not yet :O)

• The Seven Challenges of e-Learning design (Part 2) ( just trackbacks )
• Portfolios, social software and non formal learning ( just trackbacks )

Oh my we've been busy - though sometime the hours of toil do not see to get enough done.

This is a note to document some issues dealt with so far today.

Funny how these little bells and whistles can seem o=unimportant until you start creating content yourself :o)

I've long known that we should do something about logging the pings hat the trackback machinery attempts to send out. A trackback 'ping' is a little request we make to a trackback-aware server's "trackback:ping" url for their content we are linked to. That request includes the data about our own content. The other server can, if so configured, use that data - for instance to display a link back to our content's commentary on theirs.

[ASIDE] - This is an extremely trivial note, of the sort that I write up as firstClass conference messages dozens of times every day. I'm posting it here because I'm trying to experiment with making our development notes more publicly visible, and also because in this case it kind-of documents the sidebar-collapsible feature and some design decisions which other developers ought to know about :O)

I find it annoying that the sidebars are all expanded while the page is loading, and then those which are cookie-d to collapse do so after page load. It makes an odd and suddent transition in what the user sees, and makes 'pre-scrolling' very confusing. In case you didn;t know, the sidebars are each collapsible (click the little box icon to the left to toggle this), and the preferences are kept as a cookie. See the screenshots for before and after views o the sidebars during pageload.

There is no need for this - we could easily set up actual display:none style rules before the page content loads instead of acting on the DOM nodes in javascript after pageload. That is, we dynamically write style rules into a little style block which come above the markup for the sidebars, and which declare that certain of the sidebars have the rule display:none applied to them ( the cookie specifies the id's for the selectors )

There are 2 choices for when/how to create the style rules:

1. analyse the cookie in zpt at the server, and write in the style rules in the markup, or
2. write them in javascript dynamically as the page loads in the client but before the sidebars are loaded

Option 2 is best since the cookie only makes sense if js is enabled; otheriwise css-on + js-off could hide content irrevocably

Also ZPT is darned awkward for writing style rules. It is easier to generate css rules as text in javascript and write them into the page than it is to use zpt :O)

I recommend having a bit of js-written styling just before the sidebars ( so the main content loads that little bit faster above them )

I'll do that tomorrow morning.

While I'm at it I'll have an initial look at having the categories sidebar written in js as a tree reflecting the categorical facets hierarchy. We found out today that very long category facet-chains cause a styling glitch in MSIE/win, and I've been meaning to make a js at clientside tree render / drop-down render for the categories for ages.

During PageLoad - all expanded	After PageLoad - some expanded

Our colleagues in the NGRF gavea big hands-on workshop in Cyprus Friday August 26, and were concerned about performance. It can really exercise a server having a couple dozen logged-in users demanding frequent refereshes of dynamic content... as we learned to our embarassment in a workshop early in the spring :o)

Since the spring workshop we have made numerous techie performancee tweaks to the basic server technoology we run, but at the same time we had been amassing the features in KNotes.

KNotes began life as a very nippy application - in fact, performance was one of our number-one goals. But in the way of these things, as features grew so did render time. We were due a thorough review of the speed of rendering an the size of the markup deleivered. So we made that review in advance of the Cyprus workshop.

We've made good progress on tools to make trackbacks easy to monitor and manage. By the end of the week, we'll have deployed a pretty thorough suite. In tests on our own content, these make it easy to bash trackback spams almost as soon as they come in.

There are two new through the web templates:

weblog.trackbacks

This is a weblog-specific template which can be invoked on a weblog or any content within it. It displays a batched aggregate weblog view of the trackbacks within that content, with affordances to delete trackbacks if you have manager role. This template will soon become the 'more' link from the 'recent trackbacks' sidebar, and we'll also hav a link to it from the stats sidebar

trackback_admin

This is a Plone template which can be invoked on a Plone portal itself, or on any content within it. It requires manager role. It provides a batched listing of all trackbacks within the content (either flat or deep) with checkboxes for selecting items to delete

There is also a new RSS feed - TBs.xml - which can be invoked on any Plone or KNotes content. It demands authentication by a member with manager role, anf takes an optional limit search argument. It lists (deep) trackbacks anywhere ithin the content it is invoked on. The item display includes links to the content rceiving the trackback, the URL source for the trackback, and - especially convenient - a direct DELETE THIS TRACKBACK link. Clicking the delete link in an item calls the delete script through the web ( and will demand authentication if you are not already logged in ). We have used this feed successfully in netnewswire on os-x but at the moment are not getting authentication to work in the windows readers we've tried. i we annot get this working in a widerrange of readers by the end of the week, we'll change our plan - if so, we'll post a notice here to that effect.

See the screenshot for an annotated anatomy of the special RSS feed.

Those who follow this blog know that we've been planning to expand the range and features of the syndication feeds from Knotes content. The biggest priorities were:

filecasting ('podcasting'... doc-casting)

- delivering file attachments as enclosures ready to download directly from a news reader. In the case of audio or video files, this is usually called 'podcasting'

'full' content feed

Many users now prefer to experience web content almost exclusively through their newsreader of choice; not only reading content without viewing it in a browser, but also invoking editors to bookmark or blog about that content without viewing it on the web. To accomodate this growing preference, many blog publishers now offer 'full content' feeds. In the case of KNotes content, which has a lead-in/summary, main body text and extended-text, we would assume that the extended text should be excluded from 'full' content in feeds, just as it is in our aggregate web views - we'll call this 'full-minus-extended-text' the "main content" of an entry.

RSS 2 support

KNotes has supported RSS 1 and atom formats from its content. We have never wanted to appear to take sides in the atom-vs-RSS contention, but supporting only RSS 1 and atom coiukd appear to be implicit support for atom as the format for future features, since RSS 1 is ad old format. RSS 2 is the RSS format being developed in the near future and includes many useful features which our feeds have not yet supported - we wanted to include support for RSS 2 from KNotes, and begin to explore support for the new features in it.

On the other hand, we want to avoid a confusing proliferation of choice about which feed a user might subscribe to. We already have a choice whether to 'include_discussion', anfd a choice between atom and RSS-1 - making 4 choices in all - if we delivered the complete range of RSS-1,RSS-2,atom X include_discussion X full-content,main-content,summary we would be giving users a choice of 18 feeds :o{

So we've decided that the RSS 2 feed will be 'the' main-content feed and 'the' filecasting feed. In future we might add these features to the atom feed (which is now beginning to feel featureless :o)

As yet, the RSS_2.xml feed does not support the include_discussion search argument, so is only available for level-one content. We'll add support for include_discussion later today, an then put links into the Subscribe sidebar to expose the new RSS 2 filecasting main-content feed to end users. It displays the lead-in anf the html main body, with enclosures for any file attachments in the entry. If there is extended text, this is clearly flagged at the top an bottom of the feed item (for instance "View full content (18405 bytes more)". See the screenshot.

In the meantime, you can get a feel for the new format either by appending '/RSS_2.xml' to a KNotes weblog url, or by trying one of these:

• SIGOSSEE Project News [main content + filecasts]
• KNotations [main content + filecasts]

Some policy decisions remain to be made - for instance, which of the formats should be the 'one' auto-discoverable feed which we link to from the header? I am inclined to think that the new RSS2 feed ought to be the 'one' that users subscribe to when they click the RSS button in safari, etc. We'll get back to that question later :o)

Those who follow this blog know that we've been planning to expand the range and features of the syndication feeds from Knotes content. The biggest priorities were:

filecasting ('podcasting'... doc-casting)

- delivering file attachments as enclosures ready to download directly from a news reader. In the case of audio or video files, this is usually called 'podcasting'

'full' content feed

Many users now prefer to experience web content almost exclusively through their newsreader of choice; not only reading content without viewing it in a browser, but also invoking editors to bookmark or blog about that content without viewing it on the web. To accomodate this growing preference, many blog publishers now offer 'full content' feeds. In the case of KNotes content, which has a lead-in/summary, main body text and extended-text, we would assume that the extended text should be excluded from 'full' content in feeds, just as it is in our aggregate web views - we'll call this 'full-minus-extended-text' the "main content" of an entry.

RSS 2 support

KNotes has supported RSS 1 and atom formats from its content. We have never wanted to appear to take sides in the atom-vs-RSS contention, but supporting only RSS 1 and atom coiukd appear to be implicit support for atom as the format for future features, since RSS 1 is ad old format. RSS 2 is the RSS format being developed in the near future and includes many useful features which our feeds have not yet supported - we wanted to include support for RSS 2 from KNotes, and begin to explore support for the new features in it.

On the other hand, we want to avoid a confusing proliferation of choice about which feed a user might subscribe to. We already have a choice whether to 'include_discussion', anfd a choice between atom and RSS-1 - making 4 choices in all - if we delivered the complete range of RSS-1,RSS-2,atom X include_discussion X full-content,main-content,summary we would be giving users a choice of 18 feeds :o{

So we've decided that the RSS 2 feed will be 'the' main-content feed and 'the' filecasting feed. In future we might add these features to the atom feed (which is now beginning to feel featureless :o)

As yet, the RSS_2.xml feed does not support the include_discussion search argument, so is only available for level-one content. We'll add support for include_discussion later today, an then put links into the Subscribe sidebar to expose the new RSS 2 filecasting main-content feed to end users. It displays the lead-in anf the html main body, with enclosures for any file attachments in the entry. If there is extended text, this is clearly flagged at the top an bottom of the feed item (for instance "View full content (18405 bytes more)". See the screenshot.

In the meantime, you can get a feel for the new format either by appending '/RSS_2.xml' to a KNotes weblog url, or by trying one of these:

• SIGOSSEE Project News [main content + filecasts]
• KNotations [main content + filecasts]

Some policy decisions remain to be made - for instance, which of the formats should be the 'one' auto-discoverable feed which we link to from the header? I am inclined to think that the new RSS2 feed ought to be the 'one' that users subscribe to when they click the RSS button in safari, etc. We'll get back to that question later :o)

The only definition I ever found that created the lighbulb moment I was feeling was “Social software is stuff that gets spammed.” Not a perfect definition, but servicable in its way.

I hate spammers and dirty, venal link-farming vandals. I really, really hate them.

But they are out there, and they have noticed how useful trackback 2-way linking has been in raising the google page ranking of well-connected weblogs.

The link-farming spammers may also have noticed that the boost to the page ranks of well connected weblogs has, through the development of blogging, been a good thing for seekers after good content and for google: it helped people to find what they were looking for by googling it, and it helped them to browse around communities of discourse in fascinating and useful ways. They may have noticed this, but it has not stopped them from adding noise, aggravation and ugliness to the system by perpetrating trackback-spam.

In this post, I briefly explain trackback spam, and outline the measures we are planning to help the managers of KNotes content to resist the spammers by keeping spam links out of their own content. Click the permalink ("Continue reading this item") for more...

The only definition I ever found that created the lighbulb moment I was feeling was “Social software is stuff that gets spammed.” Not a perfect definition, but servicable in its way.

I hate spammers and dirty, venal link-farming vandals. I really, really hate them.

But they are out there, and they have noticed how useful trackback 2-way linking has been in raising the google page ranking of well-connected weblogs.

The link-farming spammers may also have noticed that the boost to the page ranks of well connected weblogs has, through the development of blogging, been a good thing for seekers after good content and for google: it helped people to find what they were looking for by googling it, and it helped them to browse around communities of discourse in fascinating and useful ways. They may have noticed this, but it has not stopped them from adding noise, aggravation and ugliness to the system by perpetrating trackback-spam.

In this post, I briefly explain trackback spam, and outline the measures we are planning to help the managers of KNotes content to resist the spammers by keeping spam links out of their own content. Click the permalink ("Continue reading this item") for more...

sigh...

Auto-detection of the edit API hads been a real pain for us. Clients differ in their behaviour.

And recently ecto, which used to auto-detect the preferred API and access-point for KNotes blogs, now fails. And blogjet, which used to fail, succeeds :O)

... we did not change anything I am aware of, so I suspect these are clientside changes :o{

ANYway, the worst part of not auto-detecting is that the user is not currently given a hint to specify the MT API (Movable Type). The MT API allows some clients - ed ecto - to edit the summary and extended text, pluys other goodies I think. Which makes for more useful content structuring from the editor. We're proud of the work we did implementing the serverside for the API for plone, and it did take work to support those neat MT extenseions - so this is frustrating :O)

So...

1. If you are setting up remote editing for a KNotes blog, and auto-detection of preferences and API access-point does not work, please choose the MOvable Typ APi if given the choice.
2. We should remember to have another look at the way we specify the MT as preferred API in our edituri text
3. It seems likely that whatever is preveting ecto from noticing our preferred API might also be the culprit in preventing it from auto-detecting the API attachment
4. Andin the meatnime we ought to add some text to the 'set up external editing' content to explain why the MT APi is better.

... of course, once KNotes becomes well-known by the developers of the clients, these problems start to become theirs as well as ours :O)

I'm about to post a short overview of our plans for dealing with trackback spam, and realised that before going into those measures, I should first review the behaviour - current and planned - regarding authenication for RSS/atom in KNotes.

First - what is the issue? Basically, manegers can use the permissions form for a KNotes weblog to make the blog readable only to certain members. Likewise, a parent Plone folder could have been given a workflow state of 'private'. In either case, through-the-web pageloading requires authentication by a member with the correct permissions.

But what about the RSS/atom feeds for that private, members-only weblog? If a snoopy and savvy person wanted to type in the url for an RSS feed for the private weblog, surely they should not be able to read content in their news-reader which they could not read in their browser?

No, they should not. And at least some news-reading clients respect that. For instance, NetNewsWire offers username/password properties for a subscription, and will present an interface for entering them if the subscription demands it with its http response header.

And KNotes' RSS and atom feeds will not return content unless given an appropriate username/password when the request is made on a zope object which would require authentication for viewing through the web. Try it... if you subscribe in netnewswire to a private weblog, you'll have to enter a username an password ( in the get-info dialog for the subscription ) in order to fetch content.

BUT there is still work to be done:

Demand authentication nicely

We need to have the private feeds send back an authentication demand header rather than the error they currently do. This is a very small job but needs to be scheduled,

Return '' for nested private content in public feeds

More important by far: If you subscribe to a KNotes feed with '?include_discussion=1' -- ie you want to get nested content in the feed -- you can read nested private content. At the moment, privacy is only 'ert' at the level of the object the feed is called on. The content of the feed is assembled with an SQL query, so zope-wise permissions are not taken into consideration when grabbing the item content (and we definitely want the SQL speed). What we need to do is to impose a very simple policy: content which is not public through the web should not appear as nested content in any feed.

This policy would be draconian but safe. The SQL database kndiscussion table rows can 'know' whether or not "some" authentication is required (but cannot of course encapsulate zope's complex acquirable permissions, so cannot know whether the current request should authenticate against a row). But, since a row can know that its content is not public, it can have its feed content an empty string except when called directly on its parent object... in other words, a different query would have to be called for the non-nesting case

As you can see, some changes to the SQL data model are required in order to prevent non-public content from appearing in feeds other than those called directly on its parent. That means work, and will have to wait.

In the meantime, beware that private content could be sniffed by savvy snoopers. Personally, I would resist privacy anyway, but I appreciate that it is very important to some of our own users - and we will attempt to effect correct behaviour soon after 'release' :o)

Which RDBMS? :: PostgreSQL, MYSQL

Knotes was built for speed, that's why it's been built using a RDBMS. During the development stages we used Postgresql throughout, this has led to some small non-standard, or shall I say 'non-MYSQL' code sneaking into some of the pre defined queries. This isn't a big issue and we already have a 'MYSQL friendly' version available. This just needs some thorough testing before being merged into the product.

Support for Plone 2.1

KNotes stores all related data (attachments,links...) in the RDBMS. To enable links and attachments to get their data storerd in the RDBMS, we created special versions of the standard 'Link' & PloneExFile products. The version of PloneExFile used for subclassing is now quite old and newer versions are not supported, this old version will *not* install in Plone 2.1. We will therfore drop PloneExFile as a dependency from any future release.

ZAttachmentAttribute is required by PloneExFile, even when the dependency on PloneExFile has been removed we still need ZAttachmentAttribute for our own KNExFile. The version of ZAttachmentAttribute used at the moment (2.3) does not install without a few minor hacks to the installer script. Altough these are *very* minor, they are still of some concern.

Apart from the problems outlined above, KNotes versions 0.7 alpha and above *will" install and work in Plone 2.1

A few how-tos:

1 - How the properties of a weblog itself are used [ these are the fields when you create a new weblog ]

• id - as usual; this is what appears in the URLs
• title - used as the title of the blog and as part of page title for posts and other views
• description - displayed in banner and as DC description in RSS and page metadata
• main text ('about') (rich-text field) - displayed as the 'About this weblog' sidebar if it has any content (else description is used)
  • - you can place arbitrary html here, so it's also a quick & flexible way to customise the sidebar
  • - eg in the about sidebar of my other blog, I've placed some colophon an profile stuff like js that builds summaries of recent del.icio.us and flickr stuff of mine
  • http://www.knownet.com/writing/weblogs/Mike_Malloch

• when logged in with manager role for a blog, you get a 'Manage this Weblog' sidebar at the top right of all views
• this includes links to manage the 'top' and 'sidebar' links -- basically these open subfolders of the weblog
• you can add whatever you like to those folders; the contents are rendered as links

3 - how to post an entry

A - through the web (TTW):

• if you have manager role, you get a 'Manage this Weblog' sidebar at the top right of all views
• if you have weblog contributor role, you get a 'Contribute to this Weblog' sidebar at the top right of all views
• - there is a link there to add a post
• - the fields in the edit form are as follows:
  • title : the post's title
  • lead-in: a brief description used, if present, for listings, RSS etc
  • body: the main content as it will appear in aggregate views ( currenty entries etc )
  • extended: extra content which will show only in one-entry (permalink) views
  • category: a widget for selecting categories from 3 scopes ( site/blog/personal ), or for adding new personal categories
  • ON FIRST EDIT: details for an initial link for the item. This will be a trackback-triggering link. This is automatically filled in when you use one of the bookmarklets or other tools for directly 'blogging' content

B - through an API client (the recommended way for power users)

• in the manage or contribute sidebar, there is a link to set up external weblog editing
• - get yourself a client ( I use 'ecto' for os-x http://ecto.kung-foo.tv/ - there are plenty of others for various OS's )
• - follow the instructions in the set up external weblog editing page fo the blog you want to set up
• - clients vary in how you add a new 'account' ( or similar concept )
• NB - workflow is not yet paid any attention to, but if your client allows workflow management KNotes sets workflow state accordingly

Note that there are bookmarklets for 'blogging this page' in both TTW or API-based

• A bookmarklet is a javascript 'bookmark' that you can add to your bookmarks bar in a browser and invoke on any webpage as an action on it.
• For instance, KNotes has a 'knote-it bookmarklet' link in the contribute/manage sidebar. Add this to your browser bookmarks/favourites and invoke it anywhere to open a new weblog entry edit form pre-populated to link to the page you are viewing at the time (selected text will be used as initial content of the blog entry body). We will shortly add a pop-up-blocker friendly bookmarklet.
• Almost all the API clients also have bookmarklets for quickly 'blogging' web content. For instance ecto has an 'ectoise' bookmarklet. See the documentation for your API client to seee how to install bookmarklets and customise their behaviour.

4 - how to edit entries

A - through the web:

• you will get a toolbar just beneath any entry you are allowed to edit, the pencil icon is for editing
• if clicked from an aggregate view, this opens a mini 'window' within the page ( saving round-trip time )
• if from a one-entry (permalink) view it should open a normal plone edit form

B - through an API client

• usually just find the entry in your client's display and double-click

5 - how to add an attachment to an entry

A - through the web:

• if you are allowed to attach files to an entry, you will see a little MSWord-like icon in the toolbar just beneath the item
• this creates a new KNExFile object within the blog-entry

• almost all clients let you add attachments ithin the body of an entry as you edit its text
• -- that means that the attachments and entry are created in what seems One Step
• -- much more convenient

6 - how to add a trackback-generating link to an entry

A - through the web:

• Note that one trackback-triggering link can be created at the same time as you submit a new blog or discussion entry - fields for this appear near the bottom of the blog entry edit form on first edit
• For adding further trackbacking links: if you are allowed to add trackback-triggering links to an entry, you will see a little Link-like icon in the toolbar just beneath the item
• this creates a new KNLink object within the blog-entry
• you can untick a checkbox in the edit form for the KNLink if you do not want a trackback ping fired off
• ( there is also a blog-level pref for this; eg important for private blogs )

B - through an API client - the easy way!

• almost all clients let you links within the body of an entry as you edit its text
• -- any links within the body are parsed out and turned into KNLink objects
• -- much more convenient
• -- exceptions: if the link already exists it stays there but is not duplicated on subsequent edits; if it has rel="tag" attribute it is ignored (eg technorati tags)

7 - how to set up shared blogging and other permissions

• - if you can manage, you see a link in manage sidebar for 'Set up sharing permissions'
• - this is complicated and fully featured but lmost self-explanatory
• - quite powerful
• - we'll write help for that asap
• - if you have moderator or higher (eg manager) role you see a link in manage sidebar for 'Delegate Moderators/Managers'
• - this lets you assign moderator roles to specific members or groups ( but no more powerful than your own roles )

... there are many other bits of how-to that need to be written ( KNotes is very full-featured :o)

... I'll try to get back to you with bits of documentation as soon as we get a chance to start writing them

cheers

Mike

A few how-tos:

1 - How the properties of a weblog itself are used [ these are the fields when you create a new weblog ]

• id - as usual; this is what appears in the URLs
• title - used as the title of the blog and as part of page title for posts and other views
• description - displayed in banner and as DC description in RSS and page metadata
• main text ('about') (rich-text field) - displayed as the 'About this weblog' sidebar if it has any content (else description is used)
  • - you can place arbitrary html here, so it's also a quick & flexible way to customise the sidebar
  • - eg in the about sidebar of my other blog, I've placed some colophon an profile stuff like js that builds summaries of recent del.icio.us and flickr stuff of mine
  • http://www.knownet.com/writing/weblogs/Mike_Malloch

• when logged in with manager role for a blog, you get a 'Manage this Weblog' sidebar at the top right of all views
• this includes links to manage the 'top' and 'sidebar' links -- basically these open subfolders of the weblog
• you can add whatever you like to those folders; the contents are rendered as links

3 - how to post an entry

A - through the web (TTW):

• if you have manager role, you get a 'Manage this Weblog' sidebar at the top right of all views
• if you have weblog contributor role, you get a 'Contribute to this Weblog' sidebar at the top right of all views
• - there is a link there to add a post
• - the fields in the edit form are as follows:
  • title : the post's title
  • lead-in: a brief description used, if present, for listings, RSS etc
  • body: the main content as it will appear in aggregate views ( currenty entries etc )
  • extended: extra content which will show only in one-entry (permalink) views
  • category: a widget for selecting categories from 3 scopes ( site/blog/personal ), or for adding new personal categories
  • ON FIRST EDIT: details for an initial link for the item. This will be a trackback-triggering link. This is automatically filled in when you use one of the bookmarklets or other tools for directly 'blogging' content

B - through an API client (the recommended way for power users)

• in the manage or contribute sidebar, there is a link to set up external weblog editing
• - get yourself a client ( I use 'ecto' for os-x http://ecto.kung-foo.tv/ - there are plenty of others for various OS's )
• - follow the instructions in the set up external weblog editing page fo the blog you want to set up
• - clients vary in how you add a new 'account' ( or similar concept )
• NB - workflow is not yet paid any attention to, but if your client allows workflow management KNotes sets workflow state accordingly

Note that there are bookmarklets for 'blogging this page' in both TTW or API-based

• A bookmarklet is a javascript 'bookmark' that you can add to your bookmarks bar in a browser and invoke on any webpage as an action on it.
• For instance, KNotes has a 'knote-it bookmarklet' link in the contribute/manage sidebar. Add this to your browser bookmarks/favourites and invoke it anywhere to open a new weblog entry edit form pre-populated to link to the page you are viewing at the time (selected text will be used as initial content of the blog entry body). We will shortly add a pop-up-blocker friendly bookmarklet.
• Almost all the API clients also have bookmarklets for quickly 'blogging' web content. For instance ecto has an 'ectoise' bookmarklet. See the documentation for your API client to seee how to install bookmarklets and customise their behaviour.

4 - how to edit entries

A - through the web:

• you will get a toolbar just beneath any entry you are allowed to edit, the pencil icon is for editing
• if clicked from an aggregate view, this opens a mini 'window' within the page ( saving round-trip time )
• if from a one-entry (permalink) view it should open a normal plone edit form

B - through an API client

• usually just find the entry in your client's display and double-click

5 - how to add an attachment to an entry

A - through the web:

• if you are allowed to attach files to an entry, you will see a little MSWord-like icon in the toolbar just beneath the item
• this creates a new KNExFile object within the blog-entry

• almost all clients let you add attachments ithin the body of an entry as you edit its text
• -- that means that the attachments and entry are created in what seems One Step
• -- much more convenient

6 - how to add a trackback-generating link to an entry

A - through the web:

• Note that one trackback-triggering link can be created at the same time as you submit a new blog or discussion entry - fields for this appear near the bottom of the blog entry edit form on first edit
• For adding further trackbacking links: if you are allowed to add trackback-triggering links to an entry, you will see a little Link-like icon in the toolbar just beneath the item
• this creates a new KNLink object within the blog-entry
• you can untick a checkbox in the edit form for the KNLink if you do not want a trackback ping fired off
• ( there is also a blog-level pref for this; eg important for private blogs )

B - through an API client - the easy way!

• almost all clients let you links within the body of an entry as you edit its text
• -- any links within the body are parsed out and turned into KNLink objects
• -- much more convenient
• -- exceptions: if the link already exists it stays there but is not duplicated on subsequent edits; if it has rel="tag" attribute it is ignored (eg technorati tags)

7 - how to set up shared blogging and other permissions

• - if you can manage, you see a link in manage sidebar for 'Set up sharing permissions'
• - this is complicated and fully featured but lmost self-explanatory
• - quite powerful
• - we'll write help for that asap
• - if you have moderator or higher (eg manager) role you see a link in manage sidebar for 'Delegate Moderators/Managers'
• - this lets you assign moderator roles to specific members or groups ( but no more powerful than your own roles )

... there are many other bits of how-to that need to be written ( KNotes is very full-featured :o)

... I'll try to get back to you with bits of documentation as soon as we get a chance to start writing them

cheers

Mike