Blogs in the classroom [1].

Blogs in the classroom.

Some requests for comments on my experience mandating blogs as part of TEC924 have been popping up lately. The timing is good since I’m in the midst of reviewing and updating the course for the next time it will be offered come January.

  Weblogs as part of a course design

  In another course I teach on technology management and electronic commerce, I had already experimented with using a weblog as a one-way communications tool from teacher to students. A course specific weblog turns out to be an excellent tool for supplementing classroom time.

  For the design of the knowledge management course, one central perspective was that of the individual knowledge worker. I wanted students to explore knowledge management and knowledge sharing issues not only from the organizaiton’s perspective but from their own perspective as knowledge workers with their own knowledge to be managed and shared. I wanted to avoid the notion that knowledge management was some sort of problem that belonged to someone else in the organization.

  Given that perspective, it was natural to include the topic of k-logs as an important development in the knowledge management field. If you happen to prefer “learning by doing” it was a straightforward step to build maintaining a weblog into the course design.

It’s also possible to take learn-by-doing to extremes and some of that happened during the conduct of the course.

  Choosing a blogging tool

  I selected Radio as the blogging tool for several reasons. Most importantly, I already used it and knew where its warts were. Beyond that immensely practical reason, I also had some other logic for my choice. Chief among those was that Radio stores weblog entries locally. Other important elements included Radio’s news aggregator and subscription mechanism.

  Although I could have set up a Radio Community Server, I opted instead to rely on Radio’s out of the box setup of providing a hosted account to users. As a first-time experiment, I did not want to involve Kellogg’s excellent IT group. It would have introduced additional problems of support and learning curves for a group that already has plenty on its own plate. Moreover, it would have required proposals and permission. With Radio, I could run the experiment within the confines of what I could directly control.

  The one significant technical problem I encountered with Radio was that some students in the evening MBA program have limited access to computers that they are free to install software on. Students in the full-time program are expected to invest in a laptop for the duration of the program and campus net access (both wired and wi-fi) is excellent. For the evening students we had to work through a handful of problems with firewalls in work envrionments or the limits of dial-up access. Eventually all but one student succeeded in getting Radio installed and operational.

  For the upcoming second run through this course, I expect to stay with Radio. For me the locally maintained database is an advantage. While I can see Seb’s point about a central server-based architecture in an educational setting, I also believe that a distributed architecture is more likely to be the case outside the educational environment. Given that MBAs are my audience I prefer an architecture that is more likely to be what they will encounter later, even if it might create support problems.
[McGee’s Musings]