Child pages
  • BlogWoW Requirements
Skip to end of metadata
Go to start of metadata

Information

This details the requirements and requirements gathering process for the Blog Wow! tool in Sakai. This started out with very simple requirements (create a blog in Sakai that works like a normal blog). Some additional details are available at Cafe Bootcamp RSF Blog Tool Exercise. Additionally, the tool was written to address some of the issues and requirements for blogs in the Sakai JIRA.

Some background ramblings

Early work on BlogWow shows a blog placed in a worksite, blog authors can choose to make the blog private, visible to other site members, or public. This is probably a mainstream use-case for teaching scenarios (one author, multiple, selectable audiences), and a reasonable use-case for research sites. But if the goal of adding blogging is to support a personal diary that is not site dependent, it is not clear how this would work. One possibility may be that a personal 'master blog' can be maintained in a users 'my workspace' that is able to optionally incorporate site blog entries by the same author. Otherwise an author may have many blogs and no obvious way to link them together. OSP is also thinking about Blog support. OSP might wish to extend the normal categorisation tagging to include things like making posts 'goal aware'. The tool may need to be 'group aware' within a site. I believe there is also a use-case for a group-editable blog as per the Lancaster Blogger.

I think it is useful to have a common frame of reference to discuss Blog features. I suggest two Wikipedia entries: Blog and Blog Software. I am particularly interested in the 'Features' and 'Other Applications' sections of the Blog Software page and the link on using a blog to create a web site:. I'd really like to see an account in similar terms of the purpose and features of BlogWow.

It is noticable that Wiki's can readily support most features of a blog. Oxford may be working on a tool that allows collaborative document writing in html rather than wiki language, which may be helpful for group editing of a group blog. It may be useful to consider generic personal and shared content editing where Blog represents a particular date-oriented presentation.

I think one of the things that's significant about a blog is that it allows non-technical people to simply produce a pleasing display. On this level alone both wiki tools and html-authoring tools will likely continue to fall short of our goal, since even WYSIWYG editors for such things tend to bring in more complexity than a blog really needs.

Not that there aren't ways around those problems, but it's worth emphasizing that the technical simplicity and usability of the authoring environment is a critical requirement. CDF

We also want to start thinking of criteria for promotion to a full tool (clustering, help, etc.) to which I would add the criteria: at least 3 institutions can support, accessible to Fluid standards, internationalised (Note: Current tool is i18n and l10n compliant -AZ).

The generic considerations could lead to unacceptable delay in getting a simple tool into use, but it is worth considering the potential for future overlap in order to produce compact and maintainable code to minimise institutional support requirements.

Picking up on the Wikipedia opening description of Blog "a category of software which consists of a specialized form of Content Management Systems specifically designed for creating and maintaining weblogs" and noting that rWiki is now being used in several places as another form of Content Management System in which Ian is beginning to think of a publishing step to create a static html output in JCR, it occurs to me that we might usefully conceive of a common back-end 'content framework' alongside the 'messaging framework'

Such a framework could support a lot of portfolio scenarios.

I'd like to say that I don't see the Lancaster Blog as being a blog in the conventional sense of the word, but much more of a group research collaboration tool. (Harriet)

A Blog in a Sakai My Workspace

(further ramblings by Clay)

The My Workspace blog seems really to be the most natural fit for bloggy things: the individual is the source from which all things flow. I'd like to jog down the road such an approach might take us. Some brainstorm-strawman-ing to see where this might start to break down:

  • Blog entries are always composed in a My Workspace. This is the authoring environment.
  • Blog entries may be tagged, and possible tags include the names/IDs of sites to which the user's account is joined.
  • Blog tools in worksites are essentially views on blog entries that have been tagged for that site.
  • Blog entries tagged with a particular site's descriptor will appear in that site's Blog tool, if such is enabled, and if the user has an appropriate permission (say, blog.add) for that site.
  • The Blog tool has 3 modes:
    • a gateway mode, where one can find all the public blogs on the system, sorted by user, etc.
    • an authoring mode, which is what appears in My Workspace
    • a view or synoptic mode, which is what appears in worksites, and what also appears when one views a public blog

This is the sort of thing I feel will be most intuitive for those familiar with real blogs outside Sakai. I think we will find a strong call to be able to post from within a worksite as well though (i.e. I'm looking through my Biology 101 blog posts and want to create a new post that captures my reflections. I won't want to have to cut across to a separate tool, I will want to do it there and then - almost like a file picker/helper - as a way to insert something directly into the blog from wherever I am that blog is enabled. (JohnN) PS It occurs to me that some institutions may operate without MyWorksite enabled, in which case we would need to consider the implications for a Blog designed to work primarily in MyWorksite

Tentative Feature list based on Wikipedia definition of a 'Blog'

Wikipedia 'Blog' Feature

BlogWow implementation

Title, the main title, or headline, of the post

(tick)

Body, main content of the post

(tick) Note: FCK Editor not implemented, does this mean no html/scripting limitations?

Permalink, the URL of the full, individual article

(error) Haven't seen this

Post Date, date and time the post was published

(tick)

A blog entry optionally includes the following:

 

Comments - Comments are a way to provide discussion on blog entries. Readers can leave a comment on a post, which can correct errors or contain their opinion on the post or the post's subject. Services like coComment aim to ease discussion through comments, by allowing tracking of them.

(tick) Don't know if comment moderation is possible and/or comment removal by blog owner

Categories (or tags) - subjects that the entry discusses

(error)

Trackback and or pingback - links to other sites that refer to the entry

(error)

Blogroll - links to other blogs that the blogger favors

(error)

  • No labels

4 Comments

  1. 1) Note: FCK Editor not implemented, does this mean no html/scripting limitations? - not sure what this means, we are using fckeditor for editing in blogwow and it allows all kinds of scripts
    2) Don't know if comment moderation is possible and/or comment removal by blog owner - No on the first one and no on the second one (though the second would be quite easy)
    3) Permalink, the URL of the full, individual article - yes, we have this, the url only appears in the RSS feed, I suppose we could expose it elsewhere in the UI pretty easily

    1. 1) If we are allowing public commenting, what safety issues are there in the html (e.g. from stealing cookies to scriptkiddies inserting malicious javascript or html code to exploit vulnerable browsers). I had been looking at a template that said (FCK Editor not implemented). Glad to see it is, but don't know what restrictions on potentially malicious code from the public is implied. This should be part of an overall security analysis (e.g. will anonymous comments be accepted)
      2) I would think if you are going to accept comments from the public, the ability to remove them if inappropriate is essential (otherwise you would have to take down the whole blog).
      3) Exposing the URL in the UI seems to be part of requirements for a 'normal blog' if Wikipedia is to be trusted. I'll file this as a JIRA feature request.

      1. It occurs to me that the best way of handling security issues in comments may be to accept plain text only. An alternative would be to use an FCK editor with most options switched off - assuming that is an effective way of preventing harmful scripts and html. On balance I think I favour plain text only.

        1. We have explicitly added script cleaning to the blog code which strips out malicious tags. This does not stop the user from entering colorful tags, however, it will stop XSS attacks.

          That said, comments are currently in plain text only to avoid people putting in ads or other malicious text. They are also NOT public (i.e. you have to be logged in to comment). If we decide to support anonymous commenting then we need a captcha system to stop ads and spam.

          I should clarify #2 above: We do support moderation of comments, however, we do NOT allow the blog owner to do this moderation, it has to be done by a maintainer for the site currently (this is a limitation imposed on us by the Sakai permissions scheme). It would be pretty easy to allow the owner to moderate their own blog since we do have the mechanism for removing comments.