Our NMC 2004 Small Pieces session intended to make a case for creating effective net-based collaboration using a discrete set of free tools, not so tightly controlled. This was fine, fun, and (frilly), but I wanted to describe here how we are trying to implement this for some real work.

We are headed into the 18th year of a faculty-led initiative for instructional technology at Maricopa called “Ocotillo” (see some history and the details on the metaphor). Dealing with technology, this almost organic organization evolves and re-invents itself, and just this past year, we “flipped” over a structure from representing college interests to topical ones (more details than anyone wants).

Anyhow, bottom line, this coming academic year, we will have four “action groups” each led by a pair of faculty, who will research, promote, prod, disseminate, dissect, and hopefully engage people in the areas of:

  • Learning Objects
  • Hybrid Courses
  • ePortfolios
  • Emerging Learning Technologies

Being a large, decentralized college system in an ever sprawling metropolis, I am vigorously promoting using more technology to share, communicate, and conduct this work, and get us out of the “F2F meeting/workshop” mode. So while ramping up for our Small Pieces presentation, I was also cobbling together a system of weblogs, wikis, and discussion boards, tied together with RSS, tape, and bailing wire, and hoping we can spring this effectively on our system this year.

In what will become a long rambling post, I will describe how this all works together. Brian has already pointed out that this is actually not loosely joined but rather “tight” (a compliment, I hope). And as an off kilter kind of success, before even sharing the URL, this morning already got a drug product spam (MTBlacklist now engaged)…

Here is my best attempt at a map:

Each of our action groups has their own weblog, wiki, and discussion board. The software used is:

In any of these spaces, there are links to move laterally– so from the “Hybrid Courses weblog”, you can quickly jump to “Learning Objects weblog”. But the key thing is that all of the group’s tools feed one central hub site, or Ocotillo Central.

So if we start at Ocotillo Central, we are actually in a weblog. The four colored areas each contain “feeds” from each group’s blog, wiki, and discussion board. We will come back to how the feeds work.

Above the listings for the 4 groups, there is a blog posting for the Ocotilo central blog, and following the link from the main story, beneath this front is a blog specifically for the faculty member who chairs all of the activities can blog on topics that are broad, visionary, etc.

The other blogs that feed the main one use similar templates, just with some different color coded styles:

They will diverge as the authors develop their own style, side content links, categorizing schemes. Each blog has embedded (lower right column) the feeds from that group’s wiki and discussion board. To support the authors, all who are new to MovableType, we provide a Blog Authoring Guide

While we could have used RSS to directly feed the main Ocotillo Central blog, I was not wanting to have something parse 4 feeds for every page load, and there is the whole issue of how you trigger the main page to update when one of the feeding sites change.

The answer was really simple- David Rayne’s MTOtherBLog plug-in for Movable type. Since the four feeding blogs are running under the same installation of MT, this allows the template for the Ocotillo Central blog to hit the same MT database to load the 5 recent entries from each of the feeding blogs:

It is just a matter of providing a tag <MTOtherBlog blog_id="X"> for the context to draw the entries from, where “X” is the id code for the blog providing the “feed”. This was much more efficient than using RSS; there is no need to go through syndication when you are drawing from the same database.

The sneaky part is finding the way for the 4 publishing blogs to be able to trigger a signal when they are updated for the main Ocotillo blog to be rebuilt. Otherwise, new information is not “fed”. The key is to tie the index template for the Ocotillo Central blog to a file on the server:

link-templateThe template that creates the index.php file is linked to a template file named index.template

Now, in each of the 4 blog sites that we want to trigger an update, we just create a new index template, and put the correct relative path to the same files referenced above:

link-from-templateA template from another blog is set to be linked to the same output file (1) and template file (2)

You do not even need to enter any content in the text area below. When you click “Save”, MT fetches the content from the linked template file. But that is not why we bother- they key is the checked box for “Rebuild this template automatically when rebuilding index templates”. This means that any event that triggers a rebuild of your index files in this blog (this happens when you publish a new post), will also trigger a rebuild of this page in another blog directory!

So in summary, the MTOtherBlog plugin provides a simple means for direct syndication.

The Wiki

We included a wiki so we could have a shared space for people to build resource collections, group write outlines of say workshop sessions, and to be able to brainstorm things like desired features in an ePortfolio system. Wikis work well… for people who get some wiki experience under their belt. The choice of UseMod was a bit out of familiarity, its wide use, and simplicity.

Out of the box, wikis are pretty bland and dull looking, so it took a little bit of work to customize the CSS files, and to create a design that has similar color and navigation elements as the weblogs. Adding the navigation bar across the top that leas to other group wikis just required some digging into the output code and adding a line or two of print statements.

So we have our 4 wikis:

I chose to create separate wikis because (a) the code is small so there is not much to creating multiple instances; but more so (b) so each wiki would have an RSS feed for just its updates. If all four shared the same wiki space, there is no easy way to split out the new content from the 4 groups. To assist folks ne to wikis, we actually created a 5th wiki, OcotilloWikiGuide devoted just to providing help information, and we have it appear on each wiki page as an extra navigation bar link labeled “How to Wiki”.

Each wiki provides an RSS feed (example) as part of its RecentChanges (example). Again, while I could have used something to parse this feed and put the 5 newest wiki changes into the Ocotillo Central Blog (and each group’s respective blog), I looked for a simpler solution.

First, all of my blog pages are *.php so I can insert content from external files by a simple PHP include statement in the MT templates. Therefore, I wrote a custom PHP script that uses the Magpie parser to read the feed contents and then write content to 4 include files. Actually I got clever in creating one file that can do this, and it just needs to be passed the directory name that needs to have its wiki feed built. I then set up a cron script to run this every 15 minutes, which updates the 4 wiki include files on cue.

This means that the template for the Ocotillo Central blog needs this in the template for each action group:

or everything below the link to the wiki is read in from the include file generated every 15 minutes (the script inserts a date/time stamp):

wiki-incRed box on content created by converting the wiki RSS feed to a PHP include file

And Now the Discussion Board

The Ocotillo discussion board is one instance of a phpBB site, but is organized into different “forums” for each Action Group, By having it inside one board, the account a user creates can be used to jump to any of the discussions. The way links are constructed to each Action group, one sees as an initial view just the subtopic for that action group, the other groups are “collapsed”.

Compare the board links for:

Like good “loose” technologies, phpBB has a way to extend its functionality via a set of “mods” While there is a mod you can add to generate RSS from these bulletin boards, the code was huge! Sprawling! I saw lots of tax on the database.

Therefore, I created a strategy similar to the approach for wikis. Rather than RSS, I used the Fetch All phpBB mod– this one merely allows you to load desired info from a board into an array. So I modified one of the sample scripts to filter out the board entries just from say the form for “Hybrid Courses”, load it into an array, and then write out a small include file with the board message title, link, and date posted. In a similar matter as the wikis, I now had 4 include files that are created every 15 minutes with the 5 newest postings to each action group discussion area.

Irony

So here is the kicker, I have built this complex structure of 4 blogs connected to 4 wikis and 4 discussion areas, and all of these are “feeding” content to another weblog, all of this more or less is “syndication”, but none of it is really RSS- it just acts like it!. And it is rather “not so loosely joined” as we have created some well defined connections between the pieces.

Using the Pieces

This is a lot of new technology to toss at our new faculty leaders of these groups, and we are helping them become familiar with it over the summer before we unleash on the larger group of faculty and staff in our system. Some of the questions that came early is a desire to know when to blog, when to wiki, when to go to the discussion board. I am hopeful in the experience of using tools this summer, they will develop the answers- we did provide a bit of a framework:

Ocotillo 2004-2005 Technology Trio: Blogs, Boards, Wikis (“Oh My”) [160k PDF]

it is all quite experimental, but the 4 faculty chairs I met with this week were very excited and have already jumped in to start playing. We will not have a clear indication of how this works until we let it loose in late August, and hopefully get a following of regular users.

The post "Small Pieces (Not So?) Loosely Joined (and already spammed)" was originally cracked open and scrambled from a rotten egg at CogDogBlog (http://cogdogblog.com/2004/07/small-pieces/) on July 15, 2004.

There are interesting threads to read on peeling the layers of RecentChanges in wikis.

While reflecting on the Small Technologies Loosely Joined NMC 2004 session we did last month ion Vancouver, I noticed that someone had taken the effort to paste a bunch of porn URLs on the front page, and shortly there after, someone else thankfully removed them (was that you, Brian? You are supposed to be on vacation!).

The wiki software records each edit, and its changes from the version before, which allows the community self policing that ought to occur in this environment. And a story to reveal in following the revisions.

So the kind soul that posted crap from host84-205.pool80205.interbusiness.it (Cane Difettoso! your ISP has been notified) at July 2, 2004 9:09 am, there was someone watching over your spam shoulder in under an hour at July 2, 2004 9:51 am.

This is part of the tea leaves one can read from following the “diff” links on the RecentChanges for a wiki site- “diff” means show the difference between one revision and the previous ones.

To paraphrase Lt Kilgore from Apocalypse Now:

Ahh, there is nothing like the smell of napalmed spam in the morning….

The post "Small Pieces Loosely Spammed (wiki grafiitti?)" was originally rescued from the bottom of a stangant pond at CogDogBlog (http://cogdogblog.com/2004/07/small-pieces/) on July 3, 2004.

3 Comments