KNotations

Yup. It was time again to review the behaviour of some new stuff in what the folks in the NGRF site-development team have come to call My Favourite Browser. And, of course, there were problems where glaring bugs in IE's implementation of CSS conflicted with our attempts to use terse semantic markup and pure-css layouts.

This time around, there were problems with the display of listed embedded discussion summaries, the default style of our weblogs, and with with the convenience pretty-floating images for teamtask decoration - in each case, clean semantic markup and straightforward styling ran across bizarre flaws in IE's rendering engine.

listed embedded discussion summaries - disappearing text

(These appear optionally in any indexFolder render; tersely showing the most recent discussion items from anywhere within the subcontent). This was another case of the weird 'disappearing text' bug, which can be worked around by setting a height:1% explicitly for content which has a clear implicit height of its own. Took us hour to hunt down that fix some time ago; thank heavens we remember it :O) There is still some odd behaviour in these lists - which are just a series of a's - because the links are given little icons as bg images, and IE for some reason behaves very badly with css bg images and hover's... some versions attempt to fetch the image repeatedly, for instance, so there is a noticable flicker when hovering even though the :hover styling does not change anything about the background-image... sigh.

default style of our weblogs - h1 in the context message caused left-styled sidebar to clear beneath main content

The default style for knotes weblogs - which I do know needs a lot of work and rationalising - places the sidebar div at the left of the main blog content with css. Somehow, the h1 in our context messages when viewing categories etc caused this to clear so that it appeared beneath the main blog content. Changing the h1 to an h3 worked around this. We also tuck the blog into a maximum width of about 900px in that style, so that a banner image runs across the top, and so that the main blog text stays within readable em-widths without having to hack 'p' etc tags to get readable widths in IE/win. Blinking 'eck, I forgot to apply the javascript expression workaround for max-width to the blog-content wrapper class... so it was displaying across the width of the page and looking very peculiar. Why-o-why can't a company the size of Microsoft manage to implement a simple and standard property like max-width? We also had to use an expresion hack to effect the centering of the wrapper div in the page...

pretty-floating image for teamtask decoration - the dreaded float against dl bug

For the main seed-content of team tasks, I have a few little utilit classes which give the decoration images nice frame-like borders and float them left or right. When these render next to the dl's for embedded discussion topics, they 'cut off' so that the area of the image which would have been shown from about 10px below the top of the next-door dl just disappears. The dl content and it border clearly appear to stop before they 'get to' the floated image... but something causes the image to disappear below that imaginary line :O( Ended up having to get the dl class to clear both in ie (again using the expression hack for branching)...

Why do developers have to waste time we could be spending on functionality fiddling to work around bugs in this notorious browser? Why can't MSoft at least offer some updates to fix these bugs and complete their implementation of css? Why don't users everywhere revolt and Get Firefox?

I've been a bit lax in keeping this weblog up to date on developments in knotes. In large part that's because we've been very hard at work on detailed feature grinding :O) Also because we've all been battling the 'flu :O(

In the past two weeks we've made a lot of progress on the control of collaboration in discussions and weblogs... on moderatd discussion configuration and configuration and control for group weblogging. We've got some test cases of team-tasks with embedded group weblogs working, but still have some work to do on completing the features for controlling what users have what rights within a weblog and its discussions.

We've also made quite a lot of progress on resource-centric views and discussion frameworks, on which much more later.

As part of our participation in the EVAL-4 project, KnowNet has recently ported a venerable old evaluation tool to play well in Plone sites:

Eval Mentor is a comprehensive online questionnaire which guides and buttresses a dialogue between an evaluator and a project which is commissioning or planning an evaluation.

We were happy to see that the porting process went very quickly - largely because Mentor is heavy on XML and clientside javascript-DOM processing, so all the server needs to know about an instance is its XML data string.

What surprised us (yes, even us :o) was how extremely easy it was to add a knotes group weblog to every Mentor instance (in Mentor, an instance is called a 'dialogue'. The main problems with our old implementation of Mentor were the difficulty of managing users and groups (which is made much simpler by Plone), and the lack of a good system for ad-hoc or focused discussions of issues arising during the Mentor choice-making process. A group weblog is ideal for supporting discussions arising from a Mentor dialogue.

In essence, it only took a dozen lines of simple boiler-plate python script to have every instance of Mentor create within itself a knotes blog. With a little more effort, we can tune the features of these blogs for the purposes Mentor will have in particular, and add fine-grained 'blog-this' affordances within the Mentor questionnaire.

A Plone-based, compact, customisable collaboratibe weblogging system turns out to be a darned useful piece of kit to have at a developer's disposal. We hope that others will be able to explore this kind of integration even further. We'll be releasing Team-Tasks - a resource and goal centred, time-limited collaboration environment which makes use of embedded group weblogs - sometime early in 2005, and hope among ourselves to come up with some more interesting examples of blogging for particular, embedded collaborative purposes.

Graham Attwell has reported that the requirement to join the site before discussing his Wales-Wide Web entries has deterred several people from commenting in his weblog, and led to email exchanges instead.

We've always known that more conventional 'blog-like' comments would be desirable in knotes blogs when used as personal publishing systems, and had made plans to implement lightweight, non-members comments in January 2005. I thought it worth explaining why we decided to implement the heavy-weight 'real' members' discussions as the default: the added-value of knotes, as compared with Blogger, say, is that is can embed in specifically collaborative environments, and can be adapted to specific collaboration goals. For those purposes, 'real' discussion - integrated with portal members' discussions in general, or in other collaboration contexts, is a must.

We do, however, recognise that there are other purposes for which knotes blogs can be extremely useful - purposes for which ad-hoc comments from non-members are a necessary feature. (And note that, in the interim, a non-knotes weblog (from TypePad etc) can still integrate fairly well with knotes-powered Plone sites and discussions, because knotes makes all Plone content and knotes discussions trackback aware).

We've considered several options, including running parallel, hidden Plone sites to encapsulate membership for weblog comments outwith the site-membership roster, but think that we'll begin with a crude, all-SQL solution which just implements the usual email-address+name+comment convention, completely outside any portal_membership information. We'll of course want to have some means of 'promoting' such lightweight comments into real discussion threads at some later point.

Of course, allowing non-member comments opens the possibility of comment-spam problems. We'd appreciate any advice on dealing with that one, though we're pretty sure that we can effect filtering such as Stephen's Web uses to minimise this risk.

Expect to see lightweight comments a few weeks after we release a public beta of knotes. Please email us if you have anything to add on this issue before then, or trackback to this entry with your thoughts.

• from: SciPy Scientific Tools for Python - About SciPy

From Travis Oliphant's SciPy Tutorial :


SciPy is a collection of mathematical algorithms and convenience functions built on the Numeric extension for Python. It adds significant power to the interactive Python session by exposing the user to high-level commands and classes for the manipulation and visualization of data. With SciPy, an interactive Python session becomes a data-processing and system-prototyping environment rivaling sytems such as Matlab, IDL, Octave, R-Lab, and SciLab.


The additional power of using SciPy within Python, however, is that a powerful programming language is also available for use in developing sophisticated programs and specialized applications. Scientific applications written in SciPy benefit from the development of additional modules in numerous niches of the software landscape by developers across the world. Everything from parallel programming to web and database subroutines and classes have been made available to the Python programmer. All of this power is available in addition to the mathematical libraries in SciPy.