• 
  Please support me in the 2010 Ride to Conquer Cancer - last year we were able to raise $6.9 million for the Alberta Cancer Foundation - hopefully we can raise even more in 2010!

  ---

• Search for:

• Pages

  • About
    • Colophon
    • Contact
    • Curriculum Vitae
    • Presentations
  • Archives
    • Recent Comments
    • Shared Items
  • Asides
  • Photography
  • WordPress
    • Akismet Credit Inserter
    • Post Revision Display

• Categories

  • aside
  • digital photography sessions
  • fun
  • general
  • photography
  • work

• Blog under the Creative Commons Attribution 3.0 License
  

I gave a presentation this morning as part of Faculty Technology Days 2007. I was asked a few weeks ago if I'd like to talk about weblogs and wikis, and I couldn't come up a reason why not, so they slotted me in. In the meantime, I've been doing a lot of thinking about weblogs, wikis, academic publishing, and being Open, Connected and Social. So I decided to try to subvert my presentation slightly, into a more open-content-is-good kind of talk (but still based on blogs and wikis for much of it). What better way to do that, than to present directly from a wiki? It's worked very well for Brian Lamb – all of his presentations are wiki-driven.

Yesterday, I came across a link to some Firefox Greasemonkey scripts for use with Mediawiki. (aside: I'd thought I'd seen the link via Twitter, but can't seem to find who said it there – I remembered it being from Scott Leslie, but it could have been through del.icio.us, or via a comment he made on a blog somewhere…)

Anyway, on scanning through the list, one jumped out at me. Not literally, but that would have been cool. The "Wikipedia Presentation" script sounded very cool. I'm a big fan of the wiki-as-presentation style, and this mashed up a Mediawiki page with the awesome S5 html presentation engine. By installing this script, it automatically enables viewing any Mediawiki page as a full-screen slideware presentation.

So, I installed it.

And it failed. The current version of the script has been updated for the current version of Mediawiki. I'm using an older version (because my server doesn't have the latest PHP bits to run the latest MediaWiki). Older Mediawiki pages use div elements to mark sections of a page, while newer versions use spans. After some extremely complicated editing of the Greasemonkey script (changing the 3 instances of "span" to say "div" instead) I was off and running. My modified (i.e., reverted) version of the Greasemonkey script is available here.

The cool thing, if you're using a Mac (and, really, what ISN'T cooler if you're using a Mac) is that you can install an application called Mira to enable using the Apple Remote to control Firefox. I bound the back/forward buttons on the remote to the left/right arrow keys, and I was navigating through a Mediawiki page as a full-screen presentation, using a wireless remote.

With the script installed, the wiki/presentation page for this presentation should show a "Start Presentation" link right beneath the article title.

There was one minor tweak I needed to make. By default, the content of the slide starts too far down the screen. When using a projector, you may be stuck at 800×600, and a bunch of that was sucked up by empty space at the top. So, I overrode one of the styles to make it start higher up. There are a couple of ways you can do this. If you have the Web Developer extension installed, just add a new User Style Sheet containing the style below. Otherwise, edit your Mediawiki skin (in my case, the file at /skins/monobook/main.css ) to add this: 

#wikipedia_presentation {     margin-top: 0 !important;}

I must have blinked when this was announced, but OpenAcademic.org sounds like a perfect scenario. Development efforts to integrate some of the biggest open source tools used in online education. It sounds like the goal is to come up with a way for Drupal, Elgg, Mediawiki and Moodle to all play nicely together, in such a way as to be easily deployable and maintainable by even the smallest school. Rather than attempting to build The One True LMS, they’re taking the approach of playing to the strengths of the available tools, and putting the effort into integration.

The really cool thing is a documented commitment by the OpenAcademic.org team to not fork projects, and to contribute any code to the relevant communities. So, they’ll be hacking on each of these applications directly, with all improvements freely available to everyone.

Personally, I think this is one of the biggest and coolest developments in online education for the year. I’m ashamed that I missed the announcement almost a month ago.

I’ve been spending almost all of my time lately in Drupal, with some time in Moodle. It’s pretty obvious that each has its own strengths (and weaknesses), and that spending effort to duplicate each package’s feature set would be wasteful and counterproductive. Having an effective way to integrate these various tools would be amazingly powerful, especially as more applications, platforms and tools are brought into the mix.

Imagine an elearning ecosystem that ties in Drupal, Mediawiki, Elgg, Moodle, Blackboard, WebCT, Flickr, del.icio.us, Facebook, YouTube, etc… in a flexible system that can adapt to any pedagogical needs. Sweet.

Our little experiment at wiki.ucalgary.ca has been having some rough times. It’s gotten so frustrating that I’d had to temporarily disable new account creation in a desparate attempt to thwart the automated spambots (which automatically create a new account for each edit so it’s harder to roll them back).

I’ve just updated the wiki to the latest and greatest Mediawiki 1.6.1, and one of the new extensions that work with this version is one called ConfirmEdit. It can be configured to challenge “users” with a captcha upon account creation, as well as on each page edit (even only on page edits containing a URL).

For now, I’ve set the wiki up so that all edits require an account (no anonymous edits – I can live with that), and all account creations must provide a correct simple captcha response. Once you’ve created an account, you should never see the captcha again.

I’m settling for the “SimpleCaptcha” implementation – it’s a math question rather than a nasty wordimage. As much as I hate captchas is general, I figure it’s easy enough to fire up Calculator.app when you create an account, and shouldn’t block anyone with visual challenges.

wiki.ucalgary.ca has been under a sustained spam attack all day. What started out as a minor irritation has grown into something that is impossible to ignore. The spammer is somehow getting around both Bad Behavior and Spam Blacklist extensions (I’ve blacklisted their URLs, but they keep getting edits into the system). This is one of the more frustrating aspects of trying to do things in an open manner. If there is the slightest possibility that something will be subverted for spamilicious purposes, it will be. And most likely it will happen before more than a handful of legitimate users are able to take advantage of a service.

These cretins are being rather clever (or, they’ve gotten some good Script Kiddie l337 tools) because they’re coming from many different (and changing) IP addresses, and each edit is accompanied by its very own account creation. So I can’t just block IPs, or roll back all edits by a user. So, I’ve had to disable account creation for now until I can figure out wtf to do about this.

To the spammer(s): may you rot in the most insidious inner circle of hell, reserved for parasites like yourself who find it necessary to suck energy and resources from (otherwise) free and open educational resources.

One of the biggest questions I get from people who want to use wiki.ucalgary.ca is “How do I protect or lock a page?” I’ve had to respond with a gentle suggestion that the wiki is an open resource by design, but that doesn’t go very far. There are valid reasons for locking down a wiki – ranging from sensitive information that shouldn’t be In The Wild, to protecting privacy (K-12 collaborations can’t have info about kids leaking onto the ‘net for obvious reasons).

It really felt counterproductive to just refer folks to other external tools like Writely. They’re great tools, but if wiki is to be a valued resource on campus, it should serve all core requirements. I’m struggling with the possibility of migrating away from MediaWiki (which doesn’t handle security, by design), or possibly adding a second “secure” wiki as an option.

I spent an hour or so this evening playing around with TikiWiki – some pretty fully-featured stuff (if a little “busy” as a result) that should solve any/all issues. I’ll keep playing with Tiki to get a better feel for it.

I’d installed Spam_blacklist back in October, but we’d been getting the occasional spam attack since then, lately every single weekend. So I just dug into the Mediawiki config, and realized that Spam_blacklist never got properly configured on my server, meaning it was essentially running wide open. Crap. What a waste of time that was. Paul and I have removed dozens/hundreds of spams over the last few weeks, and I was assuming Spam_blacklist was enabled properly. Oops.

So, if you’re running Mediawiki, be sure to carefully (re)follow the instructions, especially Morbus Iff’s patch for 1.5 compatibility (I had to manually patch the file, since patch was barfing on an unmatched }).

The wiki is now configured to pull the blacklist from meta.wikimedia.org every hour, and will check edits against both that blacklist and the one we’re growing ourselves.

Things to watch out for:

• If you’re running the latest MediaWiki (1.5.x), be sure you’ve applied Morbus Iff’s patch.
• Also, be sure you’ve moved your local Spam_blacklist page to Mediawiki:Spam_blacklist so the plugin can see it. It apparently must be in the Mediawiki: namespace.
• Fix your copy of load_lists.sh to use the proper URL for updating the blacklist – bots have to use http://meta.wikimedia.org/w/index.php?title=Spam_blacklist&action=raw
• If you want, add the load_lists.sh file to your crontab so it runs automatically. I think the plugin tries to do that, but better safe than sorry
• Test your wiki’s now-hopefully-working antispam measures. Try to edit a page with a URL from the shared blacklist, then one from your own. Hopefully both attempts fail.
• (hopefully) relax a bit, and with luck the spammers will move on to greener pastures…

Why on earth isn’t this plugin included with the core Mediawiki distro? And why hasn’t the download been updated for 1.5 compatibility yet? It would be great to keep it up to date, and to make it easier to get it running properly. There are likely a LOT of Mediawiki instances that aren’t configured properly, making all Mediawiki instances nice, juicy targets.

I’ve been asked by a couple of people about ways to restrict access to pages in wiki.ucalgary.ca. My initial response was often something like “wha? that’s just wrong. you don’t lock down wikis…”

Then, they explained more about what they wanted to do, and why they couldn’t just leave the pages out In The Wild and trust that it was private through obscurity. Things like collaborative student experimental writing, where it would be a Bad Thingâ„¢ if things like the Wayback Machine kept eternal snapshots of not-fully-baked writing, which could come back to haunt someone later. Shouldn’t have to throw the baby out with the bathwater – restricting access to pages within the wiki would let them play, without exposing them more than they’re comfortable with.

So I did some Googling over the last few months, and still haven’t come up with a solution I’m completely happy with. The closest I came to a workable solution is the Access Control extension – but that needed some tweaking before it would run as expected (my modified file), and I fear it exposes some pretty scary security risks. What happens if Joe Spamass edits Main_Page and adds a fake access control list to the page? I’ve installed it, but will be keeping a close eye on it, and maintaining nightly MySQL dumps of the wiki databases Just In Caseâ„¢.

I also found this patch to enable a “restrict” feature, but it really just creates a “penalty box” where pages can be sent, and only people who are allowed to see the “penalty box” can see the pages – but there’s no fine granularity, it’s an all-or-nothing thing.

I really don’t know why this isn’t part of the core feature set of Mediawiki. Sure, the Wikipedia wouldn’t use it, but how many gazillion corporate/institutional wikis could benefit (or require) this feature? There are a lot of folks who are interested in this, but no real solutions that I’ve found…