David Scotson

You might want to have a look at the section on Fieldsets in the forms and interaction chapter of Joe Clark's Building Accessible Websites (though the entire chapter, and book are good reading too) which suggests ways to split and group forms in a way useful for all users, rather than depend on old-fashioned HTML tables.

Though probably these problems can and should be solved by an automated form creation library, of which there has long been talk of adopting. In this case individual developers would only have to list the kind's of information they require from the user and the HTML code creation along with all necessary accessibilty, usability, and error checking would be generated automatically. I'm not sure whether any suitable project has been found for this use yet.

The best way is to avoid using a database at all and instead use search engine technology, as seen in Google and Yahoo. The best open source contender is Lucene, a java application that is widely ported and integrated with other languages.

At the moment PHP seems to be lagging behind other languages in their support for this technology, but the recent emergence of 2 seperate Web Service-enabled Lucene search engines may be the key to breaking through this barrier (though sadly this probably rules it out for most people running Moodle on standard commercial hosting, or at least increases the complexity greatly).

• Lucence Web Service API

• solr

The second is more recent and more advanced.

The most readable introduction to the relevant technology is the On Search series written by Tim Bray.

However, given the lack of PHP-Lucene integration, and the portablity needs of Moodle it seems likely that lowest common denominator SQL methods will be the best available technology for the moment.

I agree Joseph, but I'd go further and suggest that styles should, whenever possible, be attached to tags with semantic meaning.

To continue your example the P class could be replaced with a H1/2/3 tag since the title of the theme also acts as a suitable header. Then there would be no need to specify another font size.

I'd also suggest CSS validation as a good way to spot typos and thinkos like font-style: bold

The State of Open Source Software

by Rob Abel, March 1, 2006

This report is the first of a series. It provides an overview of the use and attitudes toward open source software in higher education. Follow-up reports will provide details on best practices for implementing open source solutions.

http://www.a-hec.org/open_source_state.html

A interesting sounding report focusing on Open Source educational tools in U.S. higher education. It only appears to be available to members but certain portions have been made public, for example:

• 32% of institutions haven't seriously considered open source
• 23% considering Moodle
• 19% think Moodle is viable today
• 5% currently using Moodle

There's also some very intersting comments attached to this (rather negatively toned) Inside Higher Ed commentary piece

The slashdot coverage is also interesting (give or take the usual wild tangents and obsessions) especially as the report author contributes. His comments in particular, remind me of someone here in Moodle.org, who seemingly accurately predicted that Sakai would play directly into people's stereotypes of open source being difficult to set up and administer, especially in the US where it is promoted more heavily and where attitudes to Open Source can sometimes seem a bit backward generally.

While the author seems very genuine, you can tell from his comments that he can't quite believe that Open Source (e.g. Moodle) could in any way surpass proprietary software, whether you're talking about ease of set-up, maintenance costs, installed base, usability, scalability (always my personal favourite) etc. It's a tough prejudice to shift, even in the honest and open-minded.

This is a good idea, though it could be improved by attaching the styles to the A tag rather than the P tag. This means the image becomes a part of the clickable link area too.

You'll save some typing too, if you attached all the common styles to a single CSS declaration, and only changed the image for each particular link.

Note that if you are creating class names to attach these images, you need one per link, rather than one per image. Some of the images are re-used for two different concepts and if they share a class you can't change one image without changing both.