Sue Sawkins, Southern Cross Online Southern
Cross University, ssawkins@scu.edu.au
Allan Ellis, School of Social and Workplace Development Southern
Cross University aellis@scu.edu.au
Schelly Gardner, Southern Cross Online Southern
Cross University sgardner@scu.edu.au
Competitive pressure to be part of the global explosion of Internet delivered, Web-based courses has resulted in many universities implementing 'off the shelf' courseware management systems. These initial systems, whilst providing an effective start-up environment, will likely over time not continue to meet the evolving needs of the institution or offer the features and efficiencies of new products. Sooner of later a transition to a new Web-based courseware management system will need to occur. This paper details such a transition at Southern Cross University. It describes the transition's goals and plans and compares them with the actual implementation steps and final outcomes. From the lessons learnt, eleven recommendations are made that should be useful to other institutions encountering a similar situation.
Southern Cross University (HREF1) has a long history of exploring and using the World Wide Web (the Web) and its associated technologies (Ellis & Sawkins, 2000). It also has over ten years' experience in designing, developing and delivering off-campus and external degree and diploma programs. In the mid 1990's several groups of academic staff experimented with putting individual course units and unit resources onto the Web. This hand-crafted courseware was the beginning of the University's move into Web-based, online educational provision.
During the last five years, universities worldwide have come under increasing competitive pressure to enter what the media term the "global online education marketplace". This involves developing, marketing and delivering Web-based courseware over the Internet. This move to technology-based learning has also caused a re-think of the traditional division between on-campus and off-campus modes of study. Increasingly, online Web-based course materials are seen as being suitable as study materials for both modes.
By early 1998 this pressure saw the Executive of Southern Cross University seek submissions for major online course development initiatives. In mid 1998 it approved substantial funding for the development of two fully online degrees: a Bachelor of Social Science and an Associate Degree in Paralegal Studies. This funding decision also involved a commitment to use Lotus Notes LearningSpace™(LS), the IBM/Lotus courseware management hardware/software system, as the university-wide development and delivery environment. Management thinking was to build up strategic alliance with IBM who was seen as a major player in the global online education marketplace. All work was to be undertaken using a project management approach and was to involve using multi-disciplinary development teams (Sawkins & Archer, 1999).
After the delivery of the first units in Semester 1, 1999 it was evident that there were a number of constraints with the operation of LS in the University's environment. The problems extended to many aspects of the development and delivery process and were evident to all stakeholders including students. Outsourcing administration to IBM business partner of both the online courseware and the server software also created numerous difficulties, including the provision of timely solutions to technical problems as well as creating a deficit of technical expertise within the University's Online Technical team. As the software solution required an IBM Domino server, technical dependency was inherent from the start. In essence they stemmed primarily from the product's origins and evolution in the corporate sector prior to the development of and widespread use of the Web. Some of these problems are documented in more detail in Patterson, Ellis and Brice (2000) while others appear in internal unpublished reports. Because of the high level of technical assistance required to support staff and student users of the system it would be exceedingly difficult to increase the spread of its use more broadly across the institution in any sustainable way.
As part of the partnership with IBM the University Executive had commissioned the development of an Online Strategic Plan (released early 1999) which aimed to comment on all aspects of the University's move into the online arena. In the second half of 1999 a comprehensive review of LS and an evaluation of the features and suitability of its Web-based Course Management System (WBCMS) commercial competitors was undertaken. The Working Party reported to the University Executive in December and recommended the University adopt Blackboard CourseInfo (BbCI) (HREF2) as the replacement courseware management system. This recommendation was accepted and planning for the transition commenced immediately, with the target timeframe for compete transition being set at one year.
The transition would be twofold: to migrate to a new WBCMS and to broaden its use across the organisation. The task ahead was analogous to changing cars mid-race. The challenge would be to maintain continuity of online delivery during the transition, with full support being maintained for the current vehicle (LS) while a new model (BbCI) was commissioned, tested and training/support mechanisms established, in other words, keep both vehicles on the track while the drivers and passengers changed vehicles.)
The overall transition process was mapped out in late December and early January and involved:
The success of the transition process would be judged by the following outcomes:
The transition plan encompassed a number of key strands. Some of these were parallel, and each a mini-project on its own. These were closely coordinated so that the University community would be supported through the transition and be kept informed of its progress.
Three main strands comprised the technical planning, namely, setting up the architecture for the BbCI environment, migrating existing materials from LS into the new BbCI environment, and closing down the old LS server. The migration of existing materials from the current environment into BbCI would take place progressively during the year, as current delivery periods were completed. A technical procedure, devised to facilitate the conversion process, would be circulated to the content developers involved.
A schedule for the shutdown of the LS server would include a full archive of unit content, instructions for all users who desired to create copies of their content and for the removal of the software from computers, in accordance with the license agreement.
In readiness for the move into BbCI the following preparations would be made. Two server environments would be set up with Linux RH6.1 operating system installed. Backup and redundancy systems would be established and full functionality testing carried out prior to staff accessing the BbCI environment. The first server, secured from all student access would be dedicated to the development of online units, the second server would be the live environment, delivering units to students.
During the development phase (January to June) the online technologies team (within Southern Cross Online) would skill themselves in the administration of the courseware and develop a set of procedures for the migration of units from the development to the delivery server
The brief was to provide as easy as possible access route with a single authentication process for students. To enable this to happen, the delivery server would need to be located within the student intranet. Whilst access authorisation protocol would be set up by the online technologies team, and thus this group would be, by default, the technological gatekeeper, it was vital to differentiate this mechanism from the actual authority and approval for access which is vested in the academic owner of each unit.
The proprietary nature of the environment required that caution to be exercised in the way content should be created and archived. In the longer term, solutions would need to be found for migrating material from one shell to another, for archiving materials, and address the question of accessing units once a licence for the software had expired.
Minimum computer and browser specifications and associated plug-ins would need to be clearly articulated as this would also impact on the way materials were developed. (A 133 MHz or faster processor, minimum 32 MB RAM with a modem capable of a minimum connection speed of at least 28.8 kbps, a sound card and speakers (built in for Macintosh) were the minimum hardware requirements specified for both Macintosh and PC's, with PC's in the Pentium class. Minimum operating system requirements were Windows 95/98 or NT4 for PC's and Mac 7.6.1 or later for Macintosh. Browser versions Netscape and MS Internet Explorer version 4 or later.
Providing a balance between a Web-based environment accessible to a broad cross-section of student users while at the same time exploiting the potential which multimedia and other applications can bring to online learning activities would be an ongoing tension.
Staff and student users of BbCI must be able to access, from the point of initial contact, timely and appropriate support and training.
For staff, hands-on half-day sessions would be run for beginning users of BbCI, both for the development of materials and for delivering in the environment. To supplement this basic training, staff would be able to participate in regular face-to-face demonstration/clinics designed to extend skills and showcase particular features. Ongoing 'how-to' support would be available to staff via a number of media; a dedicated email helplink address to provide rapid response to staff user questions and problems; a BbCI support Web site to provide up-to-date information, registration forms to set up and move units, FAQs page for latest tips, tricks, bugs, and demonstration sites to showcase features. Email bulletins would keep users informed about BbCI updates and server status. The aim of providing these resources was to encourage staff to be as self-reliant as possible in using the BbCI technology. To further support School-based activity, a network of liaison/on-site support users would be established. These 'super-users' would be able to provide timely technical assistance to staff in their own Schools /work areas, as well as being key conduits for information and escalation of issues between the Schools and the centrally located Online support team.
An introductory welcome document mailed out by Information Services Directorate would direct student users to a 'howÐto-use' resource which would walk them through the BbCI environment, and provide details about online access time /cost, etc. A centralised, front-line phone (Monday toFriday) and email helpdesk would filter student requests to the appropriate sections speedy response, and an online FAQ page would provide students with hints and answers to commonly experienced problems.
The transition activities would be a collaboration between work areas in the Information Services Directorate and the support groups within various Schools. Responsibility would need to be apportioned for a range of activities, including, technical set up of the software and establishment of a robust server environment, training and support for BbCI users, change management and communication; frontline student support for delivery in LS during 2000, and similarly for students undertaking units delivered in BbCI from Semester 2, 2000.
The funding allocation for the transition would need to factor in costs involved in the retirement of the existing software (LS) and archiving of content and the start-up expenses associated with the introduction of BbCI during 2000.
Web-based courseware development and delivery is a multidisciplinary endeavour, drawing together academic, learning support, technical, and administrative expertise. Reinforcing the collaborative nature of the activity through seminars, forums and discussion would be an important element in the communication strategy. During the transition period it would be important to establish an effective communication mechanism so that all the various stakeholder groups received accurate and timely information. If the University community was to 'buy in' to this centrally supported online learning environment it needed to be informed about the process and have opportunities for discussion and exploration of the opportunities afforded by using the BbCI environment.
There needed to be:
The transition was part of a broader strategic direction being established for online directions at the University. The key indicators of success for the transition process itself would be achievement of the objectives set for the transition by end December. Monitoring progress towards achieving these objectives would be undertaken by:
The first six months (January to June) would be a development stage, preparing the environment and developing units of study in for delivery in BbCI. The first delivery period would commence in Semester 2, (July to November). In parallel, the conversion of units previously delivered in LS would be undertaken and the environment de-commissioned when the final delivery was concluded (by December at the latest). Figure 1 presents the schedule of tasks and key milestones associated each strand of the transition plan.
|
Task no
|
Task Name
|
Timeframe
|
|
1
|
Maintain support of LS Prepare for Trimester 1 (T1) & Semester 1 (S1) delivery: (server admin troubleshooting and quality monitoring , add units, add chitchat databases, enable access); Enrol students; Deliverer training sessions and consultation |
January to August
|
|
2
|
Migrate content from LS to BbCI |
January to June
|
|
3
|
Close down LS server Develop implementation plan for close down of LS server; Migrate S1 units to server as holding measure; notify staff/students with information on changed arrangements; remove access from all Notes users; Close down/redeploy LS server |
March to June
|
|
4
|
Set up development server for BbCI Purchase hardware; install Linux RH 6.1 server software; Configure server ready for BbCI; test functionality; Establish back-up procedure and redundancy plan; Test back-up procedure |
January
|
|
5
|
Get BbCI software up and running Purchase licence copy of BbCI; install software; test functionality |
January to February
|
|
6
|
Establish delivery server for BbCI |
February to June
|
|
7
|
Establish training/support structure for staff users
Develop step-by-step tutorial materials; develop Web site resource material Trial training sessions with staff developer group; trial email helplink; run first training sessions for developer/deliverers |
February to March
|
|
8
|
Establish training/support structure for student users Develop 'how-to' materials; trial materials with sample group; develop FAQs webpage; revise materials ready for distribution; send out how-to materials for S2 students; incorporate BbCI support into Online Support service |
March to July
|
|
9
|
Inform staff about the transition process
Send monthly updates to senior management; email staff - outline the transition programs; visit Heads of Schools/School meetings - Feb to April; organise program; establish follow-up procedure for School visits; meet with groups of School staff - on request; establish program of regular clinics - fortnightly; email all staff with details of clinics; keep the online support groups informed - monthly meetings; open seminar to outline preparation for S2 |
February onwards
|
|
10
|
Manage the transition Develop transition plan; gain endorsement for the transition schedule; develop monitoring procedure for quality indicators; establishing quality review cycle; review at each specific milestones |
January onwards
|
Fig 1: Transition plan: schedule of activities
This section outlines how the transition experience actually panned out. In many aspects it went 'according to plan' but there were some unexpected spin-offs and challenges. The development phase started early in January, with the purchase of the hardware and software and getting the schedule of activities up and running, the BbCI environment went 'live' officially at the start of Semester 2 (July).
It is important to note that the move to a new, easier to use WBCMS acted as a catalyst in a number of allied developments. It escalated the development of a personalised student portal page and created new priorities for student administration system. Whereas the earlier developments had been confined to specific projects, the new system was designed for University-wide take up and the training and support mechanisms were set up accordingly. This theme will be picked up again in Section 4.
Discussion of the outcomes and lessons learnt is contained in Section 4.
The server configuration was designed: one server housing the units being developed, one server dedicated to delivery and one server as a test platform. The test platform was a server dedicated to the pre-application of BbCI patches and minor updates for testing prior to release in the live environments of development and delivery and most importantly, a fail-over for the development server.
As the importance of the delivery of Web-based units to the University was recognised, a robust and failsafe delivery hardware was considered essential. A virtual server cluster was conceptualised, purchased and created, with the assistance of an outside expert tasked with the skills transfer of the maintenance of the environment. Backup and redundancy was built into the virtual server network with the advent of multiple database and web servers.
However, during Semester 1 and Trimester 1, several 'early adopters' negotiated to trial deliver in BbCI so the test platform was assigned to delivery duty. This created significant resource issues when the need to apply patches and make changes to the environment occurred and more importantly new resources and backup procedures.
Throughout the year, minor software updates, bugs and fixes were provided as a matter of course by Blackboard's own courseware developers. Processes for application of these updates were developed to ensure their application did not affect the environment adversely or significantly change the functionality of the software midway through a teaching period. Rigorous testing and evaluation prior to implementation was undertaken at each update before they were applied to the delivery environment. Notification of server outages for the application of these updates was provided to all users according to University policy.
Server maintenance issues became extremely important with the opening up of the BbCI environment to all programs in the University. Web-based units would be delivered virtually year round with few 'quiet times' for undertaking maintenance. Associated issues regarding provision of 24x7 support for systems as well as users are also currently under review.
Continued user and server support within LS was required in order to provide uninterrupted access to those who wished to continue to deliver previously developed content. As some lecturers were either not prepared to make a direct jump from one WBCMS to another, or felt it would disadvantage their students, continued user support within the existing courseware was required for the full year. Implementation of the shutdown for the LS server was deferred to two weeks after the end of the third trimester (December). Extra time was provided to allow those users who wished to save or copy any content the opportunity to do so.
Content removed from LS proved unwieldy and often inappropriate to the new online learning system. Much of the content migrated by the online technologies team during the initial process proved of little benefit to content developers. As a result, all present and future training included the concept of developing content outside of the WBCMS so it could be more easily used in another system in the future, using the system to 'hold' content, rather than 'develop' content.
Decisions made once the transition was underway expanded the scope of the exercise. Systems administration became a much bigger issue with the decision to create an online presence for every unit offered by the University, regardless of whether it was delivered online. This required a reconsideration of the meshing of existing administrative systems used in other departments in order to create a user account for every staff and student employed by or enrolled at the University. The large number of external students and overseas staff requiring cultural consideration in the naming convention in the online learning system added to the load, as did the creation of user templates, School-based units, work collaboration units. A special addendum to the license was negotiated with Blackboard to allow Southern Cross University to 'Australianise' or modify the spelling on buttons and associated text to conform with Australian English rules and grammar and meaning. To this end, each time a patch was to be applied, all previously made changes had to be isolated from the application of each patch.
In addition to the use of the existing Kerberos authentication protocol for single password access to the new online environment, consideration was given to providing a single portal to allow easy access to units by both student and staff. This portal was developed and deployed at beginning of Semester 2, providing each student and staff member with a customised entry to not only the BbCI environment, but also to the other areas of the student intranet, including the library, computer support, helpdesk contacts and each School Web site. If a student was enrolled in a unit that was not being taught online, they would still have the use of the 'student portal' as well as to the value added areas of BbCI, including an Web-based diary and address book.
As the population of users developing units for online delivery grew, so did the need for managing multiple modes of online delivery to multiple cohorts. 'School-based' units were created in order to provide a method of delivering timely information to a large group of students without duplication of effort. All students enrolled in at least one unit offered by a School would have access to this School-based unit from the portal page, and thus access to posted information and discussion forums. Each school-based unit contains basic information for help in navigating through online units as well as details about specific school contacts. Additionally, special units were created online to allow School staff to use the BbCI environment as a work collaboration tool.
Administration and management processes were redesigned to accommodate the various changes in Web-based unit delivery. Technical liaisons and relationships were developed with other areas of the University responsible for dissemination of student enrolment and staff employment details to ensure that accurate information could be acted upon in a timely manner.
At the end of the first delivery period (November) the question of archiving units raised a number of issues. Which area should be responsible for holding the official archives, was it a matter for individual Schools, or should there be a University-wide repository of material on CD-ROM held in the Library? Should there be an official archive? It was decided that in the short term, archives would be made and kept by the system administrators until such time as the requirement or official capacity was determined. As archives are proprietary to the software and so only viewable from within the BbCI environment the question of long-term viability was raised.
Just as content developers had been encouraged to create their content outside the BbCI environment in fully supported proprietary formats such as Word, Powerpoint, Excel and maintain these master files of their materials, they were also encouraged to keep archives by creating back-ups of their own materials and /or using the software to create proprietary archives, which they or their Schools would keep.
The Web-based environment more closely resembles a classroom than a library resource. It should be seen essentially an ephemeral environment and once the period of delivery has been completed students wanting to retain the materials as a long-term resource need to make copies on their own computer outside the CI environment. Whilst technically possible to keep open long-term access to all units, the pragmatics of managing such a burgeoning repository is not sustainable.
The first training sessions for staff who would be developing and /or delivering units in BbCI commenced in early March. These three-hour, hands-on sessions were run in various lab locations until a small, five computers (three PCs and two Macintosh) training room was set up. These sessions have continued all year, rotating days in the week and times of day to match with teaching commitments. Staff were able to book in via a web-page booking form, or in response to a staff email that is sent out to announce each new schedule. Sessions have also been arranged for School-specific groups.
These Introduction to BbCI sessions focus on raising confidence in using the technology as well as providing basic skills in using the various content placement features and setting up discussion forums and groups. Prior to attending a session each participant was set up with a 'practice unit' and enrolled in each other's unit as a student. Each participant was provided with a folder containing information about the support and resources available and a printed copy of the online instructor manual. In response to the feedback provided in the early sessions the content covered in these start-up sessions was streamlined and separate follow-up sessions were developed to cover the quiz, test and survey functions.
From first point of contact staff were encouraged to use the various support mechanisms available. These included:
The transition was driven by Southern Cross Online within the Information Technology Directorate. The online technologies team (three members on fixed /casual contracts) were responsible for administering the technical environment and worked closely with the group responsible for administering the WBCMS server environment. Specific expertise was called upon as the need arose. The training and support for staff was a collaboration between the online technologies team and the general online development (one person) and the helpdesk operational staff have provided the support to students.
There has been close collaboration between the educational designers from the Teaching and Learning Centre and Southern Cross Online to ensure that information and training to staff was appropriate and supported the pedagogical approaches taken. In some cases, where activity was high, Schools identified support staff to work with academics to migrate existing materials into BbCI and to work with staff on new development. It would be difficult to estimate the exact staffing requirements, as many of the duties and activities have been incorporated into existing workloads.
In addition to funds that were specifically provided for the transition under the terms of the plan, there was the need to re-deploy additional resources. Because the original plan accelerated a number of associated initiatives, total spending was larger than initially anticipated.
As the transition progressed, leading up to the roll out of the delivery environment the start of Semester 2 (July) the Manager, Southern Cross Online attended a number of School staff and Board meetings to let staff know more about the process and set the transition into the wider context of the online direction in which the University was moving. The Manager was also the executive officer of the Online Review and Coordinating Committee (ORCC) a sub group of the University Executive and regular reports were submitted to this body.
Staff-wide emails were circulated at various milestones to inform the University community of the progress of the transition the BbCI and raise awareness of the changes to the student portal and access to the online units. Members of the Southern Cross Online and the Teaching and Learning Centre were invited along to School planning days to present information about the new online environment. The process of setting up the BbCI liaison person in each School was an effective opportunity for discussing the impact of the changes in the online environment. An online support group (a cross-section of staff from various Schools and support areas) met on a monthly basis and was an important mechanism for exchange of information and for troubleshooting issues relating to the transition process.
In terms of the five monitoring and reporting activities documented at the planning stage (Section 2.6), each was achieved as planned with activity four being subsumed into activity 2.
Although a major version upgrade in the software appeared during the period of the transition, a conscious decision was made to remain with a single version at least for the period of transition. Upgrading to a new version is in itself a transition process and needs to be planned for accordingly. A decision as whether to upgrade is a complex process and should be undertaken using formal evaluation procedures.
A Tier 1 - Technical Evaluation of the Bb 5 Level I product was conducted by the online technologies team as step one in the evaluation process of the version upgrade. Areas under evaluation included the ability of the software to fit in with the University's overall technical strategy. This included a requirement for Oracle8 database support; the ability to integrate with student administration management system for enrolment details and the ability to utilise the existing technical infrastructure without requiring additional hardware or software. Tier 2 - User Acceptance testing follows a successful Tier 1 testing.
The technical evaluation resulted in the recommendation to retain the current and stable CourseInfo 4.10 courseware until such time as a stable version of Bb 6 Level 1 is released and evaluated. The evaluation revealed there were no significant benefits to upgrade from a technical and administrative perspective. Additionally, feedback from other institutions that have upgraded to Bb 5 Level 1 indicate that there are still significant issues to be resolved. Tier 2 testing was not conducted given the results.
As Blackboard has announced the impending release of Bb 6 which is scheduled to be released in Australia mid-2001 after a significantly more rigorous testing process than Bb 5 prior to its release, the technical evaluation process will re-commence with Bb 6.
Did we achieve our objectives? Overall, the transition has run smoothly and we have achieved the majority of objectives we set ourselves at the beginning of the process. BbCI is in place as the centrally supported online learning system. Student feedback indicates that the environment is an easy-to-use interface, and the integrated personalised portal has enabled all enrolled students who use the Internet environment to take advantage of the functionality provided.
The extent of success has highlighted a range of issues which although not directly related to the transition, certainly impact on the effective uptake of the technology, for example, constraints to access for students and the cost implications for ISP connections.
The training and support services have proved to be a successful mechanism to assist staff content developers and deliverers. Over two hundred and fifty staff have this year attended the start-up sessions and these will continue to be run as long as they are needed. The sessions were restricted to five participants and this has been very effective for building confidence and establishing a rapport with the users. The allied email address has been a core means of rapid communication to solve problems and establish units.
A stable and reliable server environment has been achieved with a few sleepless moments during the year. As with all new technologies there was a steep learning curve and providing an online environment on a scale that far exceeded the initial plan has been a major challenge. As with all risk management, it is important to assume that crises will occur, thus the need for a response plan is imperative. Responsive communication was able to contain user frustration when things did go wrong, and in the long term, the fact that the users were treated as partners and kept informed has proved effective.
Formal quality assurance mechanisms are easy to let slip, but the regular monitoring of progress, the requirement that ownership for each component project/activity be clearly assigned, and the speedy response to crises when they arise and formal postmortems all provide valuable improvement capability.
The particular challenges? Off the shelf commercial package are highly unlikely to ever meet all user needs and manufacturers need to remain responsive to problems/ limitations experienced by the user community. If the problems/limitations become real impediments which are not rapidly addressed, the user community will pressure to move on to another package or opt to create their own shell environment.
From the lessons we have learnt about changing our WBCMS we have identified the following key points which may be useful to others encountering the challenges of transition:
Orientation sessions will continue as a first level of institution-wide promotion and awareness. Staff members who want hands-on skills will continue to be provided with training. A third level of support will be provided when Schools decide to engage in a major Web-based course development and will be undertaken in close collaboration with staff in the Teaching and Learning Centre.
Increasingly, the WBCMS itself will be used to attract users and market the features of the system. The purchase of a second BbCI license has enabled the development of a 'showcase environment' which will contain demonstration units, and promotional materials. Located on the University's public Web site, this showcase will be available to staff, students and the general public.
As the current version of BbCI will only be supported by the manufacturer for two years after the release of the newest version, transitions to newer versions are constantly on the agenda. Evaluations of each version will need to be undertaken and the decision made as to if, and when, a new version is implemented.
As the University's management systems progressively come online, there will be an increasing demand for the WBCMS to seamlessly integrate with these associated business systems, for example, the need to integrate student enrolment and fee-paying activities into a single Web-based environment.
Based on the assumption that Web-based and associated online technologies will continue to experience rapid expansion and maturation and progressively find better solutions for an increasingly sophisticated user base, the next transition will constantly be 'just around the next bend in the track'. A constant cycle of transition, implementation, evaluation is the reality.
Ellis,A. & Sawkins,S. (2000) " From Exploration to Consolidation: Ten Years of the Web at Southern Cross University", in Hall,R., Li.,J, & Rubin,E. (eds) NAWeb2000, Proceedings of the Sixth International North American Web-based Learning Conference, University of New Brunswick: Fredericton. pp143-148.
Patterson, K., Ellis, A. & Brice,D. (2000)" Client Versus Browser: A Case Study from Southern Cross University", in Wallace, M., Ellis,A. & D.Newton (eds) Proceedings of the Moving Online Conference, Southern Cross University Press: Lismore, pp190-202.
Sawkins, S. & Archer, F. (1999)" Designed for Online: Making use of the Internet to enhance studentsÕ learning environment" in EDUCAUSE Australasia Conference Sydney, 18-21 April, 1999 CD-ROM proceedings
Online Strategic Plan (1999) Southern Cross University Online Strategic Plan, Unpublished internal report.
Sue Sawkins, Allan Ellis, Schelly Gardner © 2000. The authors assign to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.