Course Management Systems

Janusz Buda


Recent developments in computer network technology have provided teachers with powerful tools to facilitate education inside and outside the classroom. Course Management Systems (CMS) provide a web-based infrastructure for digitized information sharing among teachers and students. A trial implementation of the Moodle open-source CMS in support of English language courses at three Japanese universities is described and analyzed, and the advantages and disadvantages of CMSs as an aid to foreign language teaching are discussed. It is concluded that CMSs provide a highly effective tool for foreign language teaching, but require a significant investment of time and money.



The use of tools to facilitate teaching is not new. For centuries educators have used blackboards, slates, charts, flash cards, books, and other teaching aids. The advent of electricity brought new tools such as slide projectors, phonographs, mimeographs, and movie projectors. In more recent times, tape recording technology has enabled presentation of audio and video content and photocopiers have facilitated bulk copying of printed text.

In the 1980s, educators were quick to adopt use of the nascent Internet. Electronic mail provided a speedy and convenient way to link teachers and students via mailing lists, and File Transfer Protocol (FTP) permitted rapid exchange of data documents.

In the 1990s the growth of the Worldwide Web (WWW) furnished teachers and students with an even more efficient way to broadcast announcements and course materials. Web-based bulletin boards facilitated teacher-student interaction.

Course Management Systems (CMS) are software packages that bring together numerous Internet tools and allow them to be accessed via a simple and convenient user interface. Such systems are also referred to as Virtual Learning Environments (VLE) or Learning Management Systems (LMS).

CMS Definition

A typical CMS will provide such tools as: user registration and authentication, creation of static web pages, file exchange, tests and surveys, student grading, journals, wikis, photo galleries, chat rooms.

In the context of a CMS, these tools are commonly referred to as ‘modules’ and a well-designed CMS will integrate several modules behind a seamless user interface.

An advanced CMS can provide most of the elements necessary for distance learning. More commonly, it can be used to support traditional classroom courses.

In either case, a CMS requires a relatively sophisticated environment to run efficiently. It needs, for example, to be installed on a web server with access to a relational database. Such an installation demands hardware, software, and technical resources, which in turn necessitate a significant financial outlay.

For this reason, most CMS installations are on an institutional level, in schools, colleges, and universities. Where an institution already maintains a computer network infrastructure with trained technical support staff, the major expense will be the licensing of the CMS software. With commercial packages such as Blackboard or WebCT this recurring expense can be significant.

Many educational institutions, unfortunately, have neither the infrastructure nor the budget to install and maintain a CMS. In the absence of a computer network infrastructure, one alternative is web hosting, in which the CMS developer or a commercial ISP will install and maintain the CMS for a charge. However, where budgetary constraints are the main factor precluding the installation of a CMS, there exist free open source CMS packages such as Moodle and Claroline, and the onus of installation and maintenance will typically fall on individual teachers.

The present study describes one such individual implementation of the Moodle CMS in support of English-language courses at three Japanese universities.



Moodle is a free, open-source CMS created by the Australian developer Martin Dougiamas. Since its initial release in 2001 it has passed through several iterations and has attracted increasing attention from educators and programmers worldwide. As of January 2006, over 8,500 Moodle installations in 140 countries have been registered with the developer’s website. This number probably represents only a fraction of total installations.

Moodle can be downloaded from the developer’s website and installed on any web server that supports the PHP scripting language and has access to a relational database such as MySQL or PostgreSQL.

Stage One

In 2003 the author installed an early version (1.1) of Moodle on a personal server and used it in support of several English language classes.

The server was one of three belonging to an Internet sub-domain provided by Waseda University. These servers were already in use for research and course support and no modification of the existing setup was required:

It should be noted that all of these computers were originally purchased for conventional desktop use requiring only modest technical specifications. After one or two years of regular use in an office environment they were added to the bank of sub-domain servers, replacing older computers.

Although no changes to the hardware specifications of these computers were required, operating system and other software updates were carried out periodically.

The initial 2003 trial of the Moodle CMS had limited non-critical objectives, the primary being to see if students would adapt to the new technology and, if they did, whether this would bring any tangible benefits to the courses.

Registering with the Moodle system — a simple online process that takes only a few minutes — was not mandatory and alternatives were provided for all CMS activities. For example, students had the option of submitting assignments as email attachments, or receiving announcements via a mailing list.

Most students, however, did register with the Moodle system and few difficulties were experienced in this first implementation. The system itself proved sufficiently robust and course feedback indicated that students found it easy and enjoyable to use. The Grading module, which allowed students to check their assignment grades, was particularly well received. The most common complaint was relatively slow response time when navigating through the pages of the CMS. A number of factors could have contributed to this slowness, including network congestion and lack of advanced data caching.

Stage Two

The 2003 trial proved successful and in 2004 intensive use of an updated version (1.3) of the Moodle CMS was extended to a total of nine courses taught by the author at three Japanese universities, at both undergraduate and graduate levels. Most of the students were Japanese, with a small number from China, Korea, Taiwan, and other countries.

During the orientation session for each course, students were issued with individual user IDs and passwords giving access to the Moodle CMS, and group course keys allowing registration for specific courses. A detailed step-by-step explanation of the CMS registration procedure was given and a registration deadline announced. The orientation assumed that the students already possessed basic computer literacy skills and familiarity with a web browser.

Most students registered successfully within a day or two. Difficulties with registration such as mislaid IDs or passwords were dealt with on an individual basis, either by email or during class time.

Intensive use of the Moodle CMS was made from the second week of each course, the nature of this use varying according to course content.

Spoken English courses focused on use of the CMS Journal module to expedite submission of preparatory assignments for correction and grading.

In written English courses the CMS was used to provide students with document templates and vocabulary lists for downloading, and to allow students to upload completed assignments.

In comprehensive multi-skill courses a combination of modules was used to facilitate collaborative drafting of, for example, project proposals and advertising copy, or exchange of research data.

All courses, irrespective of content, made use of such CMS functions as grading, in which students could access details of their own assignment grades, low-stake vocabulary quizzes, forums, and chat rooms.

At the end of each course students were warned that access to the CMS would be discontinued approximately one month after the last class, and encouraged to reference or save grades and other data before then.

Closing of each CMS course was accomplished in three steps. The first was the expiration of user IDs and passwords, the second was archiving of all course data, the third was deletion of that data from the web server.

All past course data was preserved in database form for future reference.


The distributed version of Moodle contains several basic modules. Members of the Moodle community are constantly developing new modules that can be added to an existing Moodle system. These optional third-party modules will go through a standard cycle of development in which problems and bugs are identified and resolved. Some of the more successful and popular modules may then be added to the basic Moodle distribution. The version of Moodle used in Stage Two of the study, for example, contained two or three more modules than the version used in Stage One. In this section, details will be given of the implementation of the modules used in both stages of the study, along with brief comments on the results obtained. General comments about Moodle and other CMS will be reserved for the following section.

The present study made use of the following Moodle modules: Authentication, Assignment, Resource, Forum, Chat, Quiz, Journal, and Wiki.


A new installation of Moodle or any CMS contains no information about the students or instructors who are entitled to access the system. Names are added through the process of registration, in which each user is assigned a name or number (a ‘username’) and a password. This username and password are then used to identify members whenever they log in to the system, a process known as authentication.

Moodle offers several authentication options. The choice will depend on the level of security required, which in turn will depend on the content of the CMS. If the system is used only for general announcements and discussions, the level of security can be relatively low and the method of authentication simple. Conversely, if the system is used for submission of assignments or contains private information such as student grades, a more sophisticated method of authentication with a higher security level is a necessity.

The three most common authentication options are user authentication, email authentication, and database authentication.

The first option, user authentication, is the simplest and most insecure. New members are allowed to create their own accounts and choose usernames and passwords without any check being performed.

With email authentication, new members can create their own accounts but these accounts are not activated until a member responds to a message sent to the email address he or she registered with the system. Once an account is activated the username and password associated with that account are stored locally within the Moodle system.

The third and most secure option is database authentication, in which username and password information is kept in a separate database, to which the member has no direct access.

In the present implementation of Moodle, the database authentication option was chosen. Student ID numbers were used as usernames, and unique passwords were created using a password-generating software application. Both usernames and passwords were then uploaded to a MySQL database.

During the orientation session for each course, each student entitled to access the Moodle system was given a slip of paper with a print-out of his or her username and password. Students were informed that if they found the assigned password difficult to remember or otherwise inconvenient, they could apply for a replacement of their choice. Only a few students made use of this option.

Using the assigned username and password, each student could then access the Moodle system. Upon the first access the student would be asked to fill in a short profile form containing several required items such as geographical location and email address, and several optional items such as postal address, phone number, and website. Completion of this profile form would then give the student access to the top level of system, where he or she would be able to see general announcements and a list of the courses available.

Access to one or more of the available courses required additional authentication in the form of a course key common to all students enrolled in that course. This course key consisted of a simple word or phrase and was announced during the orientation session.

Having completed this two-stage registration process, students would then have access to their own course materials and limited access to information about other course participants.

The authentication procedure described above worked smoothly and no significant problems were encountered. A few students lost the slips of paper containing their usernames and passwords and were unable to register. Others registered successfully but then lost or forgot their login information. In both cases new login information was issued during class time or via email.

A slight difficulty was experienced with the use of course keys. In a standard course setup, the course key is required only once and gives access for the duration of the course. There is an option, however, to unregister students who have not accessed the course materials for a specific length of time. This option was activated and set at two weeks. Any student who attempted to access a course (as opposed to the Moodle system as a whole) after a hiatus of two or more weeks would be asked to supply the course key. This key was changed regularly, thus effectively locking students out.

This measure was taken for two reasons: to encourage students to access the Moodle system regularly, and to force them to contact the course instructor after a prolonged period of non-activity. Students re-applying for course keys could then be quizzed about the reasons for non-activity.

The number of students re-applying for course keys proved greater than expected. Many assumed they had made an error inputting the key and wasted time contacting other course participants, asking for the ‘correct’ key. When they eventually did contact the course instructor, the most common reason given for non-access was lack of time.


In its simplest form, the Assignment module presents students with details and instructions about an assignment, the deadline if any, and the maximum grade obtainable. After the assignment has been completed the instructor can allocate grades and comments that will be visible to individual students.

The Assignment module can also handle uploads of completed assignments, control the maximum size of the assignment file, allow or deny resubmissions, and automatically refuse all uploads after the posted deadline. Of particular interest to students, the module will also countdown to the deadline, showing how many days, hours, or minutes remain.

This particular module performed flawlessly and the only problem encountered was file naming, which was not a function of the module.

Many students seemed ignorant of the basic conventions of file naming. Some allowed the creator application (usually Microsoft Word) to generate its own file name. Many students assigned ambiguous file names such as myfile.doc or assignment.doc. A few used non-standard character encodings that resulted in illegible file names.

Repeated instructions and examples were given of preferred file-name formats, with a minimum requirement that students include their own name in a recognizable form. Some students, unfortunately, seemed unable to understand or implement these instructions.


The Resource module allows the course instructor to provide supplementary material for an assignment. The resource can be a downloadable file or a viewable text or web page.

Intensive use of this module was made in writing classes, typically to provide students with formatted templates for business correspondence assignments. Students would access the Moodle system, read the details of their next assignment, then download the template file. They would then use this template to compose, for example, a business letter. The completed file would then be uploaded to the Moodle system via the Assignment module.

In addition to the file-naming problem described above, a significant difficulty was experienced with uploads of downloaded resource files. Although most students were able to upload completed assignments smoothly and successfully, a few repeatedly uploaded blank files. The cause of this problem was traced to a basic misunderstanding of how a web browser handles document files as opposed to HTML files.

Students using Microsoft Internet Explorer would click on a Microsoft Word template resource which would then appear on their screens. They would fill out this template and, upon completion, would attempt to upload it to the Moodle system. What they were uploading, however, was a blank HTML file representing their web browser window.

What these students failed to realize was that they were viewing and manipulating the template file in Internet Explorer, not Word, and that no copy of the file had been downloaded to their computer.

After this problem had been identified, instructions were given to students to override the default behavior of Internet Explorer by right-clicking resource links, or by using alternative browsers that gave users a choice of displaying or downloading documents.

These instructions were repeated at regular intervals but, as with the file-naming problem, some students seemed unable to understand or implement them.


The Forum module is a basic implementation of the electronic bulletin board familiar to Internet users. Separate forums can be created for courses or assignments.

Student response to the forums was disappointing. At the beginning of the course students were made aware of both forums and chat rooms (discussed later), and encouraged to use both freely. No additional directives were given.

Perhaps as a consequence of this lack of guidance, a few students mistook or chose to ignore the purpose of the course forums and used them to post irrelevant and occasionally inappropriate announcements to other course participants. Other students used them to post apologies for late assignments or other personal messages to the course instructor. Very few attempted to initiate, or participate in, a discussion of the course materials.

In the absence of student feedback concerning the course forums, it can be surmised that one reason for this lack of enthusiasm was reticence about posting public messages in English. Although no specific guidance was given on language use within the forums, most students probably assumed that English would be most appropriate. Fear of making English mistakes which would then be seen by other course participants, and uncertainty about the content of forum discussions, no doubt discouraged many students from posting.

A similar tendency was observed with the Chat module.


Online chats having become a popular means of communication among students, it was hoped that the chat rooms provided by the Moodle system would facilitate student-student and student-instructor interaction.

As with the Forum module, little use was made of the either the course-specific chat rooms or the general chat room for all system users.

Reference to archived logs showed that most chat activity was in course-specific rooms between two, occasionally three, students. The language was invariably Japanese and the format was typical of the stylized high-context interaction characteristic of Internet chats. Content was restricted to greetings and fairly superficial conversational exchanges. Occasionally concern was expressed that the chat was being monitored. The same reluctance to participate in online chats was also evident in student-instructor exchanges. Attempts to initiate a simple English-language dialogue usually resulted in students fleeing the chat room.

One other possible reason for the lack of chat activity may have been the low number of potential participants. Although several hundred students were using the Moodle system as a whole, most courses had a registration of between twenty and fifty. The chances of encountering another course participant at any one time, and of engaging him or her in a chat, were consequently low.

On the other hand, the same lack of participation was evident in the course forums, which transcend time constraints and allow students to communicate without the need for simultaneous access.


The Quiz module enables the course instructor to create and maintain a collection of questions and then assemble them into online quizzes.

Several question formats are supported, including multiple choice, true/false, short answer, and embedded answer.

The order of both questions and multiple-choice answers can be randomized, question scores can be adjusted, and several levels of student feedback can be activated. For example, students can see a simple score upon completion, or they can additionally see which questions were answered correctly.

A testing period can be defined, during which the quiz must be taken. The quiz is automatically closed when the deadline passes. If so desired, students can be allowed to retake the quiz during the test period.

In the present study, the Quiz module was used for vocabulary testing. Students were given course-specific vocabulary lists and asked to revise them. Students should have been familiar with most of the vocabulary items, the chief purpose of the quiz being to identify lacunae in their knowledge of meanings and collocations.

Use was made of a combination of question formats, mainly multiple choice, short answer, and embedded answer. Only one attempt was allowed and feedback restricted to raw score.

No problems were experienced with this module. Perhaps as a result of prolonged experience of testing before entering university, students were clearly comfortable with the question formats used. There were no reports of aborted or incomplete tests.

The unadjusted raw scores did, however, generate a few queries from students. Most other assignments having been graded on a scale of 1–5, some students were disturbed to see scores of up to 30 returned by the Quiz module.


The Journal module was not used in Stage One of the study. Soon after the beginning of Stage Two, difficulties were experienced with the increased volume of assignment submissions and a limited trial was made of the module as a possible solution. It proved extremely effective and intensive use was extended to most courses.

In the lesson format adopted for spoken English classes, students were required to prepare and submit material for discussion or presentation. This material varied depending on the level of the course, but would typically consist of a number of starter questions and a few items of data for discussion. A topic having been assigned, students were expected to compose a short list of starter questions designed to lead the discussion in specific directions. Students were also expected to research interesting data that would provide a focus for comments.

This submitted material was checked, corrected by the instructor, then returned to the students before class.

In previous years this cycle of submission and return was carried out on paper or by email. When intensive use of the Moodle system was extended to multiple courses, however, the volume of email traffic proved unmanageable and it became impractical or impossible to follow up reports of lost or delayed messages. Hence the decision to try out the Journal module.

The Journal module displays two text-entry boxes: a large upper box for student input and a small lower box for teacher comments. It also provides a drop-down menu for teacher input of grades.

In the current implementation, students were asked to type or copy-and-paste their starter questions and data into the student input text box. The instructor could then read the students’ submissions and make comments and suggestions via the lower text box. If necessary, the instructor could also ask for clarification of vague or ambiguous expressions. Students would then amend their questions or data accordingly. There was no limit on the number of submit-amend-resubmit cycles allowed, the only constraint being the time available to student or instructor.

Final grading of submissions was done after the assignment deadline had passed.

As mentioned previously, the Journal module was very effective in facilitating a rapid one-on-one exchange of information between student and instructor. Had the submission and correction of student preparations been paper-based, perhaps only one exchange cycle could have been accommodated before each class, with no time for follow-up questions.

Although it was made clear to students that grading would be of the final version of each assignment, not the first, and that early submission would both help the instructor and ensure at least two exchange cycles (and hence a better grade), many students still chose to submit assignments only hours or minutes before the deadline. Within a few weeks of the beginning of a course, the timing of submissions would settle down into a pattern resembling that of a suspension bridge: two sharp peaks at beginning and end, with a slack period in between. Earnest students would rush to submit assignments as soon as possible; the less earnest would postpone submission to the very end.

Student feedback on the Journal module was similarly divided. Most students were grateful for prompt and personal correction of their assignments; a few tended to view the online submission process as an unwarranted intrusion on their out-of-class time.

The Journal module itself performed flawlessly, but problems were encountered with student input. Some students attempted to copy-and-paste formatted word processor files or complex HTML pages into the text boxes, creating an illegible mess that made correction impossible. Legibility problems were also encountered with standard keyboard input of starter questions and data. A small but significant number of students were unacquainted with basic keyboarding conventions such as the insertion of spaces after commas or periods. A few students were unaware of the difference between single-byte alphanumeric encoding and two-byte Japanese encoding.


A wiki is a website that allows collaborative and unrestricted editing of content and format. Perhaps the most famous example of a wiki is the Wikipedia project, in which thousands of contributors work together on the writing and editing of online encyclopedia articles. The Wiki module was used for only one course, with disappointing results.

The course was for advanced students of English and focused on simulations of business projects. It was hoped that the Wiki module would enable small teams of students to work together on drafting proposals, reports and advertising copy.

In contrast to forum and chat website models, with which students were well acquainted, the wiki website model was unfamiliar and students had difficulty understanding its purpose and use.

Although the simple formatting conventions used in wikis can be learned in only a few minutes, most students abandoned any attempt at formatting and resorted to embedding blocks of HTML or links to external documents. More significantly, the module log revealed that students were loathe to change text submitted by other students, preferring instead to enter revised or additional text sequentially, in imitation of the forum model.

A number of related reasons could account for this reluctance to make use of the Wiki module. Three nationalities (Japanese, Chinese, Taiwanese) were represented among the students taking this course and there may have been cultural constraints against giving offense to other students by correcting or deleting their work. A more detailed explanation of the way in which the Wiki module saves all changes for future reference may have encouraged more active contribution. Finally, the availability of alternative and more familiar methods of collaboration (the Forum module, for example) may have dissuaded students from investing the time to learn wiki formatting conventions.


Adoption of CMS

At the beginning of this paper it was noted that the installation and implementation of a CMS demands a significant investment of hardware, software, and human resources.

The success of the present study, in terms of educational benefits, came at a price. Even though free open-source software running on available hardware was used, the amount of time and effort needed to set up and maintain the system was prohibitive.

Had it not been for the availability of an Internet sub-domain, the possession of three functioning servers, and a working knowledge of computer networking, the author would almost certainly not have embarked on the present study, and would have had to wait until his faculty or university decided to install a CMS.

The decision to install a CMS might appear an easy one, but is not. A school or university considering an installation is often unsure how much it will cost and how much use will be made of it. Usually these two uncertainties are closely linked: licensing costs of software and maintenance costs of the infrastructure will vary according to how many teachers choose to utilize the CMS.

Consequently, most major institutional CMS installations are performed in stages, with comprehensive reviews at the end of each stage.

For example, a large university may choose to begin by licensing a small-scale CMS and delegating maintenance responsibility to existing IT personnel. A positive review of the first stage may result in an upgraded license covering more users, and the appointment of specialists to maintain the system. Further expansion may see the appointment of dedicated CMS managers and the customized integration of the CMS into the university’s IT infrastructure.

At Duke University in North Carolina, for example, the Blackboard CMS is integrated with the university’s registration database. Whenever a new course is created, space is automatically reserved for that course on the Blackboard system. As students register for that course, their names are added to the Blackboard system and authentication is carried out using the same usernames and passwords that give access to email, library catalogues, and other campus facilities. This integration takes place whether an instructor chooses to make use of the CMS or not. Should she or he choose to use the reserved space, the system is available immediately.

Proprietary or Open-Source

Blackboard is an example of a large-scale commercial CMS. Another difficult decision for educational administrators considering the installation of a CMS is whether to go with proprietary systems such as Blackboard, or free systems such as Moodle. As with the basic decision on whether or not to install a CMS, the decision on proprietary or open-source may seem simple, but is most decidedly not. Both solutions have relative advantages and disadvantages that depend on a number of variables.

Proponents of proprietary software maintain that the use of open-source software entails hidden costs that may equal or exceed the cost of proprietary equivalents. Open-source software, it is said, is less stable and goes through frequent and erratic update cycles that add to maintenance costs. Furthermore, the developers of proprietary software can be held accountable for inadequacies in their products, whereas the developers of open-source can not.

Proponents of open-source software respond that frequent update cycles are the result of active product development and that commercial developers are slow to update and improve their software. They also point out that most commercial software companies specifically reject all responsibility for damage or loss incurred by use of their products.

Of particular concern to CMS managers is customization. Commercial software developers will, for a price, customize their product to meet specific requirements. Open-source software can also be customized — perhaps more easily than proprietary software — but responsibility for this will usually fall on already over-burdened in-house IT personnel.

What proponents of both solutions will concede is that, in terms of function and capability, neither is decisively better than the other.

Transcending Time

Whether proprietary or open-source, a CMS facilitates an exchange of information that is both physically and temporally more efficient than traditional methods. Paper-based distribution of notes, reports, assignments, etc. is replaced by speedy and resource-friendly electronic distribution. Time constraints are removed.

In a conventional course setting the only time the instructor can be sure of meeting all of his or her students is in class, and it is in class that most of the information exchange takes place. If a class is scheduled for once a week, the exchange of information will similarly take place once a week. Having given the students an assignment, the instructor will usually wait until the next class to collect them. Graded assignments will usually be returned in the class after that, a week later. A student missing a class may be unable to submit or collect an assignment, and separate arrangements may have to be made.

With a CMS, distribution of information and resources can be accomplished at any time and need not be synchronized. A student can submit an assignment on a Tuesday evening and the instructor can retrieve it on Wednesday morning or at any other convenient time.

This time-independent exchange of information is itself dependent, however, on fast and reliable access to a computer network, which in most cases will be the Internet. This may not be a problem where a CMS is installed as part of a campus-wide network and most students reside on campus. In situations where students live off-campus, however, access can become a problem. Not all students can be expected to possess their own computers, or have broadband access to the Internet.

In the present study, no formal survey was made of student access patterns but informal interviews suggest that approximately 60% had some kind of off-campus Internet access. This includes students who accessed from parents’ homes over weekends, or from friends’ homes or lodgings when visiting. Most students, even those with their own off-campus Internet access, made intensive use of computer terminals located on campus.

Although some form of CMS access was assured for all students — many students using several — this does not necessarily mean that students could access at any time they liked. Student feedback revealed that the time-transcending advantage of a CMS was often limited by other factors.

Access Problems

Examples of access limitations were students rushing to university computer labs during lunch breaks or between classes and finding all terminals occupied; students able to access only when visiting relatives or friends; students with extremely tight part-time work schedules that left little time for Internet access after returning home.

In a few extreme cases, the flexibility of a CMS was perceived as an irrelevance at best, an annoyance at worst. Some students maintained that their tightly organized schedule of study left no time for either periodic or sporadic CMS access: to check, for example, whether the instructor had corrected or graded an assignment, or whether a course announcement had been made.

Demands on Teachers

The same kind of access constraints also apply to teachers, but busy teachers always have the option of choosing not to use a CMS in support of their courses.

Anecdotal evidence of large-scale CMS implementations in schools and universities indicates that teacher adoption is slow but steady. It takes time for teachers to become aware of the availability of a CMS and there is a natural reluctance to experiment with unfamiliar technology. Reports of successful adoption and examples of specific applications will encourage wider adoption.

Successful adoption can occasionally lead to over-enthusiasm and student complaints that CMS use leads to an unacceptable increase in workload, usually in the form of tighter and more frequent deadlines.

CMS adoption in support of a conventional course adds a number of variables of which the teacher needs to be aware. As CMS interaction will, by definition, take place outside the classroom, it can be difficult for course instructors to monitor the way students use the system and identify any problems that might occur.

The CMS itself incorporates many tools that facilitate student-teacher communication: forums, chat rooms and private messages. Regular email is always available as a fall-back.

The present study indicated, however, that many problems were not reported. Some were easily identified from a perusal of CMS message and file traffic or web server logs; others had to be inferred.

Computer Literacy

Perhaps the most salient variable highlighted by the present study was computer literacy. The study itself was undertaken on the assumption that students possessed a reasonable level of computer literacy, an assumption confirmed by the pilot Stage One implementation.

Whereas the Stage One implementation was restricted to four courses and student use of the CMS was optional, the Stage Two implementation was extended to twelve courses and student use was required.

Within this wider net were caught some students who evidently possessed zero computer skills and who experienced great difficulty coping with the CMS.

It should be recalled that the overwhelming majority of students in the present study were Japanese, with a small number of students from China, Korea, Taiwan, and five other countries.

Since 1990 the Japanese Ministry of Science and Education has directed primary and secondary schools to incorporate computer literacy courses in their curricula and has promoted and funded the construction of computer classrooms with Internet access. The students in the present study could have been expected to possess basic keyboarding skills and familiarity with word processing and spreadsheet software.

This was not true of a small but significant number of students who seemed completely ignorant of keyboard and mouse use, and standard user interface conventions such as files, folders, and menus.

When the existence of such students became evident, the author set aside additional computer lab time and took students step by step through the initial CMS registration process. Some students were totally unable to follow the simple instructions, even when demonstrated on a video-projector screen, and had to be assisted by students sitting next to them.

This fundamental lack of basic computer literacy was reflected in the way students used the CMS and examples have already been given in previous sections.

The most disturbing and surprising discovery was the lack of concern among many of these computer-illiterate students. Perhaps the necessity of basic computing skills was not brought home to them by their primary or secondary school teachers, or perhaps the prevalence and popularity of Internet access via cellphones had led them into complacency.

Informal interviews with CMS administrators of US universities confirm that such computer illiteracy is not a problem. However, before concluding that the Japanese education system is at fault, it should be noted that computing in a Japanese-language environment is more complicated than computing in English, French, Spanish, or other alphabet-based language.

The formatting of assignments submitted by a few students indicated that they were familiar with Japanese word processing conventions but unfamiliar with the English equivalents.

Some attempted to input English using zenkaku two-byte alphanumerics. Others switched erratically between English and Japanese input modes. Many seemed unaware that English typography demands a space after a period or comma. Most conspicuous was persistent use of swung dashes and other symbols common in Japanese word processing. In most cases this resulted in garbled or illegible text when displayed on the instructor’s computer screen.

Future Compatibility

At the beginning of this discussion it was stated that adoption of a CMS in support of conventional courses demands a major investment of time and effort. Even if the CMS is part of a school or university computer network, individual instructors still need to spend time adapting course materials for CMS use. Documents have to be scanned and converted to HTML or PDF formats. Files in proprietary formats such as Microsoft DOC may need to be saved as RTF or TXT files to ensure the widest compatibility. If the course instructor wishes to place audio or video files on the CMS, or incorporate them in online lessons (an option provided by the most recent versions of Moodle), a choice needs to be made from among a plethora of competing and mostly proprietary formats.

File format obsolescence is an unwelcome by-product of the rapid pace of computer development. Documents created as recently as ten years ago may be unreadable because the applications with which they were created no longer run on modern computers.

In putting together CMS materials constant thought needs to be given to the inevitability of future migration — the transfer of existing files and data to a different system.

One key to such a successful migration is the separation of content and format and a departure from proprietary file formats that lock the two together. The Extensible Markup Language (XML) is a promising solution and is attracting increasing attention.


In terms of objectives met, the present study was an unqualified success. Installation of the Moodle system was simple and straightforward and, once installed, the system functioned smoothly and reliably. Subsequent updates were surprisingly easy, taking an average of less than five minutes to perform.

The overwhelming majority of students found the system easy and enjoyable to use. The instructor was particularly impressed by the positive effect of the Journal module on correction of student assignments. Preliminary drafts could be returned much more quickly than before, and the quality of corrections and suggestions improved by rapid feedback from students.

Other modules, used alone or in combination, facilitated collaborative multimedia projects that would have been impossible in a classroom-only environment.

The option provided by recent versions of Moodle of embedding audio and video files in course materials opens up the possibility of further improvements in support for foreign language teaching.

Source: Waseda University School of Commerce Cultural Review, No. 28, 2006