The picture above represents the “to-do” lists for a couple of courses that we are supporting this semester. (Thankfully in both cases, most of these to-do’s are ta-done.) In each case, we are setting up weblogs for each student, as well as for the instructor. Simple enough. Where things get a bit tricky is in the particular needs and preferences that are seemingly unique to each course. The need for global password-read protection so that only participants can read the blogs. And a deeper level of security so that certain entries can only be read by the instructor. Helping the instructor to read 35 weblogs. Aggregating entries and re-publishing them on an uber-blog by course module, and by subject matter (using a certain aggrssively-named RSS remixer that I hope I can start talking about soon). Oh yes, both of these courses are delivered exclusively online, so there is no opportunity for a face-to-face workshop to train the students in the basics of weblogging, much less on how to manage the hacks we’ve installed to make the security and aggregation possible.
I suppose this would be easier with Drupal or some other communal blogging platform. But one upside of this approach is that each student will be able to install their own unique design and also use their blogs for non-course purposes if they wish. And since the toughest part of all this (by far) is implementing adequate-yet-usable security in MT, I confess to looking with some longing at Will Richardson’s description of the latest Manilla release (follow-up here). Like it or not, I’ve learned that some facility for privacy controls is essential for weblog adoption at UBC.
And these are just two of the courses we are supporting this semester. There are two others of similar scale, and a dozen or so more new ones on a smaller scale (including the course I’m co-teaching), and countless more returning. Because the new server environment installation happened much later than anticipated, we’re cramming about two months of planned work into two weeks — which would be simply impossible were it not for the heroic efforts of our enigmatic support wizard Sir Frank.
All this growth with no marketing whatsoever. And I’m not even going to mention the hot new wiki projects that are starting up (at least, not now). This stuff is catching on.
The irony of course, is that some of the concerns you mention, the need for consistent (& easy) authentication snd authorization, scaling up implementations without scaling up implementors…, were some of the original motivations for inventing CMS (oh, so your course needs a discussion board and file exchange…oh so your course needs a discussion board, file exchange and list serv…oh, so your course needs a … you get the picture). But of course, we won’t make those same mistakes twice, right 😉 Good luck! Sounds like a crazy and exciting fall for you. Cheers, Scott
Here’s a crux, for me anyway:
“But one upside of this approach is that each student will be able to install their own unique design and also use their blogs for non-course purposes if they wish.”
That’s a tremendous upside, and one way this design differs fundamentally from the usual CMS implementations. Why is it crucial? Because user-devised designs and non-course purposes take education out of the please-step-on-our-conveyor-belt model and into a project-based, customized, and extensible work environment that feels to the user as if it’s theirs. How can we expect our students to achieve a haptic sense of their learning unless we let them hold it in their hands?
Thanks for this post Blamb – it shows the speed at which things are moving on and highlights the fact that ownership and read/write web conserns are being addressed on the ground and not just in theory… really look forward to seeing what it is you come up with and what works/doesn’t work for you and your students.