Skip Navigation

Sign up

If you sign up for an account on this web site you can customise elements of this site and subscribe to an email newsletter.

If you have an account on this web site you may login.

If you have an account on this site but have forgotten your user name and / or your password then you can request an account reminder email.

Comment component

The 1.6 and 1.8 experimental discussion components should be abandoned and instead a Comment Component should be implemented

We currently have a discussion board in MKDoc-1.6 that uses an IMAP backend to store the data. This has been removed in MKDoc-1.8 for various reasons, mainly because it doesn't get much usage – Before we recreate it, we should figure-out why.

The existing design comes from our experience of various internet discussion forums; basically, we make a lot of use of usenet, mailing-lists and irc.

We hardly ever use web-boards because they are so inefficient as a means of discussion. So the MKDoc discussion board was designed as if it was a threaded newsgroup, with all the features of a decent mail/news client.

A Building Communities with software article by Joel Spolsky has some interesting ideas.

I propose that we accept what we always knew: that the web is a terrible medium for discussion, but a good medium for comment.

A replacement for the discussion board might look like this:

We do away with the Discussion component and its IMAP backend and create a new Comment component.

The Comment component inherits from the Text component, but it has two extra pieces of metadata: Author and Date.

Any authenticated user can add a Comment component to the bottom of any document, however not all document templates will display Comment components – Editors will have to select ‘Blog’ or ‘Comment’ templates to make them visible.

(Allowing comments on any document will allow a future bonus feature where users can create a comment that only Editors can see)

The interface for non-editor users will be a simple ‘Add a comment’ text box at the bottom of the page, with a single ‘Submit’ button and no ‘preview’ functionality – There will be no automatic quoting of previous text.

Editors can add, move, edit or delete Comment components just like any other component – Editors should be encouraged to prune duplicated and off-topic bloat from pages.

New comments are always added at the bottom of a page, so the page reads in rough cronological order – There should be no threading.

Adding a comment via the comment form should not change the last-modified date or the last-modified user

MKDoc::Text::Structured modifications

Any URLs that are automatically hyperlinked should implement the <a rel="nofollow"> spec:

http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html

URLs and long words that are longer than a certain length should be split visually as per google results.

Similarly <pre> text longer than a certain length should be detected and dealt with appropriately.

Up

This document was last modified by Bruno Postle on 2005-08-05 07:43:45
MKDoc Ltd., 31 Psalter Lane, Sheffield, S11 8YL, UK.
Copyright © 2001-2005 MKDoc Ltd.