What is CLAMP?
The Collaborative Liberal Arts Moodle Project (CLAMP) is an effort by several schools to support continued and sustainable collaborations on Moodle development at liberal arts institutions. Moodle is an open-source learning management system designed with social constructivist pedagogy as part of its core values. With highly-customizable course pages, faculty can organize course material by week or by topic and add modules, resources and activities that help students meet learning objectives by encouraging collaboration and interaction. While the lack of licensing fees initially attracts many campuses, the flexibility of working with an open source tool also becomes a real advantage, allowing for additional customization to meet the specific needs of the institution.

Moodle is well-supported through its core developers and the large community at moodle.org, but CLAMP has a different focus: the issues and challenges unique to four-year liberal arts colleges using Moodle. By creating a smaller network of Moodle users with a tighter focus on the liberal arts, we are able to undertake development projects which none of us could accomplish alone. CLAMP develops community best practices for supporting Moodle, establishes effective group processes for documentation and fixing bugs, and better connects our institutions to the thriving Moodle community worldwide. Put briefly, by partnering programmers and instructional technologists across multiple institutions, CLAMP lowers the practical barriers to supporting and adapting this open source software.

To better understand CLAMP, it is helpful to look at the lexical components of the acronym:

• Collaborative: True participatory collaboration between member institutions is the motor of the project through a consensus process. Artifacts collaboratively produced from online and in-person gatherings are significant, benefiting all liberal arts Moodle institutions.
• Liberal Arts: While the liberal arts educational model is almost exclusively represented by institutions in the United States, we believe that the core values of this model–“critical thinking, broad academic interests, and creative, interdisciplinary knowledge” are embraced by many educational institutions worldwide.¹ They are also critical for the Moodle community. Indeed, a cursory dig into the support forums of the moodle.org developers, users, and managers mother site exposes rich seams of liberal arts values in the strata of developers, users, and managers. Here you find core characteristics of a liberal arts education reflected in both the outcomes and the artifacts of CLAMP activities (such as the Moodle Liberal Arts Edition, bug fixes, documentation) and the process by which they are produced.
• Moodle: As the premier open source learning management system, Moodle is a model of the open source sharing, cooperative and empowering collaborative ethic. And for CLAMP, the relationship with the larger Moodle community is symbiotic and synergistic–all bug fixes are reported back to the Moodle tracker for inclusion into the core, the Moodle Liberal Arts Edition is made freely available, and CLAMP members take an active role in voting on issues raised in the development community.
• Project: While the National Institute for Technology in Liberal Education (NITLE) has nurtured CLAMP for the past year through the NITLE’s Instructional Innovation Fund, the universal approach of CLAMP broadens its appeal to campuses beyond NITLE and even beyond the confines of North America. It is important to note, however, that our focus is exclusively on liberal arts educative goals. While we certainly recognize K-12 concerns, research university needs and distance education imperatives, these are not addressed through this project.

The technical culmination of these efforts over the last year is the Moodle Liberal Arts Edition distribution. It includes all third party modules and add-ons commonly used by our institutions; bug-fixes of critical importance to our schools; functions that simplify the user’s experience; and backend tools to give Moodle administrators better information about how their systems are being used. Although all CLAMP bug-fixes are contributed back to the Moodle core project, this distribution gathers the collective work and wisdom of the institutional network, simplifying the job of finding and installing each vetted patch or module.

Origins of the Project
CLAMP traces its origins back to 2006, when a small group of  representatives from liberal arts institutions gathered at Reed College to discuss the potential of a collaboration focused on improving Moodle. The following year, as Moodle was being adopted by a growing number of institutions across the country and the world, this circle of schools was expanded and the NITLE showed interest in providing support. An active support network developed as NITLE arranged two Moodle user community meetings and provided infrastructure for the online NITLE Moodle Exchange. Leading members of the NITLE Moodle Exchange organized two collaborative programming and documentation events called “Hack-Doc Fests” to bring programmers and educational technologists from twelve different institutions together in one place. Six of the schools–Earlham College, Lafayette College, Luther College, Kenyon College, Macalaster College, Reed College and Smith College–received a $43,000 award from NITLE’s Instructional Innovation Fund to continue and formalize their efforts.

Collaborative Projects
Since its inception, CLAMP has initiated three major projects: a Web-based workspace, a usability testing initiative, and the collaborative Hack/Doc Fests described in greater detail below. The Web-based workspace was essential to all three projects; we needed a private place to discuss, document and track our projects, as well as a front-end tool for sharing our completed efforts with the world. The end result was CLAMP-IT.org, which uses Redmine (an open source, Web-based collaboration suite) to provide project committees with online discussion forums, project trackers, and wikis, and WordPress (an open source, light-weight content management system) for public content.

To guide our development efforts, we designed a usability testing initiative to identify problem areas in Moodle. This involved asking faculty and students to complete tasks they were likely to encounter in Moodle, such as uploading files and grading assignments, and for students, responding to forum posts and editing personal profiles. After identifying the tasks, we purchased screen capture software for Windows (Camtasia Studio) and Mac (Screenflow), and conducted ten tests at five colleges. The results of these tests helped guide our development efforts.

The Hack/Doc Fest is a unique effort that brings coders and instructional technologists together to fix bugs, develop new functionality, and document features in Moodle. The name comes from “hacking” (a slang term that refers to digging into code to find and fix problems) and “documentation” (referring to the instructional technologist side of the event). But this is not a conference or a workshop. Instead, it is a chance for Moodle enthusiasts to focus on getting work done. Prior to the events we poll our community for features they would like added or documented. When we arrive on site, we spend an hour or so triaging these requests, factor in our own ongoing projects, and then launch into three days of coding and writing. The event has become the cornerstone of our collaborative efforts, as it gives us dedicated time to focus on improving the software and adding functionality essential to our campuses.

Photo: Courtney Bentley (Lafayette) works on a documentation project at Hack/Doc Fest at Smith College while Charles Fulton (Kalamazzo), Jason Alley (Lafayette), Dan Wheeler (Colgate) and Cort Haldman (Furman, back row) discuss a coding project.

Not surprisingly, the Hack/Doc Fest played a pivotal role in both the CLAMP-IT.org and usability efforts. Our initial experiments with Redmine began at Hack/Doc Fest at Reed College in January 2009 and the first drafts of our usability test scripts were written there as well. As the Spring 2009 semester progressed, we increasingly relied on Redmine to coordinate our efforts. By our second Hack/Doc Fest at Smith College in June 2009, we were able to use the software to track all of our bugs, features, and documentation requests. By the end of the event we had created or upgraded a host of new tools including the following:

• Census report: a tool for auditing active courses in Moodle
• Simple file upload: a script allowing faculty to quickly upload files to Moodle, bypassing the normally cumbersome upload script
• Current course block: a content block that allows Moodle to display courses from the current and upcoming terms
• TinyMCE integration: a new WYSIWYG editor that replaces the outdated, buggy editor that ships with Moodle
• Random course generator: a program that randomly creates hundreds of courses and assignments in Moodle, allowing developers to quickly test a medium-scale LMS installation
• Code repository: established this version control repository based on the open source Subversion software that allows our developers to easily make and track code changes

On the instructional technologist side, new documentation was created explaining how to use Moodle 1.9.5’s newly-revised gradebook, which introduced a number of new features and usability enhancements. Based on feedback from the larger CLAMP community, the instructional technologists also crafted documentation for Moodle’s “groups” and “roles” functions. (Groups and roles are powerful concepts in Moodle and allow administrators and faculty to customize the LMS to their needs, but they can also be a challenge to implement. The documentation addresses that.)

As our online and off-line efforts progressed, it became clear that we needed some mechanism for collecting and distributing our work. This realization led to the creation of our liberal arts edition of Moodle, which pulls together our finished code into one easy-to-install package available for download from CLAMP-IT.org. Our Subversion repository and documentation, crafted to be generic enough to be used at any college, is available through the Web site as well.

Participation and Funding 
Two years ago programmers and instructional technologists  from a half-dozen colleges saw a need–and an opportunity–to fix bugs and brainstorm solutions that were unique to using Moodle in a liberal arts environment. It was an ad hoc meeting, with each college paying its own way and the agenda created on a day-to-day basis. Flash forward to the present day–we have had seventeen NITLE member institutions participate in CLAMP, including attending a Hack-Doc event, contributing to the discussion regarding prioritizing needs, performing usability testing, fixing bugs in Moodle or creating and sharing documentation of the gradebook, groups and other features. What started off as a singular event has quickly become something more and in the process we have needed to find a way to govern and fund ourselves effectively.

To that end, we established a steering committee consisting of representatives from seven member colleges. This group organizes Hack-Doc events, prioritizes major projects, and handles financial matters. We have also established a number of other committees, including ones dedicated to code development and documentation. On the funding side, we established a membership fee of $300. Based on an initial membership of fifteen colleges, this will provide us with sufficient funds to cover our basic operating expenses, such as clamp-it.org, the code repository and licensing fees.

Once registered with CLAMP, colleges receive access to the development server that hosts our Web site and groupware suite. In addition to typical development tools, the development server provides custom commands that automate all of the busywork involved in setting up a new instance of Moodle. If, as happens quite frequently, a developer needs to test something in a “clean” installation of Moodle, she can create one in seconds with one command and then delete it just as easily when she’s done. The combination of single sign-on and Moodle-oriented workflow tools alleviates some of the major pain points for system administrators and developers alike.

Logistical Lessons Learned
Any collaboration across institutions will have significant logistical hurdles to overcome. Since CLAMP has always desired to build a broad and active membership, we gave these areas particular attention from the start. Here we present some of our lessons learned, in the belief that CLAMP’s experiences, and even our hardships, can be useful information for other collaborative open source projects.

Misadventures in Web Conferencing 
Clearly we need to be able to talk to one another from our different campuses. For that, the CLAMP steering committee relies on bi-weekly Web conferences in order to manage the planning, oversight, and logistics. NITLE’s current Web conferencing software, Marratech, has provided CLAMP with a fairly stable platform from which to conduct these sessions. But Google’s recent acquisition of Marratech and decision to discontinue supporting it in the future compelled us to explore other options, including DimDim (http://www.dimdim.com), Twiddla (http://www.twiddla.com/) and Skype (http://www.skype.com). Unfortunately, we have yet to find a viable alternative to Marratech. DimDim uses a “few-to-many” presentation style that only allows for four speakers–not enough for our five- or six-person committee meeting. Twiddla has an excellent whiteboard, but poor audio quality. Skype is useful for small conference calls, but doesn’t scale well and lacks white board support. While Marratech would occasionally crash and had audio-issues, it worked best for our purposes. Fortunately, NITLE has recently begun rolling out Elluminate and we are hoping that this online conferencing tool will be the magic bullet we’ve been looking for.

Our misadventures illustrate another advantage to our collaboration: bringing together technically-savvy individuals ready and willing to try out new software. Not only were we willing to try new things, we weren’t afraid to fail while doing. We braved microphone malfunctions, software crashes, terrible audio and video quality and other setbacks that casual users might not have had the patience for. The lesson is twofold: if you have the people and the time, use them to try new things. And if you begin collaborating extensively on one project, you can’t help but start to do the same on others.

Finding Convenient Meeting Times
Colleges and universities are lucky to have set academic calendars that govern the ebb and flow of their work, but that doesn’t mean it is easy finding blocks of time to work with one another. Navigating our weekly schedules for video conferencing is challenging enough, but finding a three or four days of time when our member colleges can get together for our Hack/Doc Fest work sessions is far more difficult. Not only do we need to work around academic terms, but we have to anticipate Moodle’s release cycle and consider our own internal software release cycles. For example, meeting in August would not only put us in the middle of the start-of-term crush for most of our colleges, but any code and documentation we started developing then would likely not be ready in time for September. Coupled with the tendency of Moodle to release new editions in late spring and early summer, we decided an early June session was best.

Software bugs wait for no developer, and we knew that we would need to follow up our summer session with another meeting six months later. Finding a time during the academic year was difficult; we finally scheduled the follow-up in January 2009, and had good participation from the our member institutions while June saw a greatly increased participation from both new and returning institutions. The increased June participation is due in part to heavier marketing of the Hack-Doc Fest, our choice to schedule Hack/Doc immediately after NIS Moodle Camp, and a general influx of NITLE schools beginning to use Moodle. We have discovered that it is important not to underestimate the potential for scheduling conflicts. What may be four weeks of pristine January quiet for one college may be a frenzy of winter terms, off-campus programs and special events at another school.

Development Collaboration Platform 
It is impossible to collaborate without communication. And when those collaborators are spread out across the country and working on a dozen-odd projects simultaneously, it is essential that they have some way of keeping track of who is doing what. Finding the software tools to support this collaboration was an essential step for CLAMP.

We began by using the NITLE Moodle Exchange (NME)–a Moodle instance hosted by NITLE–to plan our Hack/Doc Fests and report bugs while turning to a Google Code Project to provide version control. We quickly outgrew both. While Moodle is useful for online conversations, its sub-par wiki  and lack of a bug tracking tool would have played havoc with our developers’ workflows. At the same time, our long-term plans involved deploying a public Web site of our own, outside of the NME. We considered using Moodle for this, as it supports a barebones home page news forum, but we felt it would be an awkward fit. Moodle is about enabling classroom conversations, not serving Web pages to an anonymous public.

Because of our two very different needs, we decided to use two different tools. WordPress, an open source, lightweight content management system, powers our public Web site. For our ongoing development needs we turned to Redmine, for its robust wiki and issue tracking tools, as well as integration with version control. Tight integration between Redmine’s components means that it easily and automatically builds hyperlinks between the bugs, wiki pages, files and other resources that it’s tracking. Finally were were able to bind Redmine and WordPress together using a single signon solution called CoSign. This was critical, as it prevented a proliferation of one-off usernames and passwords and insured that people could spend their time working, not trying to remember their login information.

The system wasn’t perfect. Redmine has a learning curve, and it took a concerted effort by our developers and instructional technologists to learn the system. Even once we had mastered Redmine’s feature set, we had to spend considerable time organizing it and figuring out what workflows would be best for code, documentation, and event planning. In the end, it worked well. We used it extensively at our fourth Hack/Doc Fest at Smith College to track our progress. That in turn meant it was easy to pick up where we left off when we returned to our home campuses and concentrated on finishing the work we had started at Smith. The key wasn’t the software though–it was identifying what we needed to make our online collaboration work, and then finding the tools that fit those needs.

Usability testing
It is easy to complain about the shortcomings of an application’s user interface, but harder to quantify those shortcomings. One of CLAMP’s premier objectives in 2008-2009 was to conduct usability tests with faculty and students at our member campuses. The goal of these tests was to identify problem areas in Moodle to be fixed at one of our Hack/Doc Fest sessions. Before we could conduct the tests though, we had to establish a protocol: What questions would be used? How would the tests be administered? What software would we use to capture the results?

Developing the scripts was relatively straightforward; we drew from our own previous experiences and insights from Steve Krug’s Don’t Make Me Think, Louis Rosenfeld and Peter Morville’s Information Architecture for the World Wide Web.² Establishing the testing protocol was more difficult. After a few test runs, we determined that having two facilitators–one taking notes, the other one conducting the test–worked best, but as with video conferencing, finding the right software was a time-consuming ordeal.

While open source worked well for our Web ventures, after quite a bit of research and testing, we concluded that open source options for screencasting software were unreliable and limited in functionality. Ultimately we chose Screenflow for the Mac platform and Camtasia Studio for the PC, for their ease of use and their ability to cleanly capture the screen action with a video inset of the user from the computer’s Webcam. After several tests the formula for software setup was finalized allowing a smooth use of either package.

A best practice in usability testing is to not assist users when they have trouble but to objectively document their problem-solving process. As the usability tests unfolded, we found this approach was difficult to implement on our campuses. The instinct to help people solve a problem is strong, particularly among instructional technologists, and all of us had to balance the need to gather usability information against faculty or student frustration with the test. This tension led to very different approaches to conducting the tests that only became apparent afterward. While we were still able to gather useful data from the tests, this is an area we will need to discuss before the next round of testing.

As for the tests themselves, they revealed what might have been obvious–that the instructor’s task to use Moodle is more complicated and therefore, more difficult to master than the student’s task. Particularly troublesome areas included the gradebook, the file upload interface, and the collaborative editing of documents within Moodle.

We are still analyzing the student results, which points to another major issue with usability testing that we hadn’t anticipated: the time it would take to analyze data. We conducted a total of ten tests at five colleges, with each test generating twenty to sixty minutes worth of video footage. While our facilitators did take notes on each presentation, none of those notes were time-indexed. This in turn made it difficult for anyone other than the facilitator to go back and look for a specific problem mentioned in the notes, and sitting down to watch all of the video would take days. We also ran into issues with the quality of the video results; while most turned out fine, some experienced technical issues that caused the audio to be lost. Going forward we plan to review our usability tasks, create a more detailed testing protocol, and come up with a system for time-indexing the videos on the fly.

Conclusion 
The goal of the Instructional Innovation Fund grant from NITLE was to turn a loosely-knit group of higher education institutions with a shared interest in Moodle into a coherent, sustainable association. We have accomplished that, creating not only an organizational framework for carrying our work forward, but a software framework as well. With the release of the Moodle Liberal Arts Edition, we have provided a mechanism for distributing our work back to the larger Moodle community as well as to our peer institutions. Along the way, we have discovered the limitations of videoconferencing, the value of open source, Web-based collaboration tools, and the inadequacies of open source video-capture software. We’ve also learned much about what works and what doesn’t when conducting usability tests.

Looking to the future, our next challenges are clear. Solidifying our software development protocols to streamline releases of future versions of the Moodle Liberal Arts is of critical importance. We have the tools, now we just need to master them. Similarly, with a large number of new schools joining our ranks, we’ll need to ensure that our participation model holds up, and that the new recruits feel every bit as involved as the old ones. As part of that, we will also need to review our approach to Hack/Doc Fests to ensure they remain well attended and productive even as many of our institutions face declines in funding. Pursuing more regional Hack/Doc Fests is one option. Looking for additional grant opportunities is another.

We are optimistic that we will be able to achieve these goals. CLAMP’s established a two-year track record of working together, both online and off. While the financial landscape has changed, our commitment to working together to improve Moodle for our respective campuses has not.

Notes
1. Michelle Glaros, “The Dangers of Just-In-Time Education,” Academic Commons (6/10/2005), http://www.academiccommons.org/commons/essay/jit-education . [return to text]
2. Steve Krug, Don’t Make Me Think! A Common Sense Approach to Web Usability, 2^nd ed. (Berkeley: New Riders Pub, 2006); Louis Rosenfeld and Peter Morville, Information Architecture for the World Wide Web, 3^rd ed. (Sebastopol, CA: O’Reilly, 2007). [return to text]