Course Web Management at Albion College

Presented by
Asst. Instructional Technologist, Robin Miller

• In the beginning – Five years ago the IT department at Albion managed the web presence on our campus. All websites were on a single server “WWW”, and our role included technical and server support, design, and training. Course content was maintained in departmental web pages that linked off the main site. Departmental secretaries or faculty managed the few individual course sites we had.

• A change in management – Two years later the Communications Department took over management of the college’s web presence to promote a consistent appearance of the website for marketing purposes. In efforts to continue to provide faculty a web space for course-related content, Instructional Technology implemented a separate server. Web sites on the “courses” server were not restricted by college branding and allowed more freedom of design for those faculty designing course webs. A separate Instructional Technology owned server also provided us with the ability to experiment with models to address the increasing interest in course webs.

• FrontPage Course webs – With a history of developing home-grown solutions, and being unwilling to invest in a course management product, the initial model chosen to develop course webs was FrontPage. The campus had just signed a Microsoft Campus Agreement that provided every Faculty, Staff, and student with FrontPage for both office and home use. In this model, Faculty used FrontPage to create their own course web sites on the new server. Faculty that were new to web design could use preset course web templates to assist them in getting their sites online.

• Design, Marketing, Maintenance, and Support of FP Webs – An intern program was developed that supported the Course Web project. Intern responsibilities included:

  • Managing the migration of course web content off the www server and on to the courses server

  • Development of a management system, which included archiving and creating documentation

  • Design of course web templates

  • Faculty outreach and technical support

• FrontPage Challenges/Faculty Buy In – Faculty participation increased but many faculty still resisted the idea of course webs due to their concern about learning FrontPage. After one year, additional FrontPage templates were developed, making it easier for faculty to add their own content but Instructional Technology staff continued to do a lot of the initial website setup and technical support.
  
  

• A RE-Evaluation – Despite these obstacles, student demand for course webs was still increasing and playing out in our campus User Survey each year. Moreover, due to budget reductions, funding for the intern position was withdrawn. Therefore, we began to review other sources of course web management systems that would require less user intervention on our part and increased functionality for the user.
  
  

• Course Management Product Options – Seeing a plateau in faculty participation we realized we needed to make it even easier to enter course content on the web. We re-evaluated Blackboard and Web CT; however, both systems were too expensive and too complex for our needs at that time.
  
  

• Open Source Products – An evaluation of open source products lead us to highlight two products as appropriate for implementation on our Windows 2000 Courses server. In the spring of 2004 we did a side by side pilot of CHEF, developed by University of Michigan, and MOODLE, developed by Martin Dougiamas. We chose a handful of faculty we knew would use the systems and give us meaningful feed back.
  
  

• A Pilot – At the end of our pilot, the positive feed back and acceptance of MOODLE was overwhelming! In the course of the pilot, faculty spread the word about the ease of its use and we had a growing number of Moodle coursewebs before the program was even announced. While the faculty who piloted CHEF were generally pleased with its performance, CHEF was not as robust and there was no significant technical support or documentation.
  
  

• Decision to Adopt Moodle: The decision was made to officially announce MOODLE as our primary course web management system in the fall of 2004. This was because it has a strong developer and community support base and is much easier to implement and use. Instead of learning to create websites faculty only have to fill in web forms.
  

• MOODLE Implementation – There were a few notes of interest in Moodle implementation:

1. LINKING TO EXISTING WEBS - Though we decided to move forward with MOODLE we did not want to alienate faculty who preferred to create their own course webs in FrontPage. However, to make course content easy to find for students, we create simple MOODLE sites that link to the FrontPage webs. This allows students to easily access all course webs from the course web home page which has been created using MOODLE.

2. AUTHENTICATION OF USERS - We authenticate against our GroupWise email, however, MOODLE does support several other authentication models. For example - stand alone, network, or external databases. We feel the advantage to using email is that it allows us to ensure everyone who logs in is an Albion user. Guest access is not allowed, we shut it off when we set up new sites mainly for copy right and course content protection.

3. ASSIGNING INSTRUCTORS - We discovered MOODLE had an upload user script which allowed us to upload faculty into the system from a text file created in Banner. This eliminated the need to set up a course, instruct the faculty member to login in and create a profile, then wait for them to tell us they had done this so we could then go in and give them privileges to edit their course web.

4. PRELOADING CLASS INFO - While it is possible to preload class information such as participants, classes, etc., we have found that because students can self subscribe to course webs, this has not been necessary.
   
   

• MOODLE Success – Since our implementation of the new course web management system participation by faculty has doubled. We believe this is due MOODLE’s ease of use and active promoting by our library and Associate Dean of Faculty. In addition, Faculty word of mouth and student demand are also key factors in our success. We’ve found the program to be very solid and easy to upgrade. We are currently using version 1.4.4.
  
  

• Ongoing Challenges – Ongoing challenges for us have been:

  • Helping users to understand how to manage upload of files (which means understanding limits to file size and using correct path)

  • Helping faculty to think about what and how to present in a course web AND

  • Helping faculty to understand all the tool features available in MOODLE.

  • Also, although MOODLE has a very good individual archive process (it creates zip files in a folder on the server that contain entire course contents), we are still working on an efficient means for global archive and storage for future re-use.

In the end, we feel these challenges are minimal in comparison to the advantages of using MOODLE as a course web management system.

• More on MOODLE - We look to support the continued development of Moodle by inviting outside groups to attend our training sessions and by responding to MOODLE inquiries and participating in MOODLE discussion forums. For more information on MOODLE visit moodle.org. This site contains a wealth of information as well as discussion forums.

Technical Information:

MOODLE runs on our courses server, which is Windows 2000/IIS 5.0.

MySQL database server runs on the same computer as the courses web server and serves not only MOODLE, but also other open source and development projects. At the present time we have not experienced any performance problems with this implementation, but as demand increases for both MOODLE sites and other MySQL based projects, the plan is to move the MySQL server to its own hardware.

For our implementation, we have given a generous upload file size limit of 32mb because storage space is not currently as issue. As demand increases, we will re-evaluate and likely reduce file sizes.