Technical Design Issues for Online Course Development
Francis Lau, Marilynne Hebert
Version 1.0
September 1, 1999
Table of Contents
1. INTRODUCTION
The purpose of this document is to discuss the technical design issues involved in offering the online courses for the Distributed Experiential Learning Program in Evidence-based Practice for Health Professionals. It is to be used with the Guiding Principles document on the development, delivery and assessment of these courses.
The guiding principles are based on the organizing framework created by the Centre for Adult Learning and Educational Credentials, American Council on Education 1996. The five principles are outlined as follows:
· LEARNING DESIGN: Distance learning activities should be designed to fit the specific context for learning.
· LEARNING OUTCOMES: Distance education programs should organize learning activities around demonstrable learning outcomes, should assist the learner to achieve these outcomes, and should assess learner progress by reference to these outcomes.
· LEARNER SUPPORT: Distance learners need to be effectively supported both in using the technology and in learning how to be self-regulated learners in an online environment.
· TECHNOLOGY: The technology selected by learning providers must support the learning goals and activities of the distance education program.
· ORGANIZATIONAL COMMITMENT: Distributed learning initiatives must be backed by organizational commitments to quality and effectiveness in all aspects of the learning environment.
This document translates the above guiding principles into specific technical requirements, system design options, and suggested actions to be considered by the project team. The following assumptions were made when preparing this document:
· The ten courses cited in this program may be derived from existing courses, but they should conform to the guiding principles in order to maximize the experiential learning aspect of the program.
· It is expected that the investigators/instructors involved with the specific courses will work within their university to get the courses approved for credit at the graduate level.
· Initially, learners will register at the respective universities that are offering the courses. This means that the initial system will not deal with online registration. However, some personal information will be collected in order to understand the profile of the learners.
· HEALNet is holding a workshop in October this year to discuss setting up a national health informatics curriculum. If possible, we would like HEALNet to take the lead to coordinate with all the universities to work out a common registration and degree granting process for this program.
· Since OLT and LEE are funding this program as a research and development project, we need to include evaluation as an integral part of the program at the course, program and project level.
2. TECHNICAL REQUIREMENTS
The technical requirements are organized according to technology platforms, system features and ongoing support. Technology platforms relate to the technical infrastructure needed to support the development and delivery of the courses in the program. System features refer to types of interactions to be supported through the courseware used. Ongoing support addresses the technical support required to develop and deliver the courses. These requirements are outlined below. A summary of the requirements is included in Appendix A.
2.1 Technology Platforms
2.1.1 The courses in this program will be web-based, accessible anywhere and anytime using a Web browser regardless of the platforms used to develop and deliver the courses. It is expected that most learners will be using a dialup modem to access the content. As such, the use of video clips, graphic images and special plug-ins should be carefully planned. The need for proprietary software to be installed on individual computers should also be kept to a minimum, except for such common plug-ins as Real-Audio and Acrobat PDF file reader.
2.1.2 Initially, a distributed approach is suggested for the development, delivery and support of the individual courses. This is to allow participating universities to take direct responsibility in managing their own courses. This approach also makes it easier for other universities to join the program over time with additional courses using whatever technology available within their institution. A central technical group will be available for those universities that do not wish to develop and support the courses locally.
2.1.3 For those universities that wish to develop, deliver and support their own courses, they must have the necessary technical infrastructure in place to host web-based courses. This infrastructure should include the appropriate software (i.e. courseware) to develop the courses, a production Web server to host these courses during their delivery, and adequate technical staff to support the environment. Most importantly, at least one of the investigators/instructors must be willing to take the lead in managing this infrastructure within their institution.
2.1.4 A portal website will be maintained by one of the universities to bring all of the individual courses together under a common program structure. This portal website will contain all essential information that describes this experiential learning program, such as registration procedures, tuition fees, course descriptions, staff directory, etc. As well, this site will act as the central repository to collect information on the learners including their demographics, feedback and grades. It is expected that access to all of the courses must be made through this portal site. The university responsible for this portal site must also have the appropriate technical infrastructure in place and be willing to maintain this site. Over time, this portal site will be expanded to provide a one-stop-shopping for the learners to officially register in the program, pay tuition fees and seek advice, etc. without going through the different universities. The staff at this site should also be able to develop and support individual courses if requested by a particular university/instructor.
2.2 System Features
2.2.1 As much as possible, the different features of the courseware should be integrated to provide a seamless environment for the learners. This includes the use of a single login, a common look-and-feel design, and a simple Web interface without having to go in and out of different applications.
2.2.2 Initially, even though the learners are expected to officially register with the respective universities that are offering the courses, they are requested to “enroll” in the program via the website using the courseware through the portal site. This is to allow us to collect enrollment statistics centrally, thus reducing the need to obtain such information from the respective universities.
2.2.3 To facilitate electronic communication among learners and between learners and instructors, the courseware used should include a calendar, asynchronous group conferencing, group and private email, online chat, and distribution list.
2.2.4 The courseware should have the ability to collect ongoing learner feedback through online surveys. While individual courses may have their own feedback surveys, there should be a standard set of course evaluation survey for all courses where the responses are collected centrally through the portal site.
2.2.5 To foster collaboration on assignments and projects, the courseware should support document sharing and Web publishing among the learners. If desired, learners should be able to contribute their work to the course website as part of a dynamic repository for sharing by others.
2.2.6 The courseware should have the ability to track usage statistics on course content and learner interactions. The usages should be available by different parameters such as learner, date/time, location, Web page and Web link. The participating universities will need to submit such statistics as part of the evaluation of the course, program and project as required by the funding agencies.
2.2.7 The courseware should facilitate course management functions such as instructor ability to add/delete learners, assign user ids and passwords, create/edit homepages, manage interactive discussion groups, conduct online testing, obtain usage statistics, track learners performance, create calendars and incorporate hyperlinks to other Web resources.
2.2.8 Initially, when the learners complete a given course or specific modules of that course, the instructors will be responsible for maintaining the corresponding grade(s) in the learner record for credit granting purposes within the respective universities. In addition, the instructors will be required to update the learner record maintained centrally at the portal site. This is to allow the program to track the enrollment status of the learners centrally.
2.2.9 There should be a common set of introductory tutorials and/or instructions for learners on how to use the website and make effective use of the different features available. Individual courses may require additional instructions if they contain special features not available elsewhere. Similar tutorials/instructions should be provided for instructors who are not familiar with developing and delivering Web-based courses.
2.2.10 Where feasible, parts of the courseware and content that are similar across different courses should be shared as common resources and tools. Examples may include links to evidence-based websites, decision analysis tools, public domain software, research literature and published reports. These may be stored on the portal site as part of a central library for learners to access beyond what’s available within a given course.
2.3 Ongoing Support
2.3.1 Initially, for those universities that are developing and delivering their own courses, they are expected to provide local technical support to the instructors and learners as needed. Especially for learners, a formalized online help desk is recommended. The hours of operation and the extent of support to be provided will be dependent on the resource availability of the respective universities, but should be within a reasonable amount of effort and time frame.
2.3.2 For the universities engaged in developing their own courses, it is strongly recommended that a set of standard reusable templates be developed for the local site. This is to simplify the development process and its subsequent support. Furthermore, the templates can reinforce the common look-and-feel design between different courses.
2.3.3 A centralized online help desk function will also be provided by the university that is hosting the portal site. The forms of communication will consist of email, phone and fax. The extent of support will be limited to handling queries at the program level. Any questions with individual courses, unless fairly straightforward, will be referred to the responsible universities/instructors. The hours of operation provided will be dependent on the resources available, but is expected to be within a reasonable time frame.
2.3.4 All calls received by the help desk, whether centralized or local, should be formally logged into a central database using a web-based help desk software for subsequent analysis. This is to allow us to understand the pattern of help requested by the learners (and instructors).
2.3.5 The technical staff for the central help desk will be responsible for maintaining the centralized databases for learner enrollment, feedback survey, and help desk call log. In addition, they will be responsible for maintaining the content and links in the portal website. The staff can also support centralized group conferencing for all courses if that is desired.
3. DESIGN OPTIONS
Different software packages are available for developing and managing these courses over the Internet. These packages range from those that require strong programming skills to others that are more or less “canned” courseware. It is beyond the scope of this document to describe and compare the different packages on the market. Instead, this section illustrates several packages that are already in use at the University of Alberta or have been suggested by project team members. A summary of these packages is included in Appendix B. For more information on educational courseware packages and their reviews, see http://www.ctt.bc.ca/landonline/. Also included in this section are the possible technical architectures for the program based on the technical requirements listed.
3.1 Web Development Tools
3.1.1 An example of web development tool is FrontPage. It is both a drag-and-drop (or point-and-click) website development tool and a website management tool. For simple course content no html programming knowledge is required. With some training, instructors are usually able to create and manage their own content, especially if technical support is available for the more complex aspect such as setting up online surveys and database connectivity.
3.1.2 FrontPage is a very flexible web development tool, but it is not specifically geared toward online course development. For instance, while FrontPage has a basic group conferencing and chat module, and a rich set of website management functions, it lacks any built-in templates for learner surveys, registration, tracking, etc. Users of FrontPage will have to design and develop these pieces from scratch, which can be time consuming.
3.1.3 In order to use FrontPage, one must have a Microsoft NT-based IIS Web server with Active Server Page Extensions. A related development tool is Microsoft Visual InterDev, which provides connectivity to such databases as Access and SQL Server through the Web. Note that this Microsoft platform (i.e. FrontPage, InterDev, IIS, etc.) is not compatible with the Unix servers that are typically used by universities to host their university-wide website.
3.1.4 The Business Faculty at the University of Alberta has been using FrontPage, IIS Server, InterDev, and Access database with Active Server Pages to develop web-based courses over the last three years. A set of standard templates has been developed by the Technical Resource Group within the Faculty to facilitate the conversion of existing courses to web-based format. See http://courses.bus.ualberta.ca/mis541-lau for an example of a typical web-based course offered by the Business Faculty. The features available with the templates include group conferencing and feedback surveys.
3.2 Commercial Courseware Package
3.2.1 An example of a commercial courseware package is WebCT, which was developed at the University of British Columbia. This software is geared specifically for the development and delivery of web-based courses. It offers a standard set of templates for calendaring, online testing, student logins, student performance tracking, group conferencing and live chat. For instructors there are built-in website management functions for file transfer, web page design and directory maintenance directly through the WebCT website. Students can also present their work by posting their documents on the website, and review their performance in the course.
3.2.2 An important consideration for WebCT is that it runs on a secure Unix server, which means all access to the website content is ID and password protected. It also uses a proprietary database backend to store all of its data. Because WebCT is hosted on a Unix server, one has to use Unix based tools such as CGI or PERL script, and Unix SQL backend database for the more advanced web development beyond basic html pages.
3.2.3 The University of Alberta has started using WebCT two years ago for faculties and departments that are willing to adopt this platform. So far the University has over 100 courses converted to WebCT. While some instructors use the WebCT website directly to develop the courses, others resort to tools such as FrontPage and merely transfer the completed content to the WebCT website, and use it for course and student management.
3.2.4 Since the University of Alberta has adopted WebCT as the official web-based courseware platform for the entire university, it has established an entire technical infrastructure to support this environment. It includes a central technical support team to manage the servers and software, administer the instructor/student accounts, customize the software, conduct training workshops and provide consultations to help instructors develop web-based courses.
3.2.5 To access the list of WebCT courses developed at the University of Alberta, see URL http://www.ualberta.ca/webCT. To see a specific example of its use, go to URL http://www.ualberta.ca/WEBCT/business/index.html, select Web-based Business Information System link, enter username flau and password sidney. To get a developer view of WebCT, go to https://webct.srv.ualberta.ca/webct/public/show_courses, scroll down to MIS413 Systems Analysis and Design, enter username MIS413 and password francis. You will be presented with a set of buttons available only to course developers.
3.3 Specialized Software
3.3.1 An example of a commercial web-based asynchronous group conferencing tool is Webboard. With this software, registered users can login to a particular conference, post a discussion topic, respond to the topic, attach documents for sharing, and take part in live chat sessions. The conferences can be open, moderated or closed as required. There is built-in usage tracking to monitor the pattern of participation. The user interface can be customized if desired; all postings and usage data are stored in an Access database that can be exported. See http://courses.bus.ualberta.ca/mis541-lau for an example of the use of conferencing as part of a course in the Business Faculty at the University of Alberta. To run Webboard, one needs to set up the software on an NT Web server and designate an administrator to manage the conferences.
3.3.2 An example of a group collaboration tool is http://www.vicinities.com developed by Ramius Corporation. It allows users to create and participate in collaborative online communities known as vicinities. Within vicinities, users can collaborate by publishing information, engaging in discussions, sharing notes, storing lists, exchanging files, conducting polls, exhibiting photos and images. Each vicinity is established, configured, and managed by users without requiring any knowledge of programming or any downloading of software. This free service is entirely web-based making it accessible from any computer connected to the Internet. A quick search of the vicinities directory showed there is a Nursing Health policy 697 course to be offered this fall. No information is available as to who is offering this course or where it is being offered.
3.3.3 An initiative currently underway at the University of
Alberta is the Centres for Health Evidence (CHE) project. The purpose of CHE is
to package, disseminate, and present health knowledge
in ways that facilitate its optimum use by health professionals. Within a CHE,
staff will monitor knowledge-based software and literature from a variety of
public and private sources. Significant resources are identified, and for these
items, structured summaries are developed to alert the user to the quality of evidence
supporting health recommendations, the relative importance of recommendations,
and how the needs of specific patients, practitioners and settings are
addressed. CHE also facilitates training for health professionals to optimize
their understanding and use of evidence-based health and the technologies that
carry the content. CHE is developing web-based training workshops in the areas
of critical appraisal, literature searches and information technology support
for evidence-based practice. To preview the CHE website still under
development, see http://www.cche.net.
3.4 Possible Architectures
3.4.1 The technical requirements suggest a distributed technical architecture connected through a common portal site with certain centralized support functions. Specifically, the individual courses will be developed, delivered and supported by the respective universities according to the common set of guiding principles. A set of databases will be maintained centrally to facilitate the management of the program. These databases include learner enrollment demographics, online surveys, course grades, resources/tools library, help desk logs and usage statistics. Learners are required to provide their information for the databases via the website, even though they still need to officially register with the respective universities for formal course credits. Instructors are also required to record learner grades in the databases to facilitate performance tracking. Also to be maintained centrally are the Web pages on the program and tutorials on how to use the website.
3.4.2 A basic technical architecture is shown in Appendix C. Variation to this basic architecture is possible, depending on how much the respective universities wish to take on the responsibility to provide the central support functions. For instance, participating universities may divide up the central support functions in terms of managing the enrollment, surveys and library databases, help desk operation, and website tutorials.
3.4.3 To be successful, there needs to be strong technical leadership both within the local universities and at the central site. For universities that are developing and supporting individual courses at the local level, at least one investigator/instructor should be willing to manage the technical infrastructure and support staff. Similarly, at least one investigator/instructor is needed to manage the central portal site to ensure it is meeting the needs of the program and its project team members. Close ongoing communication is also recommended among the local and central support teams.
4. SUGGESTED ACTIONS
A list of suggested actions is provided below for considerations by the project team. These actions should be acted upon as soon as possible in order to adhere to the project schedule. Specifically, the team needs to decide on the following:
4.1 The technical architecture to be adopted in terms of the extent of centralized and distributed functions involved.
4.2 The system features to be included in the courseware, and the type of courseware to be adopted by the respective universities.
4.3 The actual courses to be developed by the respective universities, and whether the universities involved wish to undertake the development and support of these web-based courses locally or centrally.
4.4 What should be included in the central portal website, assuming if such a central site is preferred.
4.5 The type of ongoing support to be provided locally and centrally, and how such support can be coordinated between different universities.
4.6 The amount information to be tracked and whether they should be tracked centrally or locally. Such information include learner enrollment, feedback surveys, course grades, help desk logs, resources/tools library.
5. APPENDICES
Appendix A – Technical Requirements
Appendix B – Design Options
Appendix C – A Basic Technical Architecture
Appendix A – Technical Requirements
|
2.1 |
Technology Platforms |
2.1.1 Web based courses accessible through web browser, with minimal proprietary software and special downloads and plug-ins |
|
|
|
2.1.2 A distributed approach to develop, deliver and support individual courses by universities with some central support functions |
|
|
|
2.1.3 Web technical infrastructure and investigator/instructor leadership needed at local universities |
|
|
|
2.1.4 Central portal website needed for program and collection of enrollment and performance information |
|
2.2 |
System Features |
2.2.1 Integrated interface with common look-and-feel design, single login preferred in courseware |
|
|
|
2.2.2 Learner enrollment information to be collected through central portal site |
|
|
|
2.2.3 Courseware features to include calendar, conferencing, chat, email, distribution list for communication |
|
|
|
2.2.4 Courseware to allow local and centralized collection of feedback surveys |
|
|
|
2.2.5 Courseware to allow collaboration through document sharing and website publishing among learners |
|
|
|
2.2.6 courseware to track usage statistics on content and interactions at course, program and project levels |
|
|
|
2.2.7 Courseware to allow instructors to manage content, course and students directly |
|
|
|
2.2.8 Learner course grades to be maintained centrally for course and program performance tracking |
|
|
|
2.2.9 Tutorials on website use required for learners. Similar instructions needed for instructors on developing web-based courses |
|
|
|
2.2.10 Common resources and tools to be archived in library on the central portal site |
|
2.3 |
Ongoing Support |
2.3.1 Help desk support is needed for individual courses at the local universities |
|
|
|
2.3.2 Standard reusable templates for developing courses recommended for local universities |
|
|
|
2.3.3 Central help desk support at program level is needed at the portal site |
|
|
|
2.3.4 All help desk call logs to be recorded in a central database for tracking |
|
|
|
2.3.5 Technical staff at portal site to maintain central databases and portal website |
Appendix B – Design Options
|
|
Type |
Software Characteristics |
Requirements for Use |
|
3.1 |
Web Development Tools |
|
|
|
|
FrontPage and InterDev |
General Web development and
management tool Has login, conferencing,
chat capabilities but requires setting up Little programming skills
needed for basic content Programming skills needed
for surveys, databases Not specific as courseware See Business Faculty U of A
http://courses.bus.ualberta.ca/mis541-lau |
NT IIS web server, ASP
extensions Not compatible with Unix
platform Need to develop own
templates especially for data collection |
|
3.2 |
Commercial Courseware |
|
|
|
|
WebCT |
Specific for web-based
course development Has secure login, testing,
calendaring, conferencing, chat, course and student management Support course development
and management See U of A for course list http://www.ualberta.ca/webCT |
Run on Unix platform with
proprietary databases Need Unix based software
e.g. CGI, PERL scripts Can use PC to develop
content then import to webCT server Need technical support team
for server/account administration, and user training |
|
3.3 |
Specialized Software |
|
|
|
|
Webboard |
Asynchronous group
conferencing software with live chat, usage tracking, attachments Customizable, data in
Access See Business Faculty U of A
http://courses.bus.ualberta.ca/mis541-lau |
Run on NT web server with
conference administration required Tool for conferencing only |
|
|
Vicinities.com |
Group collaboration tool to publish information, engage in discussion, share notes, store lists, exchange files, conduct polls Free service with no
programming knowledge required Use website to set up
vicinities |
Site maintained by Ramius
Corporation Tool for group
collaboration only |
|
|
Centres for Health Evidence |
Project to package,
disseminate and present health knowledge to health professionals via the
Internet Developing training modules in critical appraisal, information searches and technology support for EBP See website www.cche.net |
Website still under
development |
Appendix C – A Basic Technical Architecture
