View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide

Page 1

Draft Report from the Subcommittee on Learning Management Systems to the Academic Technologies Advisory Committee

Introduction
The subcommittee has met weekly since early in March and participation has involved approximately 6-8 members at each meeting with a core of 4 or 5 attending all meetings. The participants represent a range of users of LMS from basic to advanced large class applications, and includes faculty who have developed and tested a range of educational technology. This report summarizes the consensus developed by this subcommittee and highlights key points.

Tasks and Accomplishments

The first task was to define as generally as possible the requirements for LMS at Georgia Tech. A summary is attached at the end of this report. As expected, these requirements are quite extensive: no known LMS will meet all of them and they span a range of teaching methods and applications.

A second task was to try to survey the campus experience with the use of LMS’. We believe that there is no current LMS solution that meets the needs of a significant proportion of the users and potential users of an effective LMS at Georgia Tech. This situation arises almost entirely because of the wide range of learning environments on the campus and the widely different instructional styles developed and employed by the faculty. In many cases these differences arise simply because of the sheer size of the particular courses, while in other cases the differences arise because of the differences in pedagogy, course content, student level, resources available to the instructors (including computer support, availability of TAs, etc), and activities required of the students (e.g., labs, design projects, team work, etc). Not surprisingly, it is sometimes difficult to find many common requirements between different instructional situations. For example, an interface to Banner may be an essential requirement for a large undergraduate course, but may be undesired for a weekly seminar with only a dozen or so students and other attendees not listed in Banner. The only common requirement may be the need for participants to access the system via the internet and wireless devices.

A third task was to survey the different LMS’ developed locally by faculty and staff. The preliminary results of this effort are also attached. As one looks at these systems, it quickly becomes apparent that they address a wide range of requirements, many times with quite elegant solutions to immediate problems, but also with limited applicability. This diversity of applications is itself a concern. While they may be operational today, the owning unit generally does not have the funding and/or the desire to maintain these systems indefinitely. Likewise, many of these systems would benefit from integration with other systems, either by providing new functionality to more established systems, or having access to functions within established systems; however, the necessary funding and coordination mechanisms for these synergies are currently lacking.

Recommendations

LMS’ will have a significant role in potentially-profound changes to education at Georgia Tech. At the most practical level, they provide administrative functions (grading, email, distribution of course materials) that enables more cost effective instruction in large courses. Additionally, they can enable significant improvements in instructional methods (one example is the ability to use instructional time for active learning activities when presentation of course material is given via an LMS), and can enable new concepts of courses, including distributed and asynchronous course delivery.

With these diverse range of applications, however, comes a correspondingly broad set of requirements for LMS at Georgia Tech, as outlined in this report’s attachment. To maximize the range of requirements that Georgia Tech’s educational infrastructure is able to support in the near term, and to advance our capabilities in the future, this subcommittee submits these recommendations:
  1. We recommend that Georgia Tech become fully involved with the Sakai Project, a community source software development effort to design, build and deploy a new Collaboration and Learning Environment (CLE) for higher education. We make this recommendation for three reasons:
  2. We recommend that WebCT remain the campus supported solution, but that other options such as add-ons or tools developed in house be given support for research and development, and that innovators across campus be given access to the in-house developed tools for the purpose of learning and testing new techniques.
  3. We recommend that, in the near-term, operations with the established “legacy” LMS’ continue where they can demonstrate benefits meriting their continued use. This includes WebCT where it is in use today. New requirements that must be met immediately should also be satisfied with established systems.
  4. We recommend that an interdisciplinary group work to develop and grow Georgia Tech’s LMS solution to meet the needs identified by faculty but not met by WebCT or other commercial LMS products. This “LMS support group” should generate a vision and lead GT policy regarding the management and use of LMS’ and be charged with developing, managing, and supporting their use. It should coordinate the efforts of campus groups who are developing and supporting them and look at key issues such as supporting the integration of content into them. While it is natural to assume that such a group be housed in OIT, the relative merits and prevailing trends of other organizational models in learning technologies support should also be specifically considered, such as a hybrid approach between, OIT, CETL, and the Library. .
  5. We recommend that a range of different LMS’ be made available for use by the faculty. These LMS’ should be selected to try to meet the varied needs of the instructional faculty. While some priority should be given to the largest classes, the collection of LMS’ should encompass the greatest range of learning environments possible. For example, it seems reasonable to not only support a large LMS like WebCT, but also to support the much smaller CoWeb (aka Swiki) LMS, as well as dedicate some resources to a future, emerging open system solution such as Sakai. In considering which LMS to support, a cost-benefit analysis should be used; costs to consider may include required support, and scalability and portability issues, while analysis of benefits must account for the functions of the LMS relative to otherwise unmet educational requirements.