David Scotson

I think the php referring back to colours in config.php has actually made the CSS more complicated because it makes it too easy to repeat the same value in many places. In CSS you should only have to define a colour once per 'design decision'. I'm not sure it's obvious what I mean by that, I'll try to demonstrate:

Currently (as of the last time I looked at styles.php) each 'thing' defines it's styles separately e.g.

.thing1 {
    color: pink;
}

.thing2 {
    color: pink;
}

If, and only if, these are both pink for the same reason, and it would make sense to change one when you change the other then this is more appropriate:

.thing1, .thing2 {
    color: pink;
}

Obviously this expands so that every item that is pink (for the same reason) is set together in a single style declaration. Therefore there is a single place to change each decision about color, font, border etc. I went through and redid one of the standard themes in this way. I'll see if I can find the file and you can compare them.

With the caveat that I've not looked at the latest 1.5 code yet, here are a few relatively simple things that I think could and should be done for 1.5:

• use .css rather than .php files for stylesheets

  The stylesheets are 99% straight CSS and so having them as .php may scare off designers and definitely does confuse many tools designed for pure .css files. The embedded php is used for only 2 things as far as I am aware:

  • adding the server root to create absolute URLs
  • importing colours from config.php

  CSS can use relative links (with due respect to a very rare bug in a very rarely used older browser) so the first point is unnecessary. The second point leads me straight into my next recommendation:

• we should remove config.php entirely

  config.php supplies colour values that are inserted into the HTML (and also, semi-redundantly, included into the .CSS). While there is a sliver of a valid reason for keeping this for extreme backwards compatibility I think it would be better to junk it completely. It also sets a value concerning custom images. If these were set in CSS then they could be overridden by a theme's CSS too without troubling the PHP engine.

  Note that I've tried to create themes that don't rely on config.php but as of 1.4 there are sections of the HTML that don't have the required id and class 'hooks' to attach styles to them, so you can't override or replace colours specified in the config.php file. Which brings me to:

• add more style hooks in the form of class and id attributes

  Even without changing the substance of the current HTML, the addition of semantically chosen id and class attributes would open up a world of styling opportunities. An example that I filed as a bug (which might be fixed already) is to id the three main columns so that blocks on the left and right hand side of the screen can adopt mirrored (or simply different) styles. Another that I keep tripping over is the desire to target styles at the content of text resources.

• swap tables for lists

  There are a lot of tables in Moodle's layout. I have no real problem with the larger layout tables, though they could be trimmed to their bare minimum. On the other hand, many of the smaller tables could be replaced with unordered lists which can be styled with much greater ease. Basically the more tables replaced the better, but I think if we start with the smallest and work our way up we'll get the biggest bang for buck.

• no inline styles

  Inline styles in attributes are the modern equivalent of font tags and should be removed, without exception, in favour of semantic classes or ids and the relevant CSS style moved to the stylesheet.

I would note that the service has only just entered Beta testing. I foresee this tool becoming very useful, not least to give the other services an impetus to introduce up-to-date search technology before Google Scholar grows and eats their lunch.

Two write-ups that give you a glimpse behind the scenes:

• Resource Shelf (Librarian website)
• Search Engine Watch

Most of the 'complaints' I've read have actually been media-savvy marketing exercises by librarians saying "we've had this stuff for years, but we spent so much on licensing access to all this information, we didn't have enough money left to publicize that fact".

There was also this interesting titbit, in another article:

LaGuardia said she is looking towards a tool called CrossRef to blend the ease of Google with existing library systems. The utility is being developed by Google in conjunction with 29 major academic publishers.

It might not utterly replace every other system out there, but it may only be a matter of time until it does. Personally, I don't like the idea of all scholarly (or web) search being funnelled through a single corporation but I'd rather it was an efficient, effective corporation, one that perceives your business as something to be earned rather than the turgid monopolies that seem to run academic publishing at the moment.

Note that this isn't strictly relevant to Moodle as the system that was the centre of that discussion was a 'campus credit card' style system that had been bought and re-branded to complement their learning system (though the approach to security in general might be inferred).

Short version: The two students settled with Blackboard as their investigations into what they claim were security flaws of the system breached some kind of corporate espionage law. Blackboard maintain there was no problem with the system.

An informative FAQ has links to related settlements, press releases etc.

I've no direct experience but from general chatter I'd say go with Wordpress. I found a link with some hints and advice for making the transition that mentions the 'problem' of multiple blogs.

Interesting aside: when I was searching for that blog (as I thought I had heard comments about multiple blogs in Wordpress before, your question in this forum was the fourth result in Google. I wonder if I just happened to search shortly after an update. I've read that popular and often updated sites can be spidered more often by Google.