David Scotson

One of the problems with Fair Use is that it's a bit of a wooly concept. I can say however, that you don't need to cite the source for it to be fair use, and that some cases have been upheld where the entire original content has been reproduced.

There's more info and background reading at the Wikipedia page on Fair Use

I'd agree with Martin that this doesn't appear (going by my limited knowledge of the facts and understanding of Fair Use) to be a legal issue, more an etiquette problem, so informing the other party that they are being rude, possibly publicly in the same forum that they republished your material, may have a more lasting impact than telling them they are (possibly) breaking the law.

Woah, big topic. I'll try to condense my reply as much as possible, sorry for any terseness.

Blogs that aren't public are, in my opinion, not blogs. And I don't think anyone that considers themselves a blogging expert i.e. goes to conferences and has 'blogger' in their job description or business card is going to think so either. You could probably make a case for intranet-blogs within a organization or school, but private blogs in particular, that is one's that only the author can read, boggle my mind and stretch the concept further than it can go.

I think if you are going to take advantage of externally generated concepts like blogs or wikis, then it is counter-productive to drift from what these things mean to non-Moodlers. Otherwise people can't tranfer their knowledge.

I fully support combining these things in the back end code, but suggest moving them further apart from the users perspective. This means getting at the nub of the problem and not deviating from it, especially not just because you can.

So getting back to 'private blogs' as an example, keep the functionality, just don't call them blogs. Call them 'notebooks' or 'journals' or something that reflects the core of what they are and then remove an unneccesary option from blogs. Remember that flexibility is often a bad thing in software design, as odd as that may seem.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

There is also the issue of control to think about. I assume that educators each have an idea of what kind of communication they are trying to foster. If they add a 'private journal' to the course then they know (or at least hope if it is truly private) that the student will be using that for noting down their thoughts. If a blog allows private communication, group communication, class communication, Moodle-wide communication and public communication does that mean you have to go in and set your paramaters every time you set up a blog? Do you then need to communicate this purpose to the learners or will they guess based on what they aren't allowed to do (and are those options greyed out, or simply missing?)

It worked for me as an 'uploaded file' resource but only after I turned of the option to filter uploaded files in Admin -> Filters.

However, I don't think you'll be able to update the Tiddly Wiki unless you save and then re-upload the file.

edit: hmm, as I was writing this reply the extra border has disappeared. Anyways, as I was saying...

This is a result of some changes I made in HEAD which I think Urs has committed to stable (at least that is how I assume they turned up on Moodle.org). It seems as if only part of the changes have been transferred across e.g. I uploaded new default images without borders at all which aren't in evidence and there appears to be no CSS applied to the default user images (hence the difference in borders). In fact, looking at the HTML code the CSS classes seems to be different from my code too, though I'm not sure why at the moment.

The basic idea is that having a border embedded into the image isn't as flexible as drawing it with CSS instead. The problem in transition of course is that some images already have borders embedded within them (at upload time) so drawing a second border with CSS is overkill.

This obviously isn't a problem for new installations, but there are also several things that could be done to ease the transition for established sites where many images have already been uploaded and had a border added.

• ask people to re-upload their user images (the HEAD image upload script no longer adds borders)

• run a script that replaces the current black borders with a mid-light grey border or resizes the images so that they are 2 pixels larger in height and width (though both these scripts will cause a generation loss as it involves creating a new jpeg and resizing might look odd, probably needs practical testing to see which looks best)

• replace the black border in the CSS with a mid-grey. Older images will still have a thicker border, but it won't be as thick as 2px of black and newer images will have a thinner border. (Which I happen to think is better as the thinner black border is, in my opinion, quite visually brutal, even when only 1px thick.)

Those warnings are visible to anyone if they go to the following URL:

http://www.allcritters.com/class/theme/ac/styles.php

But that is the HTML output of the PHP file when it is being run, rather than the contents of the actual PHP file itself on your server. If you post that styles.php file that you'll find in your theme folder then there may be an obvious problem that someone can spot.