Writing a CMS is Hard: Why You've Never Heard of MagicFunnel

Contributor: Brian C. Ladd
School Affiliation: SUNYPotsdam Department of Computer Science
Email: laddbc@potsdam.edu

Web-based classroom management systems (CMS) have come a long way over the last decade. Forms-based file managers have given way to full-fledged content management systems. As part of the content management, modern classroom management systems provide some form of version control. Easy access to all versions of a composition (or computer program) makes the iterative nature of writing and rewriting clear to the student. It also supports greater experimentation: if an experimental change fails,the original work is only the click of a button away. My work on writing my own classroom management system leads me to appreciate the power in the modern systems. It also sharpens my attention to the need for the ability to move information into and out of a CMS, a feature lacking in some proprietary products. In 1996, when I began teaching introductory computer programming at a small, private, liberal arts college, I placed all teaching materials on the Web. Almost all students lived on campus in rooms wired with Internet connections. Having syllabus, schedule, assignments, sample code, course notes, and solutions on the Web meant they could always find them. Everything on-line also meant that the entire class was as close as the nearest of the 800 public computers on campus.

Students could retrieve assignments or notes without returning to their rooms for their Computer Science folder. The only piece missing was a way for students to submit their work through the Web. E-mail attachments were almost sufficient, but it presented an unnecessary context switch. When students felt they had finished a programming assignment, they had to leave the course Web page, open their mail client, find the instructor's e-mail address, compose a message that told the instructor what the attached file was, find and attach the file, and then send the message. The friction in changing medium from the Web to e-mail was small but noticeable. I developed the MagicFunnel application to provide students with a simple upload form directly within the assignment. This made "handing in" the program easier. The application provided students with access to their own Web space so students could not share. It also supported a simple form of version control, appending a version number to files with the same name. With nothing to compare it to, students and I were excited by this lashed-up configuration. With a wired campus, students had continuous access to assignments, notes, and the schedule. Submitting the assignment was now part of the assignment page; all they had to do was type the file name into the submission form and the program or paper was turned in.

Students also had access to any dated version of their own work at any time; this often let them recover from disasters (deleting files, dead-end experiments) on their own at any time. I was sure a Web-based, shared file system was just what was needed. I expanded the use of MagicFunnel to all introductory and upper-level courses during the next four years. In my own work, I was using version control systems such as Concurrent Version System (CVS) and the commercial Perforce system. These version control systems have many features not found in MagicFunnel: the ability to display changes between any two versions, easy branching and merging of versions (so that an experiment can be quarantined until it proves its worth), and support for collaborative work. "Real" version control systems also made much better use of server resources. I had included none of these features in MagicFunnel so I began thinking of rewriting it. In 1999, I became enamored with on-line threaded discussion boards (such as Slashcode) and looked into using one in the classroom. I used a simple one in my Web programming course that year. For the first time the students had 24x7 access to all my course materials as well as asynchronous access to the comments, questions, and answers that all of the students had generated in the discussion threads. This was the first such system most of the students had seen.

I introduced the software and required each student to post one thread and to respond to two threads every week. Many threads were simple syntax questions, answered in a single post, so students easily kept up the required volume of posts. Using the discussion board to tap into the collective intelligence of the class was a success, but this first try did not accomplish much in terms of generating deeper or more creative conversations. In 2000, Blackboard came to our university. I was comfortable with my own Web-based tools in introductory courses, so I took a go-slow approach, deciding to introduce Blackboard only in my upper-level courses. Comfort was not the only reason I went slowly with Blackboard. At the time the system was adopted, the company was not clear on how a course in the system could be archived and displayed outside the system. This went for assignments, discussion groups, and, most disturbingly, course notes. Single vendor lock-in fed my anxiety about Blackboard. Still, by the Fall 2001 semester, I was ready. I turned on the discussion groups, on-line quizzes, grade reporting, and file submission packages in Blackboard.

The discussion group rules remained the same: every week, each student needed to post one thread and two responses. The results were not what I had hoped. Responses were always posted right at the deadline, typically short and shallow, and the discussions were anemic. The subject of the course was operating systems,so there should have been much to discuss, both in terms of the technical and the more social aspects (what was happening between Windows 2000 and the Macintosh operating system? What was Linux?). Yet,even when I seeded the board with questions, the discussions remained forced. Blackboard's on-line quizzes proved to be excellent. I administered reading quizzes the night before class meetings. I read the quizzes before class to see what parts of the reading had given the students trouble. I then adjusted my lecture accordingly, typically adding one or two slides to the notes. The lack of student engagement and my dissatisfaction with Blackboard may be traced to the friction in a context switch. I kept my schedule, syllabus, and notes on another Web server and not in Blackboard.

Thus Blackboard appeared to be some sort of "add-on" to the class Website. Though there were links back and forth, the different structure of the two types of Web pages kept them forever separate. I stopped using Blackboard and then took a year off from teaching to program video games. Professional software developers use version control systems to support collaborative development as well as for all the reasons cited above. My experience brought me back to the thing I had found so necessary in MagicFunnel: version control. When I returned to the classroom, I replaced all of my submission systems with a Web-based Subversion(SVN) server. Subversion is a powerful version control system designed as the successor for CVS. It easily handles projects with large numbers of source files and collaborative development by multiple users. By maintaining multiple versions, I could make comments directly into the text of papers or programs. Students continued development on their documents and then merged my comments into their updated work; they could see if they had already addressed one or more of my comments.

This great power proved too much for introductory courses; introductory students now e-mailed me their projects. Upper-level students either loved or hated the system. Most thought it was too much work until they made a mistake and clobbered one of their text files. When they could recover the most recent version (or, if they thought a previous version was better, any previous version) with a click of the mouse, they typically began to love it. The ease of displaying differences between versions let them trace the evolution of their work. This is similar to Wiki or current classroom management systems. Version control systems are more focused on storing content for authors than in supporting group authoring; SVN stores copies of files that a user can check out, change, and then check back in, while a Wiki provides editing functions to the content on the current page, permitting rollback to previous versions from the editor.

With the power of version control in mind, I have spent a semester investigating existing open source content management systems to provide discussion support for a distributed course. I tested both Drupal and Moodle, electing to try Moodle because of the many powerful assignment types available. Moodle provides wiki and discussion group functionality along with news, RSS feeds, and multiple content views. It will run in parallel with a Subversion server to support collaborative teams that will span two campuses. Students will meet in class for 4 hours a week but will have to develop video games in distributed teams. There will be another context switch, from SVN for the software they write and Moodle for class assignments and documentation. This is not a problem in real software shops; I believe upper-level students used to using social networking and forums can overcome the slight friction. Content management systems provide version control similar to that of a full version control system. They also provide a simple-to-use Web-based collaborative authoring system; the system supports a variety of instructor-to-student, student-to-student, and student-to-instructor communication patterns. Coupled with a version control system to support file and project level versioning, Moodle looks like it will provide one more trip around a virtuous circle, improving student engagement and outcomes.