f29380 - university of western australia · f29380 the university of western australia 4 august...

F29380

The University of Western Australia

4 August 2011 MEMBERS OF THE eLEARNING AND LEARNING SPACES STANDING COMMITTEE Director of Centre for Advancement of Teaching and Learning (W/Professor Denise Chalmers) – Chair Nominee of the Executive Director, Finance and Resources (Ms Rowan Maclean) Nominee of the University Librarian and Director of Information Management (Ms Catherine Clark) President of the Guild (Mr Tom Antoniazzi) Associate Dean (Teaching and Learning) (Faculty of Architecture, Landscape and Visual Arts), Mr Philip Goldswain Associate Dean (Teaching and Learning) (Faculty of Arts, Humanities and Social Sciences), Dr Neil O’Sullivan Associate Dean (Teaching and Learning) (Faculty of Life and Physical Sciences), Dr Peter Whipp Associate Professor Mark Pegrum, (Graduate School of Education) Mr Brian Poleykett (Applications Manager) (Information Services) BY INVITATION (STANDING INVITEE) Ms Rebecca Cameron, Manager, (Project Manager, Architecture and Design, Strategic Project Management) (Facilities Management Directorate) Asst/Professor Shannon Johnston, Higher Education Development (eLearning) (Centre for Advancement of Teaching and Learning) BY INVITATION Ms Yvonne Button, Senior Trainer/Educational Developer (Centre for the Advancement of Teaching and Learning) Mr Steve Howe, Project Manager, Policy and Planning (Information Services) OBSERVER Mr Maxwell Keeble, Administrative Officer (Academic Policy Services)

eLEARNING AND LEARNING SPACES STANDING COMMITTEE MEETING – TUESDAY 9TH AUGUST 2011

This is to confirm that the next meeting of the eLearning and Learning Spaces Standing Committee will be held from 10am – 11.30pm on Tuesday 9th August 2011 in Winthrop Tower, meeting room W1. Part 1 of the agenda is to be dealt with en bloc by motion of the Chair. There are no items in Part 2. Part 3 is for discussion. A member may request the transfer of an item from Part 1 to Part 3. Jan Cardy Executive Officer

2

A G E N D A

WELCOME The Chair will welcome members and, in particular, Ms Catherine Clark as a new member of the committee as nominee of the University Librarian and Director of Information Management. Also welcome back to Mr Philip Goldswain, ALVA representing the University’s Teaching and Learning Committee for Semester 2. Welcome to Yvonne Button, CATL and Steve Howe, IS to join the discussion regarding item 7 and Maxwell Keeble, APS as an observer. APOLOGIES The Chair will record any apologies. Members are reminded that apologies should be forwarded to the Executive Officer prior to the meeting as this may have an impact on the Committee proceeding inquorate. DECLARATIONS OF POTENTIAL FOR CONFLICT OR PERCEIVED CONFLICTS OF INTEREST The Chair will invite members to declare potential for conflict or perceived conflicts of interest, if applicable, with regard to items on the agenda. 1. MINUTES – REF: 29380 Confirmation of the minutes of the eLearning and Learning Spaces Standing Committee meeting held on Monday 28th March 2011. Minutes are located on the committee’s web page http://www.teachingandlearning.uwa.edu.au/608310 2. ITEMS/BUSINESS IN PROGRESS – REF: F28401, F22828 Members are asked to note the following items as ‘business in progress’.

No ITEM/BUSINESS IN PROGRESS

ACTION RESPONSIBLE STATUS

A

F28401 Proposed Framework for Decisions regarding Adoption of New Technologies at UWA

Terms of Reference 1: Formulation of an evidence-based framework for developing protocols regarding adoption of new technologies at UWA at both the faculty and central levels.

Mr Brian Greene, Associate Director, Policy and Planning Information Services

In progress – due June 2011

B F35723 The Built Learning Environment

Teaching Fellowship Project Ms Rebecca Cameron In progress – Final paper due

C F33728 Learning Space Evaluation

Prepare final paper Ms Rowan Maclean Ms Rebecca Cameron

In progress - Final paper due

D F23981 Capital Works Programme

Circulate summary of projects

Ms Rebecca Cameron Ongoing

E F33224 Campus Plan 2010

Progress report on Campus Plan 2010

Ms Rowan Maclean

Ongoing

http://www.teachingandlearning.uwa.edu.au/608310�

3

F F9547 ELearning Strategy at UWA

Development of a draft eLearning Strategy

Chair, W/Professor Denise Chalmers

In progress

G

F33728 Impact on learning spaces of NC2012

Monitoring of issues associated with learning spaces as they develop within the context of NC2012

Chair, Professor Denise Chalmers

Ongoing

PART 1 - ITEMS FOR COMMUNICATION TO BE DEALT WITH EN BLOC

3. THE UNIVERSITY’S LECTURE CAPTURE SYSTEM (LCS) – UPDATE FROM CATL – REF:

F36668 The attached report (Attachment A) provides an update on the University’s Lecture Capture System (LCS) usage for semester 1, 2011. For noting 4. OECD/CELE's DESIGNING FOR EDUCATION : COMPENDIUM OF EXEMPLARY

EDUCATION FACILITIES 2011 – REF: F1123 For members information the ‘Designing for Education: Compendium of Exemplary Facilities 2011’ will be released on 29th September 2011. The publication will showcase over 60 recently built or refurbished educational facilities from 28 countries which, collectively, illustrate state-of-the-art design in this field. Each project will be lavishly illustrated with colour photos, plans and descriptions. Further details on the publication, including how to purchase, can be found at www.oecd.org/edu/facilities/compendium For noting

5. eLEARNING & LEARNING SPACES STANDING COMMITTEE EXECUTIVE OFFICER – REF:

F29379 For the Committee’s information, Ms Sally Jackson (Academic Policy Services) will be taking over the role of Executive Officer to this Committee until the end of the year. Please don’t hesitate to contact Sally with any issues regarding the eLearning and Learning Spaces Standing Committee [email protected] For noting

PART 2 - ITEMS FOR DECISION EN BLOC No items

http://www.oecd.org/edu/facilities/compendium�

mailto:[email protected]�

4

PART 3 - ITEMS FOR DISCUSSION 6. PROPOSED FRAMEWORK FOR DECISIONS REGARDING ADOPTION OF NEW

TECHNOLOGIES AT UWA – REF: F28401

In the June circular agenda, the Chair requested that members consider the ‘Evaluation of New Learning Technologies’ report prepared by Mr Brian Greene. Feedback has now been received and incorporated into a revised report for consideration (Attachment B). By way of background, in 2009 the Technical Coordination Group (TCG) discussed the issue that the University does not have a formal process for reviewing and adopting new learning technologies and that this can be an issue given that senior academic and professional staff are periodically approached by firms promoting their educational technologies and other IT-related products. In 2010 the eLearning and Learning Spaces Standing Committee requested the development of a framework for decisions regarding the adoption of new technologies at UWA at both faculty and central levels. For discussion and endorsement 7. UWA LEARNING MANAGEMENT SYSTEM (LMS) IMPLEMENTATION PROJECT 2011-2012 –

PROGRESS SUMMARY REPORT – REF: F28027

Plans and reports prepared by Dr Shannon Johnston, UWA Project Manager (CATL) are attached (Attachment C) to inform members of the progress towards the UWA LMS implementation. Further information regarding the implementation is also available from the website http://www.catl.uwa.edu.au/elearning/new_lms For discussion 8. ITEMS IN PROGRESS – UPDATES The Chair will invite members to provide a brief verbal update on items in progress, including;

Rebecca Cameron to provide feedback on her attendance at the University Planning and Design Summit (June 2011)

Catherine Clark – brief update on the Communication and Research Skills (CARS) project (replacement for IRIS).

For information 9. NEXT MEETING The next meeting of the eLearning and Learning Spaces Standing Committee will be held on Tuesday 11th October 2011 from 10.00am – 11.30am and will be held in Meeting Room W1, Winthrop Tower.

http://www.catl.uwa.edu.au/elearning/new_lms�

A1

Lecture capture (Lectopia) report Semester 1, 2011 In Semester 1, 2011 (from 28th February to 24th June 2011), 361 units utilised the Lecture Capture System (Lectopia). 291 of these units allowed students both to stream and download/podcast the captured lectures, whilst the remainder of units only allowed students to stream the captured lectures. All units, except 39, use the Learning Management System (LMS, currently WebCT) as the access point for delivering captured lectures to students. Table 1 presents the number of units that utilise the Lecture Capture System, by year level, by for each faculty.

Table 1: Units utilising Lecture Capture by Year, for each Faculty

*Level 0 Level 1 Level 2 Level 3 #Level 4 + Total AHSS 28 53 5 1 87 ALVA 1 2 3 BUS 11 17 11 10 49 ECM 9 18 17 18 68 EDUC 1 1 3 5 LAWS 3 3 13 3 22 LPS 8 15 17 13 53 MDHS 3 9 12 13 37 NAS 4 11 16 1 32 SIS 5 5 Total 5 68 129 91 28 361

Please Note: * = These are foundations units e.g. AUST0071 # = These are honours and post graduate units e.g. PODI8511, CTS4240. How faculties utilise UWA lecture capture facilities varies. The Faculty of Arts, Humanities and Social Sciences (AHSS) has the largest number of units which utilise lecture capture, followed by Engineering, Computing and Mathematics (ECM), Life and Physical Sciences (LPS) and Business (BUS). In general, lecture capture is used more in Levels 2 units than in other year levels. In AHSS lecture capture is utilised most heavily in Levels 2 and 1 units and ECM utilises Lecture Capture the most for Level 4 and Postgraduate units. The School of Indigenous Studies (SIS) utilises lecture capture for the smallest number of units, all foundations units. In terms of location, whilst all units that have captured lectured are offered on the Crawley campus, 30 of these are also offered via the Albany Centre, 1 is also offered in Singapore and 4 are offered in Hong Kong. Table 2 presents the number of units offered in Albany, by each faculty.

Table 2 Units Offered in Albany, by Faculty.

Faculty TotalAHSS 10ALVA 0BUS 5ECM 0EDUC 0LAWS 0LPS 6MDHS 0NAS 5SIS 4Total 30

A2

AHSS (10) has the largest number of units offered via lecture capture through the Albany Centre. This is closely followed by the Faculty of Life and Physical Sciences (LPS) (6) and the School of Indigenous Studies (SIS) (4). Table 3 presents the total number of individual lectures captured, organised by recording format.

Table 3: Number of Individual Recordings, by Recording Format

Recording Format Number (Percentage) Audio Only 869 (9%) VGA (Audio & 1 Screen Captured/Visualiser) 7,998 (86%) Other (Audio & 2 Screens Captured/Video) 479 (5%) Total Recordings * 9,346

Please Note: * = includes UWA Standard Semester and Special Event (UWA or non-UWA) recordings Approximately 9,300 individual lectures were captured in Semester 1, 2011 with an average of 730 recordings per week. 86% of recordings were VGA (i.e. audio and 1 screen captured - PowerPoint or Visualiser), whilst 9% were Audio Only and 5% were Other (Audio and 2 Screens Captured or Video). Table 4 presents the total number of accesses to Semester 1, 2011 recordings, organised by delivery format.

Table 4: Number of Accesses, by Delivery Setting

Delivery Settings Hits (Percentage) Download 389,201 (29%) Streaming 514,198 (38%) Podcast 449,000 (33%)

Total hits * 1,352,399

Please Note: * = includes UWA Standard Semester and Special Event (UWA or non-UWA) recordings The presentations captured during Semester 1, 2011 had a total of 1,352,399 accesses. Access via streaming format (38%) is higher than download and podcast format. This is due to some staff electing not to allow students to download or podcast their lectures. Table 5 shows the number of captured lectures, organised by the number of recording (streaming and download) accesses for each faculty.

Table 5: Captured Lectures, Number of Accesses and Average Access per Lecture, by Faculty

# Captured Lectures

Number of Accesses

Average Accesses Per Lecture

AHSS 1,575 79,586 50 ALVA 47 6,511 138 BUS 1,065 199,990 187 ECM 2,122 203,835 96 EDUC 55 1,735 31 LAWS 589 82,484 140 LPS 1,485 181,559 122 MDHS 830 71,214 85 NAS 916 62,526 68 SIS 114 1,662 14

Please Note: # = does not include Special Event (UWA or non-UWA) recordings

A3

Of the individual lectures captured during Semester 1, 2011, ECM (2,122) captured the most, followed by AHSS (1,575), LPS (1,485) and BUS (1,065). ALVA (47), EDUC (55) and SIS (114) captured the least number of lectures. However, in terms of accesses per captured lecture interestingly BUS (187) has the most, followed by LAW (140) and ALVA (138).

Summary of Lectopia usages

# of units utilising lectopia # of captured lectures # of accesses

S1, 2010 S2, 2010 S1, 2011 S1, 2010 S2, 2010 S1, 2011 S1, 2010 S2, 2010 S1, 2011

AHSS 71 80 87 1,388 1,553 1,575 69,121 67,104 79,586

ALVA 1 2 3 25 27 47 3,185 6,617 6,511

BUS 44 58 49 1,050 1,192 1,065 197,474 149,889 199,990

ECM 52 67 68 1,849 2,209 2,122 167,032 190,476 203,835

EDUC 4 1 5 53 5 55 1,321 948 1,735

LAW 21 19 22 567 418 589 78,417 68,622 82,484

LPS 49 53 53 1,788 1,659 1,485 169,112 130,551 181,559

MDHS 22 27 37 484 626 830 18,370 48,899 71,214

NAS 36 25 32 1,147 506 916 59,942 19,601 62,526

SIS 4 5 5 92 121 114 708 762 1,662

Total 304 337 361 8,443 8,316 8,798 764,682 683,469 891,102

EVALUATION OF NEW LEARNING TECHNOLOGIES TRIM File Reference: F F28401

FILE PATH ON SERVER: S:\Elearning And Learning Spaces Standing Committee\Elearning 2011\08-11 (Aug)\Attachment B

DOCUMENT STATUS

X Draft Ready for Review Final

DOCUMENT MODIFICATION HISTORY

Version Number

Primary Author(s) (name and position) Description of Version

Date Completed

Provided To

0.1 Mr Brian Greene Draft version – Evaluation of New Learning Technologies

June 2011 eLearning and Learning Spaces Standing Committee

0.2 Mr Brian Greene Draft version – Evaluation of New Learning Technologies – incorporating changes recommended by the Committee

Aug 2011 eLearning and Learning Spaces Standing Committee

DOCUMENT APPROVAL

Approved By (name/position of approver) Signature Date

B1

Evaluation of New Learning Technologies

Background

In 2009 the Technical Coordination Group (TCG) discussed the issue that the University does not have a formal process for reviewing and adopting new learning technologies and that this can be an issue given that senior academic and professional staff are periodically approached by firms promoting their educational technologies and other IT‐related products.

In 2010 the eLearning and Learning Spaces Standing Committee requested the development of a framework for decisions regarding the adoption of new technologies at UWA at both faculty and central levels.

This paper is a proposal for such a framework.

Purpose

Based on discussions with the TCG and the eLearning Technologies Adoption Working Party, this document recommends a formal process for reviewing and adopting new learning technologies with the aim to:

Determine whether a solution can be supported at an institutional level with benefits of

availability, sustainability, reliability and economies of scale

Ensure minimum standards for performance, levels of availability and support at the level at

which it is implemented

Minimise duplication

Avoid the use of expensive products where cheaper options are suitable if more than one

product with the required functionality and suitable specifications is available for the UWA

context, and

Control expenditure while encouraging development or trials of new systems

Evaluation Overview

Criteria Any learning technology

Any learning technology to be adopted University‐wide

Service Levels

Availability, performance, support arrangements, reporting and review

Must be met Must be met

Educational Technology Guidelines

Provide CATL with a rationale for use including educational


B2

benefit or need being met and fitness‐for educational purpose. Review of risk, cost, benefits and duplication of existing services

Supportability

Review of architecture, technologies, policies, standards, disaster recovery, testing and support arrangements.

Must be met

Accessibility

Access and equity will be considered when making decisions on new or upgraded learning technologies.


University Facilities

The associated physical implications of the introduction of new learning technologies should be considered. These include building and/or facility adaption costs.


Service Levels

All learning technologies – whether used University‐wide or not – must meet these minimum requirements for service levels.

Availability

SL 1.1 Student‐facing or public‐facing aspects of the learning technology shall be designed for 99.99% availability – less than 1 hour of downtime per year, less than one minute of downtime per week.

MANDATORY

SL 1.2 Administrative access to the learning technology shall be designed for 99% availability

DESIRABLE

SL 1.3 Availability of the services shall be monitored and logged MANDATORY

SL 1.4 In the event of a disaster, the system administrator must be able to restore service within 24 hours

DESIRABLE

Performance

SL 2.1 The system shall respond to requests within half a second MANDATORY

SL 2.2 For web‐based systems the average render time shall be within 3 seconds

MANDATORY

SL 2.3 For web‐based systems the render time shall be within a 6 second maximum

MANDATORY

Support

SL 3.1 There shall be defined contacts for all support requests (incidents, requests for change, service or information requiring action)

MANDATORY

SL 3.2 Support requests must be logged MANDATORY

B3

Reporting

SL 4.1 If the service falls outside, or is likely to fall outside the levels described, this must be immediately reported to the business system owner.

MANDATORY

Review

SL 5.1 These service levels shall be reviewed at least every 3 years DESIRABLE

Educational Technology Guidelines

All learning technologies – whether used University‐wide or not – must meet these educational technology guidelines.

Inform

EG 1.1 The system owner shall document the expected costs and benefits of the technology, and whether there are any known UWA services with similar functionality

DESIRABLE

EG 1.2 The system owner shall provide a ‘fit‐for‐purpose’ rationale for the system as an educational resource and the educational need it is addressing.

MANDATORY

EG 1.3 The system owner shall advise the eLearning and Learning Spaces Standing Committee of the new technology, providing the document produced in EG 1.1

MANDATORY

EG 1.4 The system owner shall advise the Technical Coordination Group (TCG) of the new technology, providing the document produced in EG 1.1

MANDATORY

EG 1.5 The system owner shall ensure a risk assessment has been conducted to review:

The confidentiality of University and student data if applicable

The schedule, duration, and features of upgrades, and what ability the University has to influence these

The need for customisation or integration with existing University systems, including the cost, complexity and risk of this effort

If an external vendor is involved, the processes and contractual obligations for day‐to‐day communication, issue management and escalation

If an external vendor is involved, the University’s ability to exit from the arrangements, and the vendor viability

MANDATORY

EG 1.6 Appropriate controls must be put in place to manage the risks identified in EG 1.4

MANDATORY

Supportability

All learning technologies that are supported centrally or used University‐wide must meet these minimum requirements.

S 1.1 A technical architecture review must be completed by Information MANDATORY

B4

Services to ensure that:

The technology set is supportable

The solution is compliant with University policies and standards

The solution is scalable for University‐wide use

S 1.2 Appropriate Disaster Recovery measures must be in place MANDATORY

S 1.3 There must be an adequate test environment, and appropriate testing procedures

MANDATORY

S 1.4 There must be trained staff, and funding available for ongoing support MANDATORY

B5

LMS Implementation Project 2011‐ March 2012

PROJECT PLAN Document control:

Filename: LMSPrj_PrjMgmt_ProjectPlan_v0.1_20June2011_SJ.doc

Saved on: 21/06/2011 9:42 PM

Author: Shannon Johnston

Version: 0.1

Distribution: Denise Chalmers, Yvonne Button, Mary Davies, Steve Howe

Status: Draft For Review Final

Project Board membership: (if appropriate)

Project Executive:

.Denise Chalmers, Mary Davies

Manager: Shannon Johnston

Specialist coordinators

Yvonne Button, CATL Project Manager

Steve Howe, IS – Systems Integrations

Lisa Cluett, Student Services – Student Strategy

Partner Specialist Netspot PtyLtd

Victor Herrera (project manager), Mark Drechsler (Lead Consultant), Luke Tucker (Lead technical consultant), Mike Fardon (Account Manager)

1 LMSPrj ProjectPlan v0 2 04Aug11 SJ Page 1 of 16

C1

Project overview This project comprises a number of independent elements that result in Moodle being deployed as UWA’s learning management system (LMS) with active users. The core tasks are

Prepare the Moodle environment, including migrate WebCT unit content into Moodle units

Prepare staff and students for change and to being users of the Moodle environment

Develop ongoing staff support and community engagement in effective eLearning through the use of Moodle and other systems and tools

Note: simultaneously an LCS (lecture capture system) project for pilotting, testing and implementing Echo as a replacement for Lectopia is being conducted. See the Echo Project Plan for further details.

The LMS (Moodle) Project comprises several subprojects:

Systems Integrations Project: planning, design and development for integrating the LMS with a range of university systems. The integrations work is primarily the responsibility of systems teams at UWA and Netspot, the Host, in collaboration with CATL for determining requirements.

Moodle Configurations Project: decisions regarding the preparation of Moodle as UWA’s environment is the responsibility of CATL, with development work conducted by NetSpot. The creation of the UWA Moodle site (including development, testing, staging, and production sites) by NetSpot.

Training and Migration Project also called the Change Project – preparing staff for being able to develop units and use Moodle for teaching and learning, and ensuring students have appropriate support and training.

Plan Description

Timeframes Go live of Moodle is from January 2011, with complete use from commencement of semester 1, 2012. In order to do this, these broad tasks and timeframes are required:

30 June 2011 Creation of UWA’s Moodle environments for development, staging, testing, and production.

31 August 2011 Creation and development of UWA Moodle environments (by Netspot), including systems integrations with UWA systems (collaborative between Netspot and UWA, in particular Information Services) and configuration of Moodle, and design of Moodle units/templates (Netspot in discussions with UWA, CATL).

September 2011 and Oct/Nov 2011 Migration of all LMS units from WebCT to Moodle (by Netspot) with preparation of units for go live (CATL responsibility). Preparation support can continue until Semester 1, semester 2, and on.

From September 2011 Moodle training for all staff in unit creation and development, and staff and students in using Moodle.


From July 2011 Communication of project progress and Moodle development across the university to manage the change and support community awareness

C2

From November 2011 Communication with students regarding the change, support materials prepared, with training implemented from January.

People resources The required people resources are listed in this table:

ROLE Task

LMS/LCS Board To monitor progress, approve core decisions and approve changes to the project plan.

UWA LMS/LCS Project Manager Monitor and manage LMS and LCS project, Liaise with Netspot, ensure contractual obligations are met.

LMS Admin Officer Support the LMS/LCS and CATL Project Managers with administrative aspects of the project

CATL Project Manager (incl. LCS Project management)

Manage and implement configuration, migration, training, and on-going community strategy for the LMS, and implementation of Echo System as the new LCS.

Student Strategy Coordinator Ensure conduct of communication about LMS change, resource development and training for students and student support

LMS / LCS Project team: Education Developers Computer support

Design, develop, implement migration, training, support/resources, community strategies, and determine and test configurations Staff to maintaint support for WebCT and Lectopia until Semester 1, 2012, and support appropriate aspects of the

Integrations Project Manager Manage and monitor the development of systems integrations for the LCS and LMS, drawing on systems technical staff resources into the process as required, and liaising with NetSpot

Technical/systems teams Design, develop and test integrations

Host Company – Netspot Support UWA’s migration to and use of the new LMS, develop integrations within Moodle, create and develop UWA”s Moodle environments, Host Moodle

WebOffice Design of themes for Moodle at UWA.

Reference group; Trial and development support group (Early Adopters)

Volunteer staff for working with CATL on preparing for migration and training, and for actively seeking feedback on configurations for the LMS project.


C3


Project Management Structure

UWA LMS Business Owner and Project Owner

NetSpot Account Manager

UWA Project Manager Netspot Project Manager

Configurations and Change: (training, migration) Project Manager (CATL)

Lead Consultant

eLearning team Configurations team

Systems Integrations Project Manager (IS)

Lead Technical Consultant

Systems teams Technical teams

Project structure – Learning Management System (Moodle)

The UWA LMS Implementation project has 5 stages: Creating the LMS environment, Developing integrations, Configuring the environment, Migration of content from WebCT to Moodle, and Training of staff and students (including development of support materials). Developing community and engaged users is an underlying theme to this project. The decommissioning of WebCT is a side related project.

Phase Title of Phase Boundary (completion) Tasks

A Creating LMS environments NetSpot

Development, test, staging and production environments are ready

1. Create environments 2. Load test

B Developing integrations UWA systems w/ NetSpot (some vendors)

UWA systems are integrated with Moodle

1. Business analysis 2. Systems Architecture 3. Design all integrations 4. Develop and test

C Configurations NetSpot (UWA direction)

Moodle is developed to look and work as required.

1. Configurations planning 2. Implementation and testing

D Migration UWA CATL

All WebCT unit content migrated to Moodle, staff who want to reuse content can.

1. WebCT units prepared for migration

2. Unit content migrated to a Moodle holding unit

3. Staff supported in developing Moodle units for use.

C4

E Training UWA CATL

Staff have had the opportunity for hands-on training, and support materials are available.

1. Design and develop training sessions, resources and online support materials.

2. Technical support, admin staff, academics, students, and others attend Moodle workshops

3. Other training opportunites are provided, online materials are available, Moodle support site is developed.

F Community UWA CATL

Staff are informed about the project process and progress, are able to be involed in UWA Moodle decisions.

Reference group, early migrators. LMS Project website. Presentations at Faculty Boards or T&L Committees. All-staff information sessions. Other as arise.

G WebCT WebCT decommissioned at UWA.

1. extend license for a further year 2. establish and implement de-

commissioning process

Prerequisites Staff with appropriate skills must be available – as per the list of human resources above. Crucial are the LMS Project Managers, a Systems Integratino Project Manager, a CATL Project Manager, CATL team members for migration/training and adequate and appropriate staff across the UWA systems. Essentially, it is essential that UWA commits staff with skills and availability to the project and its short time frame.

The LMS Hosting company, NetSpot, for developing the Moodle instance, integrations within Moodle, and supporting the Implementation process.

As Moodle is hosted at NetSpot, UWA does not need special software or hardware, other than the means to keep adequate archives of the site in a secure and retrievable location.

External dependencies The availability of NetSpot human resources for developing Moodle, supporting UWA’s implementation processes, and on-going support, as well as, adequate and reliable hardware and software for Hosting UWA’s use of Moodle are crucial external dependences.

Some systems are owned by other vendors require integration plugins with Moodle 2.0 and the timing, adequacy and cost of requiring the integrations in a particular time frame, e.g. Echo system (Echo360), CMO/Hive (Exact), Question Mark Perception. Some external integrations can be managed by NetSpot.

Ensuring staff take the opportunity for migration support and training, and being informed of change and thus prepared for it.

Planning assumptions An adequately trained, skilled, experienced Project Manager is available to manage the whole project process


C5

Project managers for the subprojects – Systems integration, and Configurations / Change are available, and have the capacity for the work assigned to them and to have skill, training for managing the subprojects.

Netspot, hosting company, has the capacity, skill and processes for adequately supporting the implementation process, for their role in the preparation of Moodle for implementation, and to Host the UWA Moodle environments. NetSpot has adequate hardware and development capacity.

Adequate staff within CATL and Information Services (and other systems areas, e.g. Student systems in Student Services) are available and capable of conducting the work tasks required, when required, to a short time schedule.

Lessons incorporated This is the first project of its kind for CATL with a significant project management process in place. It appears to be the first with detailed planning and documentation. Lessons learned from past projects is the inadequacy of appropriate planning, preparation, scheduling and management of the project are necessary to ensure timely completion, that all resources are available and committed to project implementation and completion, and risks mitigated. This project will initiate project closing procedures with lessons learned in order that future projects can learn from this process.

Monitoring and control From this plan, a more detailed workbreakdown structure and schedule will be developed. The Project Manager will review and monitor progress against the tasks and schedules, and report regularly to the Business and Project Owner. At this point, risks and issues can be discussed and strategies to mitigate against or resolve them can be devised.

Regular, weekly team meetings will be held between the LMS Project Manager and the project managers (and other staff as required) regarding project decisions, progress, issues and risks. The project managers asked to supply a simple status update report (intended tasks, progress on tasks, risk level, other comments). The project managers are

CATL project manager (Configurations, Migration – Training, Community)

Systems Integrations project manager

Student strategy coordinator

Netspot Project Manager

In these meetings, issues and risks can be mitigated. Next steps can be stimulated. Large risks can be identified and solutions sought or escalated.

The LMS Project manager will also be involved in initial, key and big-picture meetings regarding design, development, testing and closure of key tasks and phases of the project. For example, business analysis and systems architecture design meetings for the integrations project, initial configurations discussions with Netspot, and so on. This allows the Project Manager to be aware of issues, progress, and the project developments, and to keep an overall picture of the project.

The Netspot and UWA Project Managers act as a conduit for information, decisions, progress and other project interactions in order to monitor activity, and ensure appropriate and adequate project communication and progress between the institutions. Regular meetings, email and skype communication, and a document of requests made between the two Managers and their institutions will help to keep track of actions. From


C6

time-to-time, NetSpot staff and UWA staff will liaise directly with NetSpot to expidite detailed discussion and decision-making, in this instance the Project Managers will be kept aware of communication and conversation outcomes (e.g. by cc email messages, or providing discussion notes)

Netspot has allocated a Project Manager and Account Manager to the implementation and on-going Hosting process. The Account Manager is oversees the project, is not involved in the day-to-day running of the project, but can be contacted with regards to big-picture developments, and major issues that require escalating.

Budgets A budget summary is provided here. For the full budget, expenditure and procurement plan, see the Finance Plan. The finance plan includes expenditure record management and monitoring processes.

Budget Componets Staffing (as listed above), in some cases this is realized as back-filling existing staff positions

NetSpot costs for hosting, development and implementation support

WebCT licensing costs until decommissioning

Echo pilot costs

Staff equipment (computer equipment)

Professional and Consulting Services

Events

Resources

Hardware for Echo system

Budget Componets and costs Source document: Final LMS Budget Revised 2011-13 (last updated 24-05-11JF)

** NB this budget is pre-project estimate and has since been revised, see Finance Plan

Item 2011 2012 2013

Managed Hosting and Licence Fees (ongoing cost)

$502,000 ($213,400 already funded)

$415,000 $435,000

Vendor Costs for Implementation $170,000

UWA infrastructure and technical management costs (ongoing)

$150,000 $150,000 $150,000

Staffing Costs for transition / migration / training

$822,000 $872,000 $544,000

Software development and integration $248,000 $210,000

Other Project Costs $80,000 $81,000 $56,000


C7

TOTAL (excluding allocated funds) $1,759,000 $1,728,000 $1,185,000

Grand Total $4,672,000

Tolerances Tolerance refers to the permissible deviation above and below a plan’s estimate of time, cost, scope and quality without escalating the deviation to the next level of management.. Tolerance is applied at project, stage and team levels.

Time, Cost, Scope, Quality

Project

Stage

Team

Products/Deliverables

A hosted learning management system – Moodle The product will be the LMS - Moodle prepared, developed, and fully integrated with UWA systems and hosted at and by NetSpot, with WebCT content transferred to the environment. The Business Owner is CATL (Director, Winthrop Professor Denise Chalmers), with final approval and authorization of the Moodle environement for UWA’s use. The Integrations Project Manager is responsible for the seamless integration of Moodle with the identified UWA systems, with the Director of Information Services authorizing and signing off, and ultimately the LMS Project manager and the Business owner.

A lecture capture system – Echo The product is Echo system purchased and implemented across the University’s current lecture recording venues, and integrated with the UWA systems, for staff to schedule, and integrated into the LMS. The Business is CATL, with final approval and authorization of EchoSystem for the Moodle environment.

Schedule – Key Milestones

Key project milestones are

End June 2011: creation of UWA Moodle environments (Netspot)

End July 2011: preparation of project planning documentation (Various project managers)

End July 2011: Configurations document (UWA CATL)

Mid August 2011: UWA Moodle environment configurations applied (NetSpot), including visual look (designed by WebOffice)

End August 2011: Systems Integrations (NetSpot and UWA – systems teams)

Early Sept + November 2011: WebCT content migration

From August 2011: staff Moodle familiarization sessions; staff training into developing units


C8


October 2011: student resources developed

January: pilot Moodle use ; some student training

Semester 1 2012 / Orientation week: Full Moodle use; student training From November: research and development of Priority 3 tools; development of policy and strateges

C9

Broad schedule


June July Aug Sept Oct Nov Dec Jan Feb March Level 1 Level 2 Level 3 Responsibility

Project Management

Create plans Overall project plan Project Manager

27th

Specific plans: Project Communications Finance Human Resources Risk Closure

Project Manager

27th

Systems Integrations project plan**

Integrations PrjMan

29th

Configurations project plan**

CATL PrjMan 29th

Managing change planS**

CATL PrjMan 29th

Implement plans

Monitor and manage

End Project Complete closure plan phase 1

Phase A

Phase B, C

Phase D

Phase E#1

Phase

E#2 Phase F

Creating Moodle site

Site creation Dev, Test, Stage, Prod Netspot 15th

Systems integrations *

Business analysis UWA ‐ IS 30th

Systems Architecture UWA‐IS 20th

Integrations design UWA ‐ IS 31st

Integrations development & testing

UWA‐IS 31st

Moodle integrations

Design and development & testing

Netspot 31st

* Detailed scheduling to be prepared by project manager of Integrations subproject, and by Netspot

C10


June July Aug Sept Oct Nov Dec Jan Feb March Level 1 Level 2 Level 3 Responsibility

Managing change

Moodle configurations

Develop configurations document

CATL‐eDS 27th

Apply configurations Netspot 10th

Review, test, feedback CATL eDS 31st

Development and finalisation

Netspot 31st

Migration Exploratory migration CATL / Netspot 29th

Batch 1 full migration CATL/NetspotEarly Sept

Batch 2 full migration CATL/NetspotEarly Nov

Training Early train‐the‐trainers Netspot 30th‐

1st

Intro to Moodle training CATL‐eDS Start Rpt on-going

Migration workshops ‐ batch 1

CATL‐eDS Start

Migration workshops ‐ batch 2

CATL‐eDS Jul-12

Continued training and support

CATL‐eDS

Community Staff reference group CATL‐eDS start

* Detailed scheduling to be prepared by project manager of Managing change subproject, and by Netspot

C11


Preparing for Future

Moodle community

Develop strategy for eLearning / Moodle community

CATL AsstPro eLearn w/ eDS

Develop plan for review and selection


Other integrated tools (eportfolio, conferencing, plagiarism)

Create plan for preparation and implementation


on‐going Moodle plugins

Develop on‐going strategy for identification of new plugins


create and support a UWA community group for strategy

C12

Risk and mitigation

Overview of risks

The greatest risk for this project is the timeframe given to have Moodle ready for use by Semester 1, 2012. The time frame is extremely short and does not allow for comfortable development and testing, change management, and for staff to prepare their LMS units.

Complicating factors include a range of major changes in the university environment:

1. A major change in the Degree structure of the University, commencing implementation from 2012. The implications are that staff are already facing major change in what they teach, requiring redesign of units and whole programs. The time and mental space available to also develop new units in a new online learning system is potentially compromised. Furthermore, the time needed to develop the LMS before staff can have access to learning how to use it AND developing their new LMS units is limited.

2. Major IT improvement projects across all aspects of information technology services across the university. Some of these changes have direct and significant impact with the LMS, such as in the areas of identity and access. Changes in these systems and processes are occurring at the same time as Moodle is being developed to integrate with them.

3. Moodle is structurally a very different LMS to WebCT. Staff are therefore needing to change how they conceive of the design and use of the LMS. Ultimately, staff will know how to work with Moodle and take advantage of the array of activities, tools, and resources that are available in the Moodle community; however, the initial change will be challenging for some. Furthermore, UWA lacks Moodle expertise to guide and support the LMS change process, and needs to lean heavily on NetSpot as partner support, and attempt to employ Moodle-experienced staff where possible, e.g. in Education Developers.

Mitigating against major risks

One core aspect to mitigating against risks is a strong culture and practice in collaborative project processes, with open and frequent communication, lead by organized project management.

The project management / project staffing structure is one aspect to this (see above). Regular project management meetings, as well as inclusion of project management attendance at relevant big-picture team meetings, particular in the planning and design phase.

Open communication allows for issues to be raised and processes and practices to address issues as they arise. Included in open communication is the openness to escalate matters as required for expedient solutions.


C13

Specific project risk identification

Phase Area Risk(s) Mitigation

Human resources Appropriately skilled, experienced staff are not available at the time required to perform functions required.

Communication with Project Sponsors to develop work-arounds as required

?

Host company fails to communicate or perform adequately to ensure project progress is assured, and project time, scope, quality or cost are compromised

Regular communication with appointed partner staff (e.g. project managers)

Escalation strategy with Netspot; enact strategy

Monitor tasks and responses, and act on delays

A Creating LMS environments NetSpot

Environments are not developed according to schedule

Revise remaining schedule and adjust to ensure core work is available for key milestones

B Developing integrations UWA systems w/ NetSpot (some vendors)

Delays to planning processes from UWA holds up development by Netspot

Revise schedule and timing priorities

Request staffing prioritises this project at key moments

Have non-linear approach to planningand development

Requirements create scope that is beyond time limits

Revise requirements to reduce scope, without minimizing quality for a build 1.0 environment, and keep to time limits.

C Configurations NetSpot (UWA direction)

Lack of Moodle knowledge at UWA, with inadequate support from Netspot to make decisions

Request further support from NetSpot

Document takes too much time to develop

Ensure basic functionality is assured for first development, and allow for further decision and development with testing

Document not adequately reflect University needs

Use a community Reference Group for feedback to/from Business Units.

D Migration UWA CATL

Migration of content leads to unusuable or lost content

Develop and implement strategies to support staff in preparing for migration, and backups of content.

Migration Develop a process for testing migration, and with NetSpot to

1 LMSPrj ProjectPlan v0 2 04Aug11 SJ

C14

ensure migration scripts are adequate and complete

E Training UWA CATL

Staff are inadequately trained to use Moodle

Ensure training is Central AND local to business units

A range of training phases – familiarization with Moodle, developing units, and more specific uses.

Draw on advice and request from Reference Group faculty representatives

F Change Management Staff feel inadequately consulted or prepared.

Develop and implement migration, training, communication plans to ensure

Ensure the plan is implemented centrally and at Business Unit level

Draw on Reference Group to enact plans according to Faculty needs and.

Closure

A project closure strategy will be developed. The purpose of the closure strategy is to close processes and ensure documentation and record management is complete, and the project is complete. Included in these will be evaluations of project processes and experiences with a view to identifying successful practices and lessons learned. Phase-related closure practices will occur at the completion of phases A, B, C, D, and E above.

A component of the closure will be formal evaluation procedures with stakeholders. Ethical clearance is required if the results are to be used in research publications presentations.

Related documents:

Title Author(s) Date completed

Project Communication Plan Shannon Johnston 25 July 2011

Project Finance Plan Shannon Johnston

Project Risks Plan Shannon Johnston

Project Human Resource Plan Shannon Johnston

Project Closure Plan Shannon Johnston

Echo Project Plan Yvonne Button, Silvia Dewiyanti

Systems Integrations Plan Steve Howe

Configurations Plan Yvonne Button


C15


Migration and Training Plan Yvonne Button

LMS Replacement Business Case Jacqueline Flowers 10 May 2011

Replacement of University’s LMS: Implementation Project Budget 2011-2013

Jacqueline Flowers 24 May 2011

Revision History:

Version Author(s) Description Date completed

0.1 Shannon Johnston Initial document preparation 29 July 2011

Document approval:

Project Owner Denise Chalmers

Date

Signed

C16

Functional Specification

Learning Management System Integration

Document control:

Filename LMSPrj_Integ_Functional specification LMS 1.0

Saved on 23/06/2011 2:58 PM

Author Keith Falloon / Editor: Shannon Johnston & Yvonne Button

Version 1.0

Status FINAL

Distribution Shannon Johnston, Yvonne Button, Jen Tomczak, Brian Greene

Project Board

Revision history:

Version Author(s) Description Reviewed by Date completed

0.1 Keith Falloon Initial draft 25 May 2011

0.2 Keith Falloon Changes to initial draft including remapping of the LMS unit request process

Shannon Johnston, Yvonne Button

26 May 2011

0.3 Keith Falloon Changes to draft to reflect client input Shannon Johnston, Yvonne Button

7 June 2011

0‐4 Keith Falloon Changes to reflect feedback and adjustments to requirements

Shannon Johnston

Yvonne Button

9 June 2011

0‐5 Shannon Johnston Adjustments to clarify, and reflect additional requirement to unit creation

Shannon Johnston

Yvonne Button

Keith Falloon

14 June 2011

0‐6 Keith Falloon Minor adjustments to version 0‐5 Shannon Johnston

Yvonne Button

15 June 2011

1.0 Keith Falloon Moved to final following approval from Client

23 June 2011

Related documents:

Title Author(s) Date completed

Original prepared by: Keith Falloon ; this version edited by Shannon Johnston (with Yvonne Button)

S:\eLearning and Learning Spaces Standing Committee\eLearning 2011\08‐11 (Aug)\LMS docs\2 LMSPrj_Integ_Functional specification LMS 1 0_230611_KF.doc

C17

Events Management System

Page 2

Table of Contents

1 INTRODUCTION........................................................................................................3

1.1 Problem statement, goals and objectives ....................................................................................3

1.2 In scope...................................................................................................................................................3

1.3 Outside scope........................................................................................................................................3

1.4 Business Context..................................................................................................................................4 1.5 User characteristics ............................................................................................................................4

1.6 Assumptions..........................................................................................................................................4

1.7 Dependencies .......................................................................................................................................4

1.8 Constraints ............................................................................................................................................4

2 LMS UNIT REQUEST PROCESS...................................................................................5

2.1 LMS unit request process map ........................................................................................................5

2.2 u LMS nit request process requirements......................................................................................6

2.2.1 Multiple unit creation................................................................................................................................82.2.2 Process Help ..................................................................................................................................................9

2.3 LMS unit request process functional requirements.................................................................9

3 LMS UNIT LIFECYCLE...............................................................................................10

3.1 LMS unit life cycle requirements................................................................................................. 10

4 STUDENT LIFE CYCLE ..............................................................................................12

4.1 Student life cycle requirements................................................................................................... 12

5 INTEGRATION WITH EXISTING UWA SYSTEMS .......................................................13

5.1 Callista.................................................................................................................................................. 13

5.2 Authentication................................................................................................................................... 13 5.3 s Echo ystem........................................................................................................................................ 13

5.3.1 Wireframe Echo schedule selection.................................................................................................145.3.2 Wireframe Echo appearance in LMS unit ......................................................................................145.3.3 Wireframe echo booking form ...........................................................................................................15

5.4 s Cour e materials online and HIVE .............................................................................................. 15

5.4.1 Wireframe – Course material selector ............................................................................................165.4.2 Wireframe – course materials online display page...................................................................16

5.5 Questionmark Perception ............................................................................................................. 17

5.6 Online Class Registration............................................................................................................... 17

5.7 Google mail ......................................................................................................................................... 17

5.8 Portal .................................................................................................................................................... 17

5.9 Wireframe – MyUWA LMS portlets ............................................................................................. 18

6 GENERAL RECOMMENDATIONS .............................................................................19

7 APPEN 1 DIX – LMS UNIT PROPERTIES.....................................................................207.1.1 Table 6 ‐ LMS unit properties .............................................................................................................20

8 APPEN 2 DIX – CALLISTA TABLES OF REQUIRED FIELDS............................................22

8.1.1 Table 3 ‐ Callista student information.............................................................................................228.1.2 Table 4 ‐ Callista unit information ....................................................................................................228.1.3 Table 5 ‐ Callista enrolment information.......................................................................................23

C18

1 Introduction

The goal of this specification is to describe requirements for integrating the new Learning Management System with other relevant systems in The University.

Information Services and the Centre for the Advancement of Teaching and Learning (CATL) are engaged in a joint project to deploy a new Learning Management System (LMS). CATL is the business owner and is managing the project which consists of a joint Information Services and CATL team.

This LMS will be the core delivery platform for unit subject matter effectively being a virtual supplement to physical classrooms and education processes. Due to this, the LMS will need to interact and display information from various other systems deployed throughout The University of Western Australia.

This functional specification will outline requirements and functional behaviours associated with the Learning management system project.

1.1 Problem statement, goals and objectives

A strategic goal of this project is to improve the quality of the student learning experience.

Goals of the integration component of the LMS project include:

‐ Learning management system (LMS) unit request process,

‐ LMS unit life cycle description,

‐ Student lifecycle in the LMS,

‐ Integration with existing UWA systems.

1.2 In scope

‐ Student, staff, guest authentication,

‐ Integration with:

o Callista,

o Echo system

o Course Materials Online (CMO) and HIVE,

o Questionmark Perception assessment system,

o Online Class Registration,

o MyUWA the student portal,

o Google Web mail,

‐ LMS unit request,

‐ LMS unit lifecycle management.

1.3 Outside scope

Out of scope for this phase:

‐ Migration of material from WebCT or other systems,

‐ LMS system architecture,

‐ LMS system install, hosting and management.

C19

1.4 Business Context

The new LMS requires information that other systems across the University contain. This information includes student cohorts who will be enrolled in units, online course materials that are managed through systems such as CMO and Perception. This information needs to be sourced from the relevant systems in an efficient way that appears seamless through the user interface.

1.5 User characteristics

Users of the LMS will include:

‐ Students,

‐ Staff,

‐ Guests,

‐ Administrators.

1.6 Assumptions

All systems required for integration have web services available for sharing information.

1.7 Dependencies

‐ Authentication dependencies exist with Forefront Identity Management (FIM),

‐ Access dependencies exist with Callista,

‐ Course material dependencies exist with,

o Course materials online and HIVE,

o Questionmark Perception,

o Echo system,

‐ Migration dependencies exist with WebCT.

1.8 Constraints

The key constraint around delivery for requirements is time.

The LMS integrations must be delivered by end of August 2011.

C20

2 LMS unit request process

A request process is required to provision LMS units.

LMS unit request process is included in the scope of this specification because it directly relates to the granting of access to various student and staff.

2.1 LMS unit request process map

Page 5

The following diagram illustrates the LMS unit request process.

1. Unit properties – establish unit properites

LMS unit type

Unit Offering

Combination

Avoid duplication

Request start

5. Save request

2. Student authorisation

3. Template selection

4. Configuration

Add elements

Other unit elements

Connect to other systems

Staff access

Echo booking

Student access

Student access period

6. Approval

Point from which request can be

Re‐entry point

Staff access

Comment [s e1]: The approval necessity is under discussion

C21

2.2 LMS unit request process requirements

The LMS unit request process is required to capture:

1. LMS unit properties

a. LMS unit type ‐ the requester to select 1 of

i. LMS Unit – choice of all units, (sourced from Callista)

ii. Course Unit – choice of all courses (sourced from Callista)

iii. Major Unit – choice of all Majors (sourced from Callista)

iv. Course Year Level Unit – choice of all course year levels (sourced from Callista)

v. Other Unit – free text entry designed to capture requests outside the standard range.

vi. Moodle Skills Practice Unit – a “sandpit” or “playpen” site for staff (only by LMS Admin)

b. To select a Unit, the requester

i. For LMS Unit (1.a.i) Unit offering ‐ The unit code and teaching period combined provide a unique unit offering. The requester must select:

1. unit code

2. teaching period

ii. For Course, Major and Course Year Level, the requester must select Course code or major code, and may select Year Level if required.

c. Combination – An option to combine LMS units is required,

i. Combine units ‐ does the requester wish to combine units?

ii. If so, the requester to select other units to combine.

iii. If a unit is already live or in request only an administrator can combine it.

d. Avoid duplication ‐ The system is required to establish if the LMS unit requested already exists or has been requested. If the unit exists, a message is required to display:

i. This unit has been requested or is live,

ii. The unit coordinator’s email address.

e. Staff access –

i. Unit Coordinator – (required) a unit Coordinator must be selected or confirmed at this point.

1. If a unit Coordinator is listed in Callista, this person will be the default LMS unit Coordinator. The requester can add an additional Unit Coordinator.

2. Student authorisation – when the LMS unit is identified through steps 1 to 4, the system is required to automatically populate student authority to access the LMS unit. This will be achieved through the information available from Callista and will reflect current enrolments, with changes in Callista being replicated in the LMS unit access immediately.

a. For LMS unit types: LMS Unit, Course, Major and Course Year Level; optional for ‘Other’; and not for the Moodle skills practice unit.

3. Template selection ‐ template is defined as a LMS unit layout that contains predefined elements. These elements are activities and blocks. Activities are items such as calendars, forums and blogs. Blocks are sections that appear within a page. By picking a template or format, blocks, activities and layout are preselected. Options for template selection are:

a. Use an existing LMS unit?

i. Select from a list of LMS units that the requester has access to.

C22

ii. This selection is then used as a basis for the new LMS unit.

b. Select a template from a list of predefined templates?

i. Standard templates will be required to be created for

1. LMS units

2. Course

3. Major

4. Course year level

4. Configuration – the requester can complete any of these configuration processes for the LMS unit as part of the request process.

a. Add elements – the requester can select additional activities or elements to add to the LMS unit.

i. Activities

ii. Blocks

b. Other unit elements – the requester can request access to other LMS units in order to select activities and blocks from that unit to add into the new LMS unit.

c. Connections to other systems –

i. LMS unit requesters will be able to browse the content of other systems to select elements to include in the LMS unit.

ii. LMS unit requesters will have a same sign‐on access through those systems. For example, a requester will not have to login to course materials online in order to view material. They will have access to the material they can normally see in course materials online.

iii. Selection of an element from another system will place it in a predefined block within the LMS unit.

iv. Other systems to include in this selection are:

1. Course Materials online and HIVE,

2. Echo system,

3. Questionmark perception – (only a configuration option when the LMS unit is live.)

d. Echo booking – the requester can complete a booking process for echo recordings –[ see 5.3.3 wireframe echo booking form]

e. Staff access – the requester can enrol staff to the Unit and assign roles (There may be multiple individuals in the same role. Roles are to be defined as part of the configuration process.)

i. Unit coordinator/s

ii. Lecturer/s

iii. Tutor/s

iv. Unit Admin

f. Student access – the requester can

i. For Other Unit type only, browse and add individual students who appear in the central authentication system

ii. Have the option for requester to allow self‐enrolment for all units EXCEPT LMS unit

g. Student access period – the requester can set the dates from and to the start and finish of student contribution access to the LMS unit.

5. Save request– from completion of step 2 Student authorisation, the request can be saved and completed later.

C23

6. Approval – the requester can submit the request for approval

a. Only an LMS Administrator or Category (ie Faculty or School) Administrator can approve an LMS unit request and make the LMS unit live.

b. LMS administrator can set the time period when the LMS unit will go live.

c. LMS administrator can review the request and alter details to suit.

d. On approval, notification is sent to the LMS unit requester,

i. The LMS administrator can manually write the notification message,

ii. If not manually overwritten a default text is used.

e. If not approved, notification is sent to the LMS unit requester,

i. The LMS administrator can manually write the notification message,

ii. If not manually overwritten a default text is used.

OR

6. Approval – A unit is automatically created unless a staff member requests that it is checked first.

a. Prior to creation, the requester can request Unit Creation Check. At this point

i. The request moves to ‘saved’ status.

ii. A follow‐up “receipt” appears on screen to confirm the request for checking and details of the request. Requester can save or print the receipt.

iii. An email message with the request details is sent to the CATL support desk. CATL will then check the details. If there are any issues, CATL staff will contact the requester by email to discuss the issues and assist in completing the form correctly.

iv. When the form is correct, CATL will advise the staff member to submit the Unit for creation.

b. A staff member can alternatively submit the request for automatic site creation.

i. A staff member selects submit.

ii. A follow‐up “receipt” appears on screen to confirm the request and details – requester can save or print. The option to go ‘back’ and edit choices exists on this screen.

iii. The requester can then resubmit if editing has occurred

iv. The requester confirms the submission, and email is sent confirming completion of the process and informs of a typical time frame for staff availability.

v. The system automatically creates the unit.

[S 6 otep d upon by CATL based on advice from Information Services and Netspot.] ptions are to be decide

2.2.1 Multiple unit creation

There is a requirement for a version of the unit creation process that would allow a staff member to create multiple units in one step. In this process:

‐ Category (Faculty or School) Admin should be able to create multiple units.

‐ The requester needs to be able to create multiple units in a single batch.

‐ It may be sufficient that the unit is created (Steps 1 and 2 only), without template or configuration selections.

‐ A bulk upload will not need approving as the Admin member will be considered to approve the Unit. This will allow the Unit to be reserved before multiple attempts to create LMS Units for the same course unit.

‐ Staff can then select further configurations post‐creation.

Comment [s e2]: We are currently considering an alternative to this approval requirement, but request IS expert advice. An alternative #6 is provided below.

C24

2.2.2 Process Help

Help text is required to be available with each section or step in the LMS unit request process, to support staff in completing the form successfully.

‐ The text should be:

o created by CATL,

o Editable in the future,

o The text content should advise staff on,

what the question and answers mean,

what some common issues might be

how to overcome them

where to go for further help.

2.3 LMS unit request process functional requirements

‐ Database driven selection of LMS unit name based on unit offerings sourced from Callista view.

‐ There will also be an option for non‐standard unit requests which would involve entering a free text title for the LMS unit.

‐ Options of templates or formats for selection in LMS unit request process to same time and to control LMS unit layout to predefined standards.

‐ Capacity to combine LMS units under to cater for the instances where multiple units are taught through one LMS unit.

‐ Ability to add additional activities, blocks or elements to the LMS unit.

‐ Ability to add additional activities, blocks or elements to the LMS unit from past LMS units.

‐ Ability to assign roles within the LMS unit.

‐ Ability to manually add access authorisation for individuals to the LMS unit.

‐ Database driven enrolment i.e. addition of student authorisation access to LMS units sourced from Callista enrolment information.

‐ Ability to set the access period for students to a LMS unit.

‐ Ability to add elements from these sources to the LMS unit:

o Course Materials Online,

o Echo system,

o Questionmark perception.

‐ Ability for a LMS unit request to be approved by an LMS administrator. Then for the request information to populate the LMS thereby preconfiguring a live LMS unit.

‐ An administrator group email is required to be sent to notify the administrator/s of all LMS unit requests.

‐ Ability for a LMS unit requester to save a request for further editing and submission later.

‐ Ability for a LMS unit requester to adjust LMS unit properties when the LMS unit status is live. These properties will only include:

o Unit roles,

C25

o Unit membership for individuals,

o Addition of activities and blocks,

o Addition of elements from other systems – CMO, Echo system, Questionmark perception.

In addition the LMS administrator will be able to

Extend a unit duration

Combination of units

Add

3 LMS unit lifecycle

groups of members.

The LMS unit life cycle is depicted below. Steps in the cycle are:

1. LMS unit request process.

Page 10

2. LMS unit approved,

a. Staff can access an LMS unit immediately on approval.

3. Student access.

4. Review status – read only access for staff and students

a. A copy of the LMS unit is exported to a separate records management system for archiving.

5. LMS archive status – the LMS unit will be retained in the LMS according to a time set by CATL. While in this status the LMS unit is available for requesters to use as a LMS unit template for creating a new unit. There is no read access to the unit while it has this status.

3.1 LMS unit life cycle requirements

‐ Request ‐ a LMS unit is created through the LMS unit request process, followed by LMS administrator approval.

‐ Approval ‐ when a LMS unit is approved, an email notification is sent to the LMS unit requester.

‐ Staff access – staff have access to the LMS unit from when it is created.

‐ Student access – students have access as defined in the LMS unit request, alternatively an LMS administrator can set the student access period.

‐ Staff and Student end point – no further adjustments or contributions to the LMS unit can be made from this point onwards. The LMS unit becomes a read only resource.

1. Request

LMS unit request

[see request process]

Staff access – immediately on approval

3. Student access

Archive copy ‐ a copy of the LMS unit is exported to a records management system.

4. Review status ‐ read only access for staff and students

Staff and Student end point for access

No further contributions after this point

5. LMS archive the LMS unit will be retained on the LMS according to records management procedures

2. LMS unit approved[see request process] Live status

LMS unit is available for requesters to use as a LMS unit template for creating a new unit. There is no read access to the unit while it has this status.

Comment [s e3]: This will change to “Staff can access an LMS unit immediately upon successful completion of the form” if the no‐approval process is selected

Comment [s e4]: Or “created”, if the no‐approval process is used

C26

o Staff to receive a notification e‐mail prior to this point. This will be 7 working days with the time and frequency of reminders being variable. LMS administrators can set this frequency and time.

‐ Records management system archive copy – A copy of the LMS unit and all materials in it will need to be exported to a records management system. This copy will need to be retrieved in cases of academic reviews/assessment challenges.

‐ Review status – the LMS unit is a read only in this status. This period will last for a default time of 1 year, however it needs to be adjustable per LMS category. For instance, Medicine will require that units are in review status for 4 years. Only an administrator can adjust the review period setting for a LMS unit.

‐ LMS Archive – when a LMS unit has reached the end the review status period, it must be retained. The LMS archive is to be available for requesters to use as a LMS unit template for creating a new unit. The new LMS unit will have layout, activities and blocks as contained in the LMS archive, except the student contributions will not be copied across.

‐ Netspot – are required to advise on the following points before the requirements can be finalised.

o CATL is to set a period for retention of an LMS archive based on cost and data consumption in the hosted solution.

o The business rule for staff storing materials in one spot in the LMS is to be confirmed.

o The business rule for what materials staff can take from a LMS archive and place in a new LMS unit is to be confirmed.

‐ Recommendation – That all records management system archive copies including those from WebCT are stored in the same place.

C27

4 Student life cycle

The student life cycle in a LMS unit is depicted below. Steps in the cycle are:

1. Enrol in unit ‐ information recorded in Callista. Information recorded in central authentication source.

2. Group placement,

a. Students allocate their own groups through the online class registration system,

b. Students are placed in groups by staff from within the LMS.

3. Student access to LMS unit.

4. End of student contribution to LMS unit.

5. Review – read only access.

6. Review end – end‐point for read only access.

Placed in groups by staff

2. Students allocate their own groups through online class

3. Student access to LMS unit

4. End of student contribution ‐ to LMS unit

5. Review –read only access

6. Review end – end‐point for read only access

1. Enrol in unit ‐ information recorded in Callista. Information recorded in FIM authentication

4.1 Student life cycle requirements

‐ Staff to be able to view student status in a LMS unit.

‐ Some students will not be in Callista. These students will need to have authentication provided through another means, these students will need to have authorisation to view LMS units set manually by a requester or LMS unit administrator.

‐ Authentication details for “Guest” students will need to be added into a central authentication system. The requirement is that addition to this system will include being able to add single and multiple accounts.

‐ Students often change enrolment. A requirement is that changes in enrolment as recorded in Callista are reflected in the authorisation provided to students in the LMS. The required timeframe is that the LMS is updated immediately.

‐ Guests and visitors are to be able to be notified via email when they have been given authorisation to access a LMS unit. Guests and visitors are defined as anyone who is not an administrator, staff or enrolled student.

‐ Students are added to records in the LMS Unit (e.g. enrolment lists and grade book) before they have access to the unit.

‐ Unit code and teaching period are to be populated into separate columns in the grade book when students are put into a LMS unit.

‐ Recommendation – It is a recommendation from this project that the entire student experience at the University be captured in a single system with Callista being the most obvious candidate for this.

Page 12

C28

5 Integration with existing UWA systems

5.1 Callista

Callista is a core student information management system.

The LMS project requires that:

‐ Data held in Callista to be available to the LMS, as listed in the tables of required fields,

o [See 8 Appendix 2 – Callista tables of required fields].

‐ Student groups enrolled in unit offerings in Callista are provided automatic authorisation/access to corresponding LMS units will the same code in the LMS,

‐ Student changes in enrolment are carried across to the LMS and reflected in authorisation/access to relevant LMS units. A requirement is that these changes are reflected immediately.

‐ A requirement is that the LMS can obtain the teaching period from Callista. The teaching period is used to identify the unit offering,

o Unit offering = unit code + the teaching period,

o Location is a required field that further identifies a unit offering.

‐ Unit code and teaching period to be populated into separate columns in the grade book when students are put into a LMS unit.

5.2 Authentication

All users of the LMS are required to be authenticated with the exception of the open access units.

‐ Username and passwords will be held in a central authentication source provided by Information Services.

‐ All users will authenticate into the LMS, logging in (with the exception of those LMS units that are public.)

‐ Some groups of students are not listed in Callista. These individuals will still need to be authenticated.

‐ Open access units will not require authentication,

‐ Recommendation – it is recommended that Information Services manage all identities in relation to the LMS from a central source.

5.3 Echo system

Echo system is the new lecture capture solution to be deployed at UWA.


‐ Echo schedule of captured events can be linked to from the LMS unit.

‐ Echo individual element can be linked to from within the unit.

‐ Staff adding unit schedule of captured lectures can do so as part of the request process or as part of LMS unit development.

‐ Staff will not need to manually authenticate to Echo when browsing to view components

‐ Students within the LMS unit will be able to link directly through to Echo without having to manually login.

C29

5.3.1 Wireframe Echo schedule selection

This diagram depicts how a user can select to include a schedule or individual component from Echo system and browse to that item.

Page 14

Selector

View as icons View as list

Server files

Recent files

Upload a file

Private files

Course Materials Online

Echo

Question mark perception

Google docs

Item 1 lorem ipsum aliquet velit sollicitudin sed malesuada ipsum hendrerit.






Browse capability to select item to incorporate into the LMS unit.

Listing shows the material in Echo that the user has access to.

5.3.2 Wireframe Echo appearance in LMS unit

This diagram depicts a listing of Echo lecture recordings in the LMS unit. This is how echo components would appear to students and staff using the LMS unit.

Links – are listed within a LMS unit block. They link through to the echo system to play recording.

C30

5.3.3 Wireframe echo booking form

As part of the unit request process there is an option to book recordings through the LMS in Echo.

This requires a booking form. The key element of this booking form is to use the unit code from the LMS unit request to import information from online class registration (OLCR.) This information is venue, week and frequency. This is then used to generate a booking array.

The requester can then select which lectures or tutorials are to be recorded.

The requester can also select the recording and delivery formats.

Page 15

> LMS Home

LMS – Echo booking form

ACHIEVE INTERNATIONAL EXCELLENCE

Unit code unit title

+ add

Recording sessionsWeek

Week 1 Lecture 1

Activity

Lecture 2

Week 2 Lecture 1 Lecture 2





Week 7 Tutorial 1 Tutorial 2







Submit

Unit coordinator

+all

Recording format Delivery format

+all

Activity 1

Activity 2

Unit details are carried through automatically to the form. These then generate the selection array of activities. Activities are lectures and tutorials.

Recordings can be booked by selecting the appropriate sessions, then submitting the form.

Activities are: ‐ Lectures, ‐ Tutorials.

Recording formats are: ‐ Audio only, ‐ Audio and screen.

Delivery formats are: ‐ Streaming and download or, ‐ Streaming, download and podcast.

5.4 Course materials online and HIVE

Course Materials Online (CMO) is the course readings application deployed at UWA. HIVE is the repository in which the CMO objects sit.


‐ CMO components or reading lists can be linked to from the LMS unit.

‐ Staff adding each CMO component can do so as part of the request process or as part of LMS unit development.

‐ Staff adding CMO content will be able to select components.

‐ Staff will not need to manually authenticate to CMO when browsing to view components

‐ Students within the LMS unit will be able to link directly through to CMO without having to manually login.

C31

‐ It is a requirement that CMO can provide a group of resource links to be added to a block in a LMS unit as well as an individual link.

5.4.1 Wireframe – Course material selector

This diagram displays how a user can select to include a component from CMO and browse to that component.

5.4.2 Wireframe – course materials online display page

This diagram depicts how a reading list from CMO would appear in a LMS unit. The links would link through to the CMO material.

Titles link through to CMO material. CMO sort and search elements are available.

Page 16

C32

5.5 Questionmark Perception

Questionmark perception is the learning tool used by the Faculty of Medicine and Dentistry and Health Services at UWA.


‐ Questionmark Perception components such as quizzes can be linked to from the LMS unit.

‐ Staff adding each Questionmark perception component can do so as part of the request process or as part of LMS unit development.

‐ Staff will not need to manually authenticate to Questionmark Perception when browsing to view components

‐ Students within the LMS unit will be able to link directly through to Questionmark Perception without having to manually login.

‐ Grades that are in the Questionmark Perception quiz need to come through to the LMS grade book.

5.6 Online Class Registration

The online class registration (OLCR) tool is used for students to select which tutorials and or laboratories they are to attend.

The LMS project requirements are that:

‐ Student groupings from OLCR are shared with the LMS.

‐ That changes and updates to the OLCR records and groups are reflected in the LMS.

‐ Changes in OLCR are to be reflected in LMS immediately.

‐ The LMS can then reflect OLCR groupings in subsections of units.

‐ The requirement is that this configuration is to take place after a LMS unit has been made live.

‐ Staff can create LMS groups when they have access to a unit.

‐ Recommendation: OLCR is listed as priority 3 in the Agreement with Netspot due to the potential for extra development time and cost as OLCR is an unknown for Netspot. However, as identified in this specifications document, it is important to the basic environment functionality for commencement of implementation. Therefore it is recommended that it be prepared for integration with other systems, and the implications be identified and resolved now.

5.7 Google mail

Google Gmail is the mail system that all UWA Students use.

The LMS project requirements are that:

‐ Student Google Gmail can be embedded in the LMS as a private feed for each student

o This is to be automatically set‐up with the student having the ability to hide it.

‐ This would be an element that the student would be able to manually set up against their LMS profile.

o This assumes that there is a profile section of the LMS that a student can configure and change.

5.8 Portal

The MyUWA portal tool contains a series of feeds that can be nested and configured to provide windows and links to resources and tools across the University.

C33

The LMS strategy is to provide students with new elements in the portal to link into the LMS. The LMS project requirements are:

‐ A MyUWA portlet to be created that will list a student’s active LMS units, o Listing unit code and a link to the LMS unit,

‐ A MyUWA portlet to be created that will list a student’s review LMS units, o Listing unit code and a link to the LMS,

‐ The list of units that appears in the Portal comes from the LMS.

5.9 Wireframe – MyUWA LMS portlets

MyUWA

Home | Research| Help Site Search UWA Website GO

Make MyUWA yours

Welcome to your MyUWA home page.

You can change the content of this page at any time ‐ change the layout, add or remove portlets ‐ by selecting Edit Page from the Home drop‐down menu.

You can create more home pages as well, up to six of them, by selecting Create New Page from the Home drop‐down menu.

News

News title lorem ipsum

Wed, 25 May 2011 | Uwa Media Statements

Phasellus vitae arcu eu ante scelerisque placerat ac sed lorem. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam dictum arcu sit amet ipsum venenatis molestie sit amet id neque. Etiam ornare tortor aliquet velit sollicitudin sed malesuada ipsum hendrerit

My LMS Units ‐ active

Unit Code Unit title and link Phasellus vitae arcu eu ante scelerisque placerat ac sed





Important Links

> link title lorem ipsum pracias





My LMS Units ‐ review






Page 18

C34

6 General recommendations

These recommendations sit outside the scope of this specification. They are included to capture aspects of the overall process that have been identified through the requirements gathering process. Recommendations are:

‐ System Administrator/s – it is recommended that a full time system administrator/s be appointed to the LMS project to manage structure and adjust the LMS system as required.

‐ Information architecture – it is recommended that the LMS project engage advice around branding look and feel, layout and information structure across the LMS. Moodle LMS unit themes can be customized to suit the University’s requirements.

‐ Authentication – it is recommended that Information Services establish a policy and framework to authenticate all system users from a single source and thereby manage a single identity for system users across the university.

‐ Student information – it is recommended that there be a single repository for a student’s entire experience with the University throughout their lifecycle.

‐ Solution development – it is recommended that Netspot as the host of the LMS identify a demarcation line for connecting to other systems. That is only Netspot should be changing and configuring Moodle code while other vendors should be making their system web services available for Moodle to use. This should provide consistency in how other systems are used by Moodle.

‐ Accessibility – it is recommended that all solutions delivered through the LMS are accessible as possible with reference to Web Content Accessibility Guidelines (WCAG) 2.0.

‐ Archives – That all LMS archives including those from WebCT are stored in the same place.

‐ OLCR is listed as priority 3 in the Agreement with Netspot due to the potential for extra development time and cost as OLCR is an unknown for Netspot. However, as identified in this specifications document, it is important to the basic environment functionality for commencement of implementation. Therefore it is recommended that it be prepared for integration with other systems, and the implications be identified and resolved now.

C35

http://www.netspot.com.au/

http://www.netspot.com.au/

http://www.w3.org/TR/WCAG20/

7 Appendix 1 – LMS unit properties

The following table depicts properties associated with a Moodle LMS unit in the Moodle administration interface. These are properties that are available for configuration at the administration level. (Moodle terminology calls these LMS units courses. In terms of this specification, unit means a Moodle course.) The LMS unit request process will allow some of these fields to be captured and applied to a LMS unit. Notes are ese fields will be captured in the LMS unit request process. included to indicate which of th

7.1.1 Table 6 ‐ LMS unit properties

Setting Description Notes

Category Category to which the unit belongs A requester can select a category and choose to combine the unit with other units. Yet the LMS administrator must confirm where the course sits in the LMS system structure.

Full name The full name of the unit is displayed at the top of the screen and in the unit listings

A requester will select this from a list provided in the request process and sourced from Callista.

Short Name The unit code Selected from a list provided from Callista records

Course ID Number Official unit code Selected from a list provided from Callista records

Summary A concise paragraph that explains what this unit is about. The summary is displayed when a user clicks on the information icon when a unit appears in a list.

The requester will be able to edit this summary in the LMS unit request process

Format Formats include: LAMS, SCORM, Social, Topics, Weekly, Weekly no tables

Custom templates or formats are required to be developed. These can then be selected during the LMS unit request process.

Number of weeks/s or topics

In the weekly unit format this is the number of weeks that the unit will run for, starting from the commencement date. In the topics format it is the number of topics in the course. Both of these translate into the number of boxes in the centre column of the course page.

This information should be associated with the unit code and be sourced from Callista.

Hence by selecting the unit code, this information is attached to the LMS unit.

Unit start date Refers to the staring date for the unit, only relevant for weekly formats.

Unit start date should be associated with the unit code and be sourced from Callista. Hence by selecting the unit code, this information is attached to the LMS unit.

Hidden sections Determines how hidden unit sections are shown. By default, they are displayed as small collapsed areas, invisible to the students. When completely hidden, the students are not presented with any information.

This should be set through the template or format. A requester should be able to configure and change this for an LMS unit.

News items to show Determines how many recent items appear on the unit home page in the news section (if any)

This should be set through the template or format. A requester should be able to configure and change this for an LMS unit.

Show grades Determines whether students are shown the grades link in their Administration block. This can be set to No and the activity still graded.

A requester should be able to set this in the LMS unit request process.

Show activity reports Determines whether the activity reports of the students and teachers can be seen by other students of the course.

Default setting of off. A requester should be able to change this.

Maximum upload size This setting limits the size of a file a user can upload into this unit.

This should be set through the template or format across all units. Only an LMS administrator can change this.

C36

Is this a meta unit? Meta units are units which take their enrolment from other units

The requester will be able to set this in the LMS unit request process. It describes a combination of LMS units to cater for the instances where multiple units are taught through one LMS unit.

Enrolment plugins The LMS will use database driven enrolment (from Callista)

The requester will be able to add individuals to have authorized access to the LMS unit. A LMS administrator will be able to add groups.

Default role This is the role assigned with assignment is automatic (rather than manual.) This value overrides the default role for users in a unit.

Only a LMS administrator can set this field.

Unit enrollable During the preparation of a unit, it is sometimes necessary to avoid enrolment until it is read. Also a date can be specified when the unit can be enrolled to.

As specified this is captured in the LMS unit request process. Beyond the initial request only a LMS administrator can change this setting for a unit.

Date range As above As above

Enrolment duration The number of days the users are enrolled in a unit, starting from the moment they enroll. If set they are automatically un‐enrolled after the specified time has elapsed.

Access to LMS units will be determined through reference to the corresponding information for a student’s enrolment details in Callista.

Enrolment expiry notification

The three fields specify whether the course teachers (Notify) and students (Notify Students) will be notified. A Threshold has to be set indicating how many days prior to expiry the notification will be sent.

This is a default setting that can be adjustment by a LMS administrator.

Group mode Sets group mode of the course to:

‐ No groups (default) – there are no sub groups. Everyone is part of one big community or class.

‐ Separate groups – Each group can only see their own group, while others are invisible

‐ Visible groups – each group works in their own group, but can also see other groups.

A default will be separate groups [CATL to confirm]

Force If selected the group mode is used for every activity and group settings in individual activities are ignored. This is useful when the same unit is run multiple times with separate student cohorts. Also if group mode is forced and set to no groups, no groups link will be shown in the unit administration menu.

[CATL to confirm]

Availability If set to not available the unit is hidden. Except the course teachers and administrators, no one will be able to see it on the unit listings.

This would be a LMS administrator only setting. [see requirements around the unit lifecycle]

Enrolment key This is a unit password which is required when self‐enrolment is chosen.

This will not be active. There will be no self‐enrolment for standard units. However a LMS administrator may set this to active on public units.

Guest access Allows guest (read only) access to a unit where it can be selected if guest require an enrolment key.

This may be manipulated in order to provide the review status required for units ‐ [see requirements around the unit lifecycle]

Cost If the LMS unit uses payment based enrolment then the unit cost here will override the specified default cost.

This is not required and should only be a LMS administrator setting.

Force language If set the selected language is used throughout the course and cannot be changed

LMS administrator only setting

[Source of settings and descriptions: A., Buchner, Moodle Administration, PACKT, Birmingham, 2008, pp. 72‐75]

C37

8 Appendix 2 – Callista tables of required fields

The fo ing tables depict fields of data held in C

8.1.1 Table 3 ‐ Callista student information

llow allista and those that will be required by the LMS.

Callista Field Required by LMS

Notes

Person ID Yes A person’s unique identifier must be consistent

across systems

Alternate Person ID Yes

Institution Role/Account Type

Title Yes

First Name Yes

Preferred Name Yes

Last Name Yes

Email Yes LMS will use email address for Lecturers etc to

contact student

Phone number from correspondence address

No

Staff Indicator Yes LMS will need to know what contexts a staff

member is a student

Photo

Yes LMS will use the Callista photo as the default photo for the student. Students can then adjust the photo when they are in the LMS.

Gender Yes

Date of Birth Yes

8.1.2 Table 4 ‐ Callista unit information

Callista Field Required by LMS

Notes

Unit code

Yes LMS will need to know what unit codes are available and who is associated with them

Unit title Yes

Unit short title Yes

Unit abbreviation Yes

Unit version Yes

Credit points (re‐enrolled and achievable) Yes

Unit offering option ‐ ID ‐ Mode ‐ Location ‐ Class ‐ Start ‐ End

Yes

Derived year from parent academic calendar Yes

CI – sequence number

CAL type

Owning org unit Yes

Owning org unit start date Yes

Unit coordinator person ID Yes

C38

Unit coordinator alternate person ID Yes

Unit activity ‐ ID ‐ Tutorials ‐ Class ‐ Lectures ‐ Start dates

Yes

Unit level Yes

Unit sector Yes

8.1.3 Table 5 ‐ Callista enrolment information

Callista field Callista sub‐field

Required by LMS

Notes

Person ID Student course attempt Yes

course code Yes

location code Yes

version Yes

Course attempts status Yes

Discontinued date

Student unit attempt person ID

Yes

Course cd

unit cd

cal_type

ci_sequence_number

The Unit Offering Option ID unit_cd

Yes

version_number

cal_type

ci_sequence_number

location_cd

unit_class

unit attempt status

discontinued date

exam location

flag for incomplete grades

Progression Progression outcomes

progression status (to indicate which students are at risk)

C39

LMS (MOODLE) IMPLEMENTATION PROJECT 2011‐2012

VARIATION TO FUNCTIONAL SPECIFICATIONS: discussion document

Document control:

Filename LMSPrjInteg Changes to Functional Specs 20811 SJ.doc

Saved on 2/08/2011 7:30 PM

Author Shannon Johnston, for SJ, Steve Howe, Brian Poleykett

Distribution Shannon Johnston, Yvonne Button, Brian Poleykett, Steve Howe, Denise Chalmers, Mary Davies, Jen Tomczak

Revision history: Version Author(s) Description Reviewed by Date completed

0.1 Shannon Johnston Initial draft Brian Poleykett Steve Howe

2 August 2011

Purpose for change The requirements for the LMS functionality, in particular around LMS Unit creation were deemed to be excessively complex. The impact of these and other factors are found to have a negative impact on the timing, scope and cost of the project for completion of Build 1 for 2012. Furthermore, some of the complexities are deemed to promote pedagogical practices that promote resource selection over learning and teaching design.

Principles for change

Address issues in time and cost, particularly when quality is not a discernible compromise

Ensure the process of LMSUnit creation follows quality pedagogical design processes (ie design of learning and teaching before assignment of resources)

Ensure that the process is a simple, clear, and regular as possible for the user – have a function carried out in one location

Manage identities only in the identity system

Key changes LMS Unit Creation Process / Form

2.2.1b, 2.2.1c – naming of a unit in the LMS

** for duplication the title of the LMS Unit is a combination of all Callista unit codes

have codes only appear in the LMSUnit title; have codes and teaching periods appear in the My Moodle list.

2.2.2 c – student authorisation (updated according to more recent authentication decisions through systems architecture process, and IAM project developments)

2.2.4 – delete all configurations and resource / activity additions at this stage, complete only through

a. activities, blocks

b. selecting from other units

Note: b. selecting content and activities from other LMS Units needs to be explored further. If it can be done from within a created LMS Unit, then it will not be done during LMS Unit creation.

3 LMSPrjInteg Changes to Functional Specs v0 2 030811 SJ page 1 of 3 Created by Shannon Johnston, 02 Aug 2011

C40

c. access to other systems – CMO, Echo, Question Mark Perception

d. other staff access and roles Question – in Moodle, how do people identify and draw in other staff – by username, or Firstname, Secondname?

e. student access except: allow ‘self enrolment’

2.2.6 Remove requirement for course approval Keep requirement for automatic course approval, with option to request course be reviewed/checked.

CMO integration

1. keep the current functionality available with WebCT – to link to course reading lists.

2. remove requirement to select CMO from Unit creation process

3. remove requirement to manage CMO from within LMS Unit

4. ? remove requirement to select specific files from CMO? (see note below)

Outstanding questions LMS Unit Creation Process / Form

2.2.1d – Avoiding duplication of unit requests

Business rules: how to detect a duplicate, ‘this unit exists’, what’s the unique data… legitimate and illegitimate units. Unit code in Callista identifies the LMS unit is assigned. Feedback to/with Callista. Where does duplication checking happen?

1:1 duplication rejected. LMS Unit code and teaching period. You have selected this unit, but it already has a LMS Unit for this code and teaching period. Moodle as authority.

2.2.3 – template selection

Review and confirm. Would staff really select a template from a past course? Or start afresh from limited blank templates into which content is drawn?

Not necessary.

2.2.1 – multiple unit creation

Ask NetSpot’s advice, given the complexities of our form. Ask YB who does bulk uploads – is it really a time saving.

No bulk uploads. But add to receipt for submit form for LMSunit creation two buttons: 1 “I’ve finished give me my unit”, 2. “Do another”

3.6 – 3.7 – change of student provisioning from active LMS unit to archived LMS Unit

clarify business rules more clearly… IAM project – separating Callista and LMS

Daily until first census date, weekly until a set time prior to Callista closing unit. E.g. one week. IS to advise whether daily is OK all the time.

Need actual timeframes for units in archive status. Business rules. Check implications. Academic policy services.


C41


Business case – 6 months review status. 6 months in Moodle … numbers, backup how do staff who only teach a unit every two years access old data? Separate archival site data storage off site.

CMO integration

implications of functionality of selecting specific files within the CMO ‐ $63000 cost for this functionality. Perhaps it could be a future, phase 2 functionality. One issue is the review of Hive

C42

Architecture Overview – LMS Integration Information Services Division

Author: Damian Bramanis

Version: 0.3

Version Author Date Description Distribution

0.1 Damian Bramanis 21-07-2011 First Draft Peer Review

0.2 Damian Bramanis 22-07-2011 Updated following peer review

Technical Contacts (Appendix 1)

0.3 Damian Bramanis 01-08-2011 Updated following requirements clarification

Technical Contacts (Appendix 1)

Use this template to describe the overall technical architecture of any project or work that involves significant change. The completed Architecture Overview should be forwarded to the Technical Architecture Board for approval, before building or purchasing any part of the solution.

A significant change is:

Any change that introduces a new technology, that is not currently used in a production environment;

Any change that is not in accordance with architecture, strategy, policy or standards and requires a waiver.

Any project or technical change that requires 4 man-weeks of effort or greater, excluding standard changes;

C43

4 LMS Integration Architecture v0 3 Page 2 of 10

1 Architecture Overview

1.1 Purpose

Information Services and the Centre for the Advancement of Teaching and Learning (CATL) are engaged in a joint project to deploy a new Learning Management System (LMS). CATL is the business owner and is managing the project which consists of a joint Information Services and CATL team.

This LMS will be the core delivery platform for unit subject matter effectively being a virtual supplement to physical classrooms and education processes. Due to this, the LMS will need to interact and display information from various other systems deployed throughout The University of Western Australia.

1.2 Architecture

Learning Management

SystemMoodle

Email GatewayIronport

Identity Management

FIM

Course Materials

OnlineHIVE

Lecture Recording

Echo

Quizzes/Assessment

QuestionMark Perception

Archive Storage

PortalmyUWA

Class Registration

OLCR

Student EmailGoogle Apps

Student Management

SystemCallista

Email Notifications

Staff provisioningStudent provisioning“Visitor” provisioning

Student unit enrolmentDeprovisioning

Administer CMOList/View CMO Content

File Picker

Generate SSO SessionEchoCentre – Admin/View Conte

File Picker – Shared ConteBook Lecture Recording

ntnt

Generate SSO SessionAdminister Assessment/Quizzes

Link to ContentWrite Grades into Moodle

List UnitsList CoursesList Majors

Import Student PhotosImport Course Year Levels

SSOBasic Email

Link into Google Apps

Update Tutorial Groups

Links to LMS Units

Archive / ExportReview Archive Copy?

Single Sign‐onSiteminder

Authentication

Authentication (SSO)

Authentication (SSO)

Bulk Load (ad hoc)

List of Users

Archive Data

Figure 1 - Overall Integration Architecture

The new LMS (Moodle) will be hosted by Netspot, and will integrate directly with a number of UWA systems. These integrations will be used for:

Manage User Identity – managing user provisioning, deprovisioning, authentication and single sign-on This includes Forefront Identity Manager and SiteMinder Web Single Sign-on

Source Content – sourcing quiz, assessment, lecture recording and course materials content This includes QuestionMark Perception, Echo, and HIVE/Course Materials Online

C44

Manage Course and Class information – enrolment, tutorial group registration, units, courses and majors This includes Callista and OLCR

Link to other student systems – linking with other systems used by students, including student email and the portal

Other – keeping an archive copy of LMS information, sending email notifications, and DNS

Where possible, these integrations will use Web Services or off-the-shelf Moodle connectors.

Netspot

FIM Synchronisation Service

Staff provisioningStudent provisioning“Visitor” provisioning

Student unit enrolmentDeprovisioning

SiteMinder Policy Server

Apache agent, installed on Moodle web server, using UWA configuration

SiteMinder Web Agent

Applications which must also use SiteMinder SSO:PortalStudent EmailCMO/HIVEOLCR

User Provisioning and Enrolment(Web Services)

Moodle DB

Moodle

FIM Portal

Bulk Load (ad hoc)

FIM DB

List of Users

XML file with user details, for initial load of

students and staff into Moodle

Login Page New page for Moodle authentication

Redirect (after login)

Figure 2 - Identity Architecture

Identity Integration

Users will be provisioned by FIM using a Netspot-provided Moodle Web Service. For performance reasons, there will be an initial bulk load (XML file) into the Moodle database. This might be used annually at enrolment time, which will be determined during detailed design.

Moodle also requires access for visitor accounts, which will be provisioned by FIM. The FIM portal will be used to provision these “visitor” accounts, and will provide attributes (username, first name, last name, email), and enrolment details. Initially, these accounts will only be used for Moodle, but they may be granted access to other UWA systems in the future.

All users (staff, students and visitors) will be provisioned into UNIWA, and will be authenticated by SiteMinder. The only exception to this is some Moodle administrative accounts, which may have direct access to Moodle, and may not appear in FIM or UNIWA. Google Apps, MyUWA, OLCR and Moodle will all be under the same SiteMinder SSO instance.

Moodle may also be used to contain open access units, which can be accessed without authentication. Architecture for this TBA.

There will be some delay to synchronise user data with Moodle (e.g. after enrolment, or deprovisioning). This synchronisation delay is acceptable to the University.

FIM will provision students with their Callista unit enrolment (and not their “LMS unit” enrolment)


C45


When withdrawing from a unit in Callista, FIM calls the User Provisioning web services and the unit enrolment is made “inactive” in Moodle, so that the student no longer has any access to the LMS unit. When completing a unit in Callista, the user must stay enrolled in the LMS unit. When the LMS unit archive date is reached, Moodle will change the unit to a review unit, and the student’s access will become read-only.

Open Access: How to design authentication for open access units? Likely either:

1) Separate subdomain for open access units

2) SiteMinder to protect only the login page, Moodle to redirect to login page only when authentication is required

Callista DB

Netspot

Import Units/Courses/Majors(Scheduled Task)

Moodle DB

Moodle

UnitsDB View

CoursesDB View

MajorsDB View

Course Year Levels

Import Course Year Levels

(Scheduled Task)

Student Photos

DB View

Figure 3 - Callista and Student Photos

Callista Integration

New DB views will be set up in Callista’s Oracle DB. These will be accessed daily by a scheduled task at Netspot, to synchronise Moodle’s list of Units, Courses and Majors. There will be no event-based push of data from Callista to Moodle (e.g. grades will need to be manually entered into Callista).

Callista’s unit, course, major and course year level information is authoritative, and Moodle will retain a copy of this information.

Unit enrolment information will be sourced from FIM, and not directly from Callista. However, if the FIM integration is not possible, an alternative design is to source unit enrolment (and possibly student information) directly from a Callista DB view.

C46

Student Photos will be updated daily from a Callista view, which can be selected by last modified date/time. Student Photos are stored in an Oracle BLOB in the Callista Database. Students will not be able to update their own photos in Moodle – this functionality will be disabled – however students will have the option to select whether their photo is visible to other students.

Course Year Levels

Course Year Levels: What are the business rules for course year levels, and do these require Moodle cohorts?

UWAGoogle

MyUWA Portal

Active Units Portlet

Netspot

Google Apps Connector

Moodle

SiteMinder SSO

UWAGoogle Apps

URLs for LMS Units

List Units for Student

(Web Service)

OLCR


SSOBasic Email Functionality

Link to Google Apps

Review Units Portlet

Existing Units Portlet

List Active Units

List Review Units

GroupsDB View


(Scheduled Task)

OAuth Certificate

OAuth Certificate

Figure 4 - Google Apps, MyUWA Portal and OLCR

OLCR Integration

Tutorial Groups in OLCR will be regularly synchronised with the Moodle gradebook. OLCR is the authoritative source of Tutorial Groups, these groups will not be updated directly within Moodle. All other groups will be managed manually within Moodle.

Tutorial Groups will be made read-only in Moodle. Tutorial Groups will be updated every 2-hours (incremental update) a DB view provided by OLCR. Tutorial Groups will be updated daily (full update) using the same DB view provided by OLCR.

Tutorial Groups will be loaded into the Moodle Gradebook, Moodle users may manually copy these groups for other purposes.

Portal Integration

A Moodle Web Service which lists unit information for a given student, will be called by MyUWA portlets. There are 2 new portlets – one for “review units” in Moodle, and one for “active units” in Moodle. The existing portlet which displays links to WebCT, CMO and Lectopia will be updated to include links to Moodle. All of these portlets will use the same Web Service.


C47


Google Apps Integration

Google Apps functionality will be handled by Moodle and Google – this integration will not require any UWA involvement, except for providing the OAuth Certificate. UWA’s Google Apps is already integrated with UWA’s SiteMinder single sign-on, and this must continue to operate when using the Google Apps Connector.

Netspot

Moodle

Quizzes/AssessmentQuestionMark Perception

5

Course Materials OnlineHIVE

List CMO Content

Block

Administer CMO Block

Content

Lecture RecordingEcho

SiteMinder SSO

Echo Connector

Generate SSO SessionEchoCentre – Admin/View Content

File Picker – Shared ContentBook Lecture Recording

QMP Connector

Generate SSO SessionAdminister Assessment/Quizzes

Link to Assessment/Quiz ContentWrite Grades into Moodle Gradebook

Deep Link to

Content/Function

Authenticated by SSO

Pass Unit Code in Query String

Figure 5 - Content Integration

Echo Integration

A modified Moodle Echo Connector will be used to integrate Moodle to Echo (lecture recording). This will primarily be used to allow access to Echo content via Moodle. The connector will:

Generate a user session in Echo, for single sign-on

Allow a staff member to administer Echo content

Allow a student to view Echo content, from within Moodle

Provide a file-picker, so Echo content not linked to the unit (e.g. UWA-generic content, or shared content) can be embedded within the Moodle unit

Provide an interface to book Echo lecture recordings

Echo content will be linked to “Callista units”, so there may be multiple Echo blocks (corresponding to multiple Callista units) in a single LMS unit.

C48

What is the requirement for Echo integration for shared content - assume linking to a different EchoSystem section that is marked as a "shared" section (requires University Staff Login but not enrolment)?

This integration will be entirely designed by Netspot.

CMO/HIVE Integration

This integration will be designed by eXact, in conjunction with Netspot.

New pages in CMO/HIVE will be built to:

Allow a staff member to administer CMO content for a unit

Allow a student to view CMO content for a unit

Select other content (not necessarily linked to a unit), with a file-picker, that may be embedded directly within an LMS unit

CMO content will be linked to “Callista units”, so there may be multiple CMO blocks (corresponding to multiple Callista units) in a single LMS unit.

CMO/HIVE will be under the same Siteminder Single Sign-on instance as Moodle.

QuestionMark Perception Integration

This integration will use the off-the-shelf Moodle QuestionMark Perception Connector.

All student access to QuestionMark Perception will be via the LMS and using the QuestionMark Perception Connector.

QuestionMark Perception will manage content for “LMS units” and not “Callista units”.

It is assumed that

The QuestionMark Perception connector will work with QuestionMark Perception 5 and Moodle 2.1

The connector will meet UWA’s requirements


C49

1.3 Physical Configuration

Google Apps(student mail)

Netspot (192.160.71.0/24) UWA (130.95.0.0/16)

Netspot DNSnetspot.com.au

uwa‐mdl‐prod.srv.netspot.com.au

uwa‐mdl‐uat.srv.netspot.com.au

uwa‐mdl‐dev.srv.netspot.com.au

UWA DNS (Nixu)uwa.edu.au

moodle.uwa.edu.au

test.moodle.uwa.edu.au

dev.moodle.uwa.edu.au

CNAME

CNAME

CNAME

SSH TunnelFor DB Views only

Callista DB / OLCR DB(Oracle)

Moodle

Scheduled Tasks for DB

Views

Other Integrations

Other Integrations

Internet (application‐layer encryption)For all other integrations

192.160.71.20 130.95.???.???

SFTP Server

List of Users (for bulk load)

Moodle DB Dump(for archive)

SFTP PUT

SFTP GET

Internet (application‐la

yer encryption)

Server Load Balancer

test.moodle.uwa.edu.au SSL Certificate

moodle.uwa.edu.au SSL Certificate

dev.moodle.uwa.edu.au SSL Certificate

EmailMail Gateway

(Ironport)SMTP/TLS

?? Tunnel for SiteMinder

Figure 6 - Physical Integration

Address Space

All Netspot hosted parts of the service will reside on Netspot address space. All UWA hosted parts of the service will reside on UWA address space.

Netspot have configured the required internal service domain names, which will be managed by Netspot.

UWA will configure 3 new entries in our DNS, with CNAME records pointing to the Netspot DNS. These are:

moodle.uwa.edu.au CNAME uwa-mdl-prod.srv.netspot.com.au

test.moodle.uwa.edu.au CNAME uwa-mdl-uat.srv.netspot.com.au

dev.moodle.uwa.edu.au CNAME uwa-mdl-dev.srv.netspot.com.au

Connectivity and Encryption

All connectivity will be over the Internet. Netspot’s traffic provider is peered with AARNet, so all traffic will be unmetered.

In general, application interfaces will be encrypted at the application-layer. This includes:

All web services to run over HTTPS

Moodle connectors will encrypt communication to Google Apps, QuestionMark Perception and Echo

Ad hoc and infrequent file transfers will be over SFTP

Siteminder will manage encryption between the Web Agent and Policy Server (is a tunnel required)


C50

Mail will be sent with the application connecting directly to UWA mail gateway, using SMTP (with TLS)

Oracle DB views will be accessed only through an SSH tunnel.

Certificates

UWA will provide all security certificates required for Netspot. These are:

SSL certificate(s) required for moodle.uwa.edu.au, test and development, used on the Netspot Server Load Balancer for SSL offloading

OAuth certificate for Google Apps, to be used by the Google Apps Connector

Archive

A copy of the Moodle DB backup will be taken every six months by Netspot. UWA will download this file from the Moodle SFTP server, and retain a copy of it for archive purposes.

When the archive needs to be restored, UWA will upload the file back to the Netspot SFTP server, and Netspot will manually restore the file into a temporary Moodle environment.

2 Checklist

Question Answer

Do any Architecture documents need updating as a result of this work?

No

What shared components are being used? Portal, FIM, SiteMinder SSO, Ironport

Does this comply with all relevant policies and standards?

Yes

Are you seeking an exemption from any policy or standard?

No

Is this part of a bigger program of work? If yes, describe the program of work.

The LMS project also has streams to cover Moodle configuration, implementation, and use at UWA

Will this negatively impact any other systems, services or applications, including performance or network impacts? If yes, provide a brief overview of the impacts.

No

Will this impact day-to-day work or other business practices carried out by the University – including administrative, research or teaching and learning? If yes, provide a brief overview of the impacts.

Yes – these will be covered by CATL under the greater LMS project

Are there any particular security or privacy requirements, including confidential information, encryption or auditing? If yes, provide a brief overview of the requirements.

Unknown

Does the solution require any changes to DR or business continuity planning? If yes, provide a brief overview of changes required.

No


C51


Question Answer

Is there sufficient capacity for usage volumes including growth over the next 3 years (this includes storage and performance)? If no, provide a brief overview of extra capacity required.

Unknown

When will the system be used? 24x7

What is the expected lifespan of the system? 4 years

Will additional ongoing support be required (additional staffing)? If yes, provide a brief overview of the requirements.

No

Have ongoing maintenance, monitoring, changes to operations been planned?

Yes

Will any systems be decommissioned as a result of this work? If yes, list which systems, and when they are planned to be decommissioned.

Yes, WebCT

3 Appendix 1 – Contacts Please note: All communication with Netspot staff must go via Victor Herrera (Project Manager, Netspot) and Shannon Johnston (Project Manager, UWA). All communication with UWA staff must go via Steve Howe (Project Manager, UWA).

Moodle - Luke Tucker (Netspot)

Google Apps - Michael Simmons (UWA), Brian Poleykett (UWA)

Portal - Michael Simmons (UWA), Brian Poleykett (UWA)

FIM - Brad Rosman (UWA), Ling Lee (UWA), Brian Poleykett (UWA)

Siteminder - Nic Mayhew (UWA), Daniel Foster (UWA)

QuestionMark Perception - Diana Jonas-Dwyer (UWA)

Echo - Daniel Foster (UWA), Damyon Weise (Netspot)

HIVE/CMO - Arlene Raz (UWA), Keith Falloon (UWA), Brian Poleykett (UWA), eXact Technologies

Callista - Richard Styles (UWA), Brian Poleykett (UWA)

OLCR - Michael Simmons (UWA), Brian Poleykett (UWA)

Email - Toivo Pedaste (UWA), Mark Curtis (UWA)

Archive Data - Daniel Foster (UWA)

Student Photos - Richard Styles (UWA), Brian Poleykett (UWA)

Network – Marshall Cowan (Netspot), Mark Curtis (UWA)

Architecture - Damian Bramanis (UWA)

C52

This proposal has been specifically prepared for limited

distribution. This document contains material and

information which NetSpot considers confidential,

proprietary and significant for the protection of its

business. The distribution of this document is limited

solely to employees actively involved in the delivery of

this project.

The information contained within this document is

accurate to the best knowledge of the authors as of the

day of publishing. However, the information is subject to

change without notice.

2011 NetSpot Pty Ltd. All Rights Reserved

Moodle Configuration Document University of Western Australia

V1.0

1 August 2011

Edited by:

eLearning Development and Support

Centre for the Advancement of Teaching & Learning

University of Western Australia

M401

35 Stirling Highway

CRAWLEY 6009

T: +61 (08) 6488 8166

F: +61 (08) 6488 5099

E: [email protected]

C53

Contents Overview .................................................................................................................................................4

Site layout ...............................................................................................................................................6

Default ‘Moodle Frontpage (a.k.a login, entry page) layout ..............................................................6

Default ‘My Moodle’ layout................................................................................................................9

Default ‘Unit’ layout..........................................................................................................................10

Front Page settings ...........................................................................................................................11

Category structures............................................................................................................................... 12

User configuration ................................................................................................................................14

Personal profile fields .......................................................................................................................14

User settings .....................................................................................................................................16

Authentication ......................................................................................................................................17

Manual Accounts ..............................................................................................................................18

Manual Accounts ..............................................................................................................................19

LDAP Server.......................................................................................................................................19

Data Mapping....................................................................................................................................22

Roles Specific Permissions ....................................................................................................................24

Developer......................................................................................................................................42

Lecturer/Unit Coordinator ............................................................................................................42

Tutor..............................................................................................................................................42

Student..........................................................................................................................................42

Archived Student...........................................................................................................................42

Category context roles ......................................................................................................................43

Faculty Administrator ...................................................................................................................43

Site‐wide context roles .....................................................................................................................43

Central Admin ............................................................................................................................... 43

Staff Help Desk..............................................................................................................................43

Student Help Desk.........................................................................................................................43

Guest .............................................................................................................................................43

Role allocations .................................................................................................................................43

Security .................................................................................................................................................43

Course configuration.............................................................................................................................48

C54

Default course configuration ............................................................................................................48

Course settings..................................................................................................................................48

Modules ................................................................................................................................................49

Module settings ....................................................................................................................................50

Blocks ....................................................................................................................................................62

Available blocks.................................................................................................................................62

Disabled blocks .................................................................................................................................64

Enrolments............................................................................................................................................69

Filters ....................................................................................................................................................70

Portfolios...............................................................................................................................................73

Repositories ..........................................................................................................................................73

Backups .................................................................................................................................................75

Grades ...................................................................................................................................................78

General settings ................................................................................................................................78

Grade categories ............................................................................................................................... 79

Grade items.......................................................................................................................................80

Scales.................................................................................................................................................81

Outcomes..........................................................................................................................................81

Letters ...............................................................................................................................................82

Grader report ....................................................................................................................................82

Overview report ................................................................................................................................84

User report........................................................................................................................................84

Location settings ...................................................................................................................................85

Language settings .................................................................................................................................86

General language settings.................................................................................................................86

Language packs .................................................................................................................................86

Language customisation ...................................................................................................................87

Themes..................................................................................................................................................87

Appearance ...........................................................................................................................................88

Advanced settings .................................................................................................................................91

Server ....................................................................................................................................................93

C55

Overview The first step in any large‐scale Moodle deployment is to establish how many requirements can be

achieved through configuration of the ‘out of the box’ Moodle deployment, as shown on the

diagram below as the second step in the hierarchy of meeting project requirements.

The configuration process serves first and foremost as a requirements gathering exercise, where the

specific needs of the client are discussed and mapped against the configurable possibilities of

Moodle. Where a required outcome cannot be met by a suitable configuration of Moodle, this

requirement is documented and then fed into the Integration and Customisation processes,

whereby additional features can be scoped and delivered based on the priorities of the client.

C56

This document exists within a context of several other information sources which combine to form

the formal documentation of the Moodle environment for UWA. These other sources include:

‐ The Integration Document, which details as appropriate the necessary integration points

between Moodle and other systems; and

‐ The Customisation Document, which details as appropriate any customisations made to the

environment, including any third‐party plugins.

Project

Initiation

Initial

Training

Config.

Process

Informs

InformsIntegration

Process

Dev.

Process

Environment

Documentation

The initial configuration workshop was held in early May 2011 with representatives of the project

team. As often happens with initial configuration workshops, many questions were raised for the

project team which required further consultation before a decision could be made on the required

configuration item, hence this initial document is primarily a reflection of the questions raised.

C57

Site layout The MyMoodle view will be used as the default interface for all users in the UWA Moodle environment due to its flexible, user‐centric properties.

Default ‘Moodle Frontpage (a.k.a login, entry page) layout

This page is still under development and will require the design support of UWA’s weboffice.

The Moodle frontpage is the initial entry point into the LMS for entry other than MyUWA web portable. This page will be publicly accessible.

Moodle Frontpage can be a either splash page (Example 1) or a Moodle site (Example 2). Decision is yet to be finalised.

Example 1: Splash page by University of Canberra

(https://learnonline.canberra.edu.au/login/index.php)

Features:

The splash page is a webpage and not a Moodle page.

If you refresh the login page, a different background image will be

displayed.

Either Web office or Netspot is able to develop this page.

Cons: Unable to add Moodle blocks on this page.

C58

of 98

Example 2: Standard Moodle login page

Flinders page

(http://flo2012.flinders.edu.au)

Netspot page

(http://moodle2.netspot.com.au/login/index.php)

UNSW page

(https://moodle2.telt.unsw.edu.au/login/index.php)

Features:

Simple and clean

C59

of 98

Uses a Moodle page

Tabs or links under the banner section. These tabs and links will stay on all Moodle pages.

A drop‐down menu when you click on the tab or link.

Example 3: Standard Moodle open page

(http://moodle.yorksj.ac.uk/mod/forum/discuss.php?d=8520&yorkstjo

hncolour=grey)

Features

Using a Moodle open page (i.e. everyone can access the page)

Users are able to change the colour and font size (see top right)

Ability to add Moodle blocks (e.g. search forum)

As it is not a login page, users need to login to a different page (see

the link at the end of page)

What UWA Web Office needs to supply?

Relevant Image (if UWA will use splash page)

C60

of 98

Color codes

UWA logos

Text

The recommended layout for UWA frontpage is using the standard Moodle login page. The main reason is that the standard Moodle login page is simple

and has similarities with the current LMS login page.

Note: The “log in as guest” button should be removed from the Moodle Frontpage as UWA will create a guest login to access certain units.

Default ‘My Moodle’ layout

Docking will be disabled. Other universities have reported that when docking is enabled, many users contact the helpdesk to find their ‘missing’

(docked) blocks.

The default for My Moodle view for student and staff accounts will be as follows:

C61

of 98

Default ‘Unit’ layout

Docking will be disabled. Other universities have reported that when docking is enabled, many users contact the helpdesk to find their ‘missing’

(docked) blocks.

Sticky blocks are Announcement, Calendar, HTML, and Activities. These sticking blocks are default and cannot be removed by users.

The default for Unit view for all student accounts will be as follows:

C62

of 98

Front Page settings

CI Description Default Actual Notes

fullname Full site name Empty The University of Western Australia

To reflect the official name of the UWA Moodle environment YB: text description eg: “Flinders Learning Online”.

shortname Short name for site (eg single word) Empty UWA YB: eg: “FLO”

summary This description of the site will be displayed on the front page.

Empty

frontpage The items selected above will be displayed on the site's front page.

None This will depend on the openness of the UWA Moodle site and what should be made open for public access.

C63

of 98

frontpageloggedin The items selected above will be displayed on the site's front page when a user is logged in.

None Only relevant for Admin users as all others will be using the My Moodle view.

maxcategorydepth This specifies the maximum depth of child categories shown

Unlimited 1 YB: Flinders ex: ‐ Current Courses – Past Courses – Future Courses

numsections If selected, a topic section will be displayed on the site's front page.

Yes Yes Only relevant to Admins.

newsitems News items to show 3 3

commentsperpage Comments displayed per page 15 15 YB: limited to certain people

coursesperpage Enter the number of courses to be display per page in a course listing.

20 20

defaultfrontpageroleid Default frontpage role None None YB: Open

Category structures UWA are currently going through a transition to a new course structure, and hence the most common alignment between Moodle’s category structure and

the faculty structure within the University requires further thought.

Category = Faculty/School/Centre

Centre for the Advancement of Teaching and Learning

Information Literacy

School of Indigenous Studies

Faculty of Architecture, Landscape and Visual Design

Faculty of Arts, Humanities and Social Sciences

Faculty of Business

Faculty of Education

Faculty of Engineering, Computing and Mathematics

Faculty of Law

C64

of 98

Faculty of Life and Physical Sciences

Faculty of Medicine, Dentistry and Health Sciences

Faculty of Natural and Agricultural Sciences

The ability to allocate roles will vary based on where the user is in Moodle, and who is attempting to perform the allocation.

Callista Open access Study skills OSDS Sandpit Collabor‐ation

Unenrolled Visibility (i.e. can the user see these kinds of units when not enrolled)

X Mixed No X

Enrollability (i.e. what enrolment methods are required for this kind of unit).

Integration Unidentified Self

Self Manual Manual (for staff) Self or manual

Unenrolled access X X X No

Creation Via callista only Manual Manual Manual Manual / Request

C65

of 98

User configuration

Personal profile fields

Moodle provides a range of personal profile fields, some of which may require ‘locking down’ from editing and some which should be removed completely.

Discuss:

Which will be populated from the integration?

Which will be viewable/editable/accessible by users?

Which will be displayed to other users?

For editable fields, the default settings?

Configuration Item (CI)

Description Visible (self/admin)

Visible (others)

Editable Default Notes

username Moodle username Yes No No N/A Populated via integration.

password Moodle password No No No N/A LDAP

firstname First name Yes Yes No N/A Populated via integration.

lastname Last name Yes Yes No N/A Populated via integration.

email Email address Yes Optional No N/A Populated via integration.

emaildisplay Should other users be able to see a user’s email address?

Yes No Yes No YB: Students should elect to show their email addresses to others

emailactivated Is the email address active? Yes No Yes Yes

emailformat Email format Yes No Yes Pretty HTML

emaildigest Email digest type Yes No Yes Daily, subjects

forumautosubscribe Should a user automatically subscribe to a forum upon posting?

Yes No Yes Yes

forumtracking Show unread posts to a user? Yes No Yes Yes

C66

of 98

textediting Use an HTML editor when editing text?

Yes No Yes ‘Use HTML editor’

ajax Use AJAX and javascript? Yes No Yes Yes

screenreader Use a screen reader? Yes No Yes No

city City/town Yes Yes No Populated from Callista

country Country Yes Yes No Populated from Callista

YB: Populated

description Free text user description Yes No No Do not show YB: “About Me” – privacy issues don’t show

timezone Timezone Yes No No Server’s local time

Need to put more information on the page re implications of changing this

lang Preferred language? No No No System default

theme Preferred theme? No No No System default

picture User Picture Yes Optional No Empty Cannot upload a private image but able to opt using ID Card photos Empty initially Need to investigate using ID card photos

interests List of Interests No No No Disable Remove completely

url Web page Yes Yes Yes Students: emptyStaff: webpage

icq ICQ Number No No No Disable Remove completely

skype Skype ID No No No Disable Remove completely

aim AIM ID No No No Disable Remove completely

yahoo Yahoo ID No No No Disable Remove completely

msn MSN ID No No No Disable Remove completely

idnumber ID number Possibly rename (depending on integration)

institution Institution Yes No No Name of Internal tagging only

C67

of 98

University (from integration)

department Department Yes Yes Yes Disable Remove completely

phone1 Phone Yes Yes Yes Disable Remove completely

phone2 Mobile Phone Yes Yes Yes Disable Remove completely

address Address Yes Yes Yes Disable Remove completely

User settings

Configuration Item (CI)

Description Default Actual Notes

newprofilefields Custom profile fields created Nil Nil YB: No need for custom profile fields to be created at this time?

cohorts Cohorts (site‐wide groups) defined Nil To be defined by UWA.

Will cohorts need to be used for any function within UWA? YB: We will use cohorts. Category or course level?

notloggedinroleid Users who are not logged in to the site will be treated as if they have this role granted to them at the site context.

Guest Guest

guestroleid This role is automatically assigned to the guest user.

Guest Guest

defaultuserroleid All logged in users will be given the capabilities of the role you specify here, at the site level

Auth user Auth user

nodefaultuserrolelists This setting prevents all users from being returned from the database from deprecated calls of get_course_user, etc

No No

creatornewroleid This role is automatically assigned to creators in new courses they created.

editingteacher Lecturer Lecturer in UWA’s terminology

autologinguests Should visitors be logged in as guests automatically when entering courses with guest access?

No No

C68

of 98

hiddenuserfields Which user information fields to hide from other users other than course teachers/admins.

Nil Define in the User Profile section. YB: Questions?

extrauserselectorfields Fields which are searched and displayed, in addition to full names, when selecting users.

Email Email

Authentication Authentication methods to be used are as follows:

1. Manual accounts:

2. LDAP:

3. <Define and document>


Common Settings

registerauth If an authentication plugin, such as email‐based self‐registration, is selected, then it enables potential users to register themselves and create accounts. This results in the possibility of spammers creating accounts in order to use forum posts, blog entries etc. for spam. To avoid this risk, self‐registration should be disabled or limited by Allowed email domains setting.

Disable Disable

guestloginbutton You can hide or show the guest login button on the login page. Show Hide

alternateloginurl If you enter a URL here, it will be used as the login page for this site. The page should contain a form which has the action property set to 'http://uwa2.moodlesites.com/login/index.php' and return fields username and password. Be careful not to enter an incorrect URL as you may lock yourself out of this site. Leave this setting blank to use the default login page.

Empty Empty

C69

of 98

forgottenpasswordurl If you enter a URL here, it will be used as the lost password recovery page for this site. This is intended for sites where passwords are handled entirely outside of Moodle. Leave this blank to use the default password recovery.

Empty Empty

auth_instructions Here you can provide instructions for your users, so they know which username and password they should be using. The text you enter here will appear on the login page. If you leave this blank then no instructions will be printed.

Empty Empty

allowemailaddresses If you want to restrict all new email addresses to particular domains, then list them here separated by spaces. All other domains will be rejected. To allow subdomains add the domain with a preceding '.'. eg ourcollege.edu.au .gov.au

Empty Empty

denyemailaddresses To deny email addresses from particular domains list them here in the same way. All other domains will be accepted. To deny subdomains add the domain with a preceding '.'. eg hotmail.com yahoo.co.uk .live.com

Empty Empty

verifychangedemail Enables verification of changed email addresses using allowed and denied email domains settings. If this setting is disabled the domains are enforced only when creating new users.

Yes Yes

recaptchapublickey String of characters used to display the reCAPTCHA element in the signup form. Generated by http://recaptcha.net

Empty Empty

recaptchaprivatekey String of characters used to communicate between your Moodle server and the recaptcha.net server. Obtain one for this site by visiting http://recaptcha.net

Empty Empty

Manual Accounts

Lock User Fields

You can lock user data fields. This is useful for sites where the user data is maintained by the administrators manually by editing user records or uploading using the 'Upload users' facility. If you are locking fields that are required by Moodle, make sure that you provide that data when creating user accounts or the accounts will be unusable.

C70

of 98

Consider setting the lock mode to 'Unlocked if empty' to avoid this problem.

Field Status

Surname Unlocked

First Name Unlocked

Email address Unlocked

Unlocked City/town Unlocked

Country Unlocked

Language Unlocked

Description Unlocked

Web page Unlocked

ID number Unlocked

Institution Unlocked

Department Unlocked

Phone 1 Unlocked

Phone 2 Unlocked

Address Unlocked

Manual Accounts

Auxiliary plugin that prevents user to login into system and also discards any mail sent to the user. Can be used to suspend user accounts.

LDAP Server

C71

of 98

This method provides authentication against an external LDAP server. If the given username and password are valid, Moodle creates a new user entry in its

database. This module can read user attributes from LDAP and prefill wanted fields in Moodle. For following logins only the username and password are

checked. Note: This is currently disabled / hidden.


LDAP server settings

Host URL Specify LDAP host in URL‐form like 'ldap://ldap.myorg.com/' or 'ldaps://ldap.myorg.com/' Separate multipleservers with ';' to get failover support.

Blank Blank

Version The version of the LDAP protocol your server is using. 3 3

LDAP encoding Specify encoding used by LDAP server. Most probably utf‐8, MS AD v2 uses default platform encoding such as cp1252, cp1250, etc.

utf‐8 utf‐8

Bind settings

Hide passwords Select yes to prevent passwords from being stored in Moodle's DB. No No

Distinguished name If you want to use bind‐user to search users, specify it here. Something like 'cn=ldapuser,ou=public,o=org'

Blank Blank

Password Password for bind‐user. Blank Blank

User lookup settings

User type Select how users are stored in LDAP. This setting also specifies how login expiration, grace logins and user creation will work.

Default Default

Contexts List of contexts where users are located. Separate different contexts with ';'. For example: 'ou=users,o=org; ou=others,o=org'

Blank Blank

Search subcontexts Search users from subcontexts. No No

Dereference aliases Determines how aliases are handled during search. Select one of the following values: "No" (LDAP_DEREF_NEVER) or "Yes" (LDAP_DEREF_ALWAYS)

No No

User attribute Optional: Overrides the attribute used to name/search users. Usually 'cn'.

Blank Blank

Member attribute Optional: Overrides user member attribute, when users belongs to a group. Usually 'member'

Blank Blank

Member attribute uses dn Optional: Overrides handling of member attribute values, either 0 or Blank Blank

C72

of 98

1

Object class Optional: Overrides objectClass used to name/search users on ldap_user_type. Usually you dont need to chage this.

Blank Blank

Force change password

Force change password Force users to change password on their first login to Moodle. No No

Use standard page for changing password

If the external authentication system allows password changes through Moodle, switch this to Yes. This setting overrides 'Change Password URL'. NOTE: It is recommended that you use LDAP over an SSL encrypted tunnel (ldaps://) if the LDAP server is remote.

No No

Password format Specify the format of new or changed passwords in LDAP server. Plain Text

Plain Text

Password‐change URL Here you can specify a location at which your users can recover or change their username/password if they've forgotten it. This will be provided to users as a button on the login page and their user page. If you leave this blank the button will not be printed.

Blank Blank

LDAP password expiration settings.

Expiration Select No to disable expired password checking or LDAP to read passwordexpiration time directly from LDAP

No No

Expiration warning Number of days before password expiration warning is issued. 10 10

Expiration attribute Optional: overrides ldap‐attribute that stores password expiration time

Blank Blank

Grace logins Enable LDAP gracelogin support. After password has expired user can login until gracelogin count is 0. Enabling this setting displays grace login message if password is expired.

No No

Grace login attribute Optional: Overrides gracelogin attribute Blank Blank

Enable user creation

Create users externally New (anonymous) users can create user accounts on the external authentication source and confirmed via email. If you enable this , remember to also configure module‐specific options for user creation.

No No

Context for new users If you enable user creation with email confirmation, specify the context where users are created. This context should be different

Blank Blank

C73

of 98

from other users to prevent security issues. You don't need to add this context to ldap_context‐variable, Moodle will search for users from this context automatically. Note! You have to modify the method user_create() in file auth/ldap/auth.php to make user creation work

Course creator

Creators List of groups or contexts whose members are allowed to create new courses. Separate multiple groups with ';'. Usually something like 'cn=teachers,ou=staff,o=myorg'

Blank Blank

Cron synchronization script

Removed ext user Specify what to do with internal user account during mass synchronization when user was removed from external source. Only suspended users are automatically revived if they reappear in ext source.

Keep Internal

Keep Internal

NTLM SSO

Enable Set to yes to attempt Single Sign On with the NTLM domain. Note: this requires additional setup on the webserver to work, see http://docs.moodle.org/en/NTLM_authentication

No No

Subnet If set, it will only attempt SSO with clients in this subnet. Format: xxx.xxx.xxx.xxx/bitmask. Separate multiple subnets with ',' (comma).

Blank Blank

MS IE fast path? Set to yes to enable the NTLM SSO fast path (bypasses certain steps and only works if the client's browser is MS Internet Explorer).

No No

Authentication type The authentication method configured in the web server to authenticate the users (if in doubt, choose NTLM)

NTLM NTLM

Data Mapping

These fields are optional. You can choose to pre‐fill some Moodle user fields with information from the LDAP fields that you specify here. If you leave these

fields blank, then nothing will be transferred from LDAP and Moodle defaults will be used instead. In either case, the user will be able to edit all of these

fields after they log in.

C74

of 98

Field Mapping Update Local Update External Lock Value

First Name The name of the attribute that holds the first name of your users in your LDAP server. This is usually givenName or displayName

On creation Never Unlocked

Surname The name of the attribute that holds the surname of your users in your LDAP server. This is usually sn.


Email address The name of the attribute that holds the email address of your users in your LDAP server. This is usually mail.


Unlocked City/town The name of the attribute that holds the city/town of your users in your LDAP server. This is usully l (lowercase L) or localityName (not valid in MS‐AD).


Country The name of the attribute that holds the country of your users in your LDAP server. This is usully c or countryName (not valid in MS‐AD).


Language preferredLanguage On creation Never Unlocked

Description description On creation Never Unlocked

Web page On creation Never Unlocked

ID number On creation Never Unlocked

Institution On creation Never Unlocked

Department The name of the attribute that holds the department name of your users in your LDAP server. This is usully departmentNumber (for posixAccount and maybe eDirectory) or department (for MS‐AD).


Phone 1 The name of the attribute that holds the telephone number of your users in your LDAP server. This is usually telephoneNumber.


Phone 2 The name of the attribute that holds an additional telephone number of your users in your LDAP server. This can be homePhone, mobile, pager, facsimileTelephoneNumber or even others.


Address The name of the attribute that holds the street address of your users in your LDAP server. This is usully streetAddress or street'.


Update local: If enabled, the field will be updated (from external auth) every time the user logs in or there is a user synchronization. Fields set to update

locally should be locked.

Lock value: If enabled, will prevent Moodle users and admins from editing the field directly. Use this option if you are maintaining this data in the external

auth system.

C75

of 98

Update external: If enabled, the external auth will be updated when the user record is updated. Fields should be unlocked to allow edits.

Note: Updating external LDAP data requires that you set binddn and bindpw to a bind‐user with editing privileges to all the user records. It currently does

not preserve multi‐valued attributes, and will remove extra values on update.

Roles Specific Permissions A critical element of Moodle is the deployment of an appropriate role structure to meet the needs of the institution. The roles used at UWA will be aligned

with the roles stored in Student2?

Activity: Assignment Label Description Developer Lecturer Tutor Student Guest

mod/assignment:exportown submission

Export own submission

Allows a user to export a copy of their submission to ePortfolio or download to a copy to their computer

0 0 0 1 0

mod/assignment:grade Grade assignment This allows a user to grade assignments 0 1 1 0 0

mod/assignment:submit Submit assignment This allows a user to submit assignments 0 0 0 1 0

mod/assignment:view View assignment This allows a user to view assignments 1 1 1 1 1

Developer: Is allowed to view assignments.

Lecturer: Is allowed to view and grade assignments.

Tutor: Is allowed to view and grade assignments.

Student: Is allowed to view and submit assignments, and export their own assignments to a portfolio or computer.

Guest: Is allowed to view assignments.

Activity: Book Label Description Developer Lecturer Tutor Student Guest

mod/book:edit Edit book chapters 1 1 0 0 0

mod/book:exportimscp Export book as IMS content package

1 1 0 0 0

C76

of 98

mod/book:import Import chapters 1 1 0 0 0

mod/book:print Print book 1 1 1 1 0

mod/book:read Read book 1 1 1 1 1

mod/book: viewhiddenchapters

View hidden book chapters

1 1 0 0 0

Developer: Can edit book chapters, import/export book chapters as well as view hidden, read and print book chapters. Can do everything.

Lecturer: Can do everything.

Tutors and Students: Can read and print book chapters.

Guests: Can only read book chapters.

Activity: Certificate Description Developer Lecturer Tutor Student Guest

mod/certificate:manage Manage Certificate 1 1 0 0 0

mod/certificate:printteacher Print Teacher Does this mean print certificate? 1 1 1 1 0

mod/certificate:view View Certificate 0 1 1 1 0

Activity: Chat Label Description Developer Lecturer Tutor Student Guest

mod/chat:chat Access a chat room This allows a user to chat 0 1 1 1 0

mod/chat:deletelog Delete chat logs This allows a user to delete chat logs 0 1 0 0 0

mod/chat:exportparticipatedsession

Export chat session which you took part in

This allows a user to export or download the logs for any chat session they participated in

0 1 0 0 0

mod/chat:exportsession Export any chat session

This allows a user to export or download all chat session logs

0 1 0 0 0

mod/chat:readlog Read chat logs This allows a user to read chat logs 0 1 1 0 0

C77

of 98

Developer: Is not allowed to do anything.

Lecturer: Is allowed to chat, and view/delete/export any chat logs.

Tutor: Is allowed to chat, and view chat logs.

Student: Is allowed to chat.

Guest: Is not allowed to do anything.

Activity: Choice Description Developer Lecturer Tutor Student Guest

mod/choice:choose Record a Choice This allows a user to choose a choice option

0 1 1 1 0

mod/choice:deleteresponses Delete Responses This enables a user to delete choice responses

0 1 0 0 0

mod/choice:downloadresponses

Download Responses This allows a user to download choice responses

0 1 0 0 0

mod/choice:readresponses Read Responses The allows a user to view choice responses

1 1 1 1 1

Developer: Is allowed to read responses to choices.

Lecturer: Is allowed to record and read responses to a choice, and download/delete choices.

Tutor: Is allowed to record and read responses to a choice. Is not allows to download/delete choices.

Student: Is allowed to record and read responses to a choice.

Guest: Is allowed to read responses to a choice.

Activity: Database Description Developer Lecturer Tutor Student Guest

mod/data:approve Approve unapproved entries

This allows a user to approve database activity module entries

0 1 1 0 0

mod/data:comment Write comments This allows a user to add comments to database activity module entries. By default, students are allowed to add comments. If you only want teachers to

0 1 1 1 0

C78

of 98

be able to add comments, you can prevent this capability with a student role override.

mod/data:exportallentries Export all database entries

Allows user to export all / selected entries.

1 1 0 0 0

mod/data:exportentry Export a database entry

Export a single entry to a portfolio. 1 1 0 0 0

mod/data:exportownentry Export own database entry

Allows a user to export their entries to a portfolio.

1 0 0 1 0

mod/data:managecomments Manage comments This allows a user to edit and delete database activity module comments.

0 1 0 0 0

mod/data:manageentries Manage entries This allows a user to manage database activity module entries. (delete / edit)

1 1 0 0 0

mod/data:managetemplates Manage templates This allows a user to manage database templates.

1 1 0 0 0

mod/data:manageuserpresets Manage all template presets

This allows a user to manage database presets

1 0 0 0 0

mod/data:rate Rate entries This allows a user to rate database activity module entries.

0 1 1 0 0

mod/data:viewallratings View all raw ratings given by individuals

Raw data – is in addition to aggregate 0 1 0 0 0

mod/data:viewalluserpresets View presets from all users

This allows a user to view database presets from all users. This allows also a user to export entries.

1 1 0 0 0

mod/data:viewanyrating View total ratings that anyone received

0 1 1 0 0

mod/data:viewentry View entries This allows a user to view database activity module entries. This capability is moderated by any submission requirements in the database set‐up, such as the number of entries required before viewing.

1 1 1 1 1

C79

of 98

mod/data:viewrating View the total rating you received

This allows a user to view all database activity module entry ratings.

0 0 0 1 0

mod/data:writeentry Write entries This allows a user to add database activity module entries.

0 1 1 1 0

Developer: Is allowed to view/export(portfolio or file)/edit/delete entries. Can edit/delete templates. Can view/export/edit/delete all user’s presets. Can

export entries.

Lecturer: Is allowed to view/export(portfolio or file)/approve/edit/delete/rate/write entries. Can write/edit/delete comments. Can edit/delete templates.

Cannot manage database presets. Can view/export/edit/delete all user’s presets. Can view any rating, raw or aggregate.

Tutor: Is allowed to view/approve/rate/write entries. Can write comments. Cannot export entries, edit/delete comments. CannoCan view aggregate ratings.

Is NOT allowed to view the raw ratings.

Student: Is allowed to write/view entries. Can export own entries to a portfolio. Can comment on entries. Can view aggregate ratings.

Guest: Can view entries.

Activity: Dialogue Description Developer Lecturer Tutor Student Guest

mod/dialogue:close Close 0 1 0 0 0

mod/dialogue:manage Manage 0 1 0 0 0

mod/dialogue:open Open 0 1 0 0 0

mod/dialogue:participate Participate 0 1 1 1 0

mod/dialogue:participateany Participate in any dialogue

Allows users to participate in dialogues that are not initiated with themselves

0 1 0 0 0

mod/dialogue:viewall View any dialogue Allow users to have read access to dialogues which they are not a participant

0 1 0 0 0

Developer: Cannot do anything.

Lecturer: Can Open, Manage, Close and Participate in Dialogues as well as those not involving themselves.

Tutor and Student: Can participate in dialogues only.

Guest: Cannot do anything.

C80

of 98

Activity: Feedback Description Developer Lecturer Tutor Student Guest

mod/feedback:complete Complete a feedback 0 0 0 1 0

mod/feedback:createprivatetemplate

Create private template

User creates feedback template only usable by them in unit

1 1 0 0 0

mod/feedback:createpublictemplate

Create public template

User creates feedback template usable in multiple units

0 0 0 0 0

mod/feedback:deletesubmissions

Delete completed submissions

User deletes completed feedback submission

1 1 0 0 0

mod/feedback:deletetemplate

Delete template Different public / private 0 0 0 0 0

mod/feedback:edititems Edit items 1 1 0 0 0

mod/feedback:mapcourse Map courses to global feedbacks

(Role based) no unit level override ? ? ? ? ?

mod/feedback:receivemail Receive email notification

? ? ? 0 0

mod/feedback:view View a feedback 1 1 1 1 1

mod/feedback:viewanalysepage

View the analysis page after submit

0 1 1 1 0

mod/feedback:viewreports View reports View report and analysis 0 1 0 0 0

Developer: Can create a private template. Can view/edit/delete feedback submissions.

Lecturer: Can create a private template. Can view/edit/delete feedback submissions. Can view reports and analysis page.

Tutor: Can view feedback submissions. Can view the analysis page.

Student: Can complete/view feedback submission. Can view the analysis page.

Guest: Can view feedback.

Questions: Who can map courses to global feedback? Who receives email notification of feedback?

Mark Bailye was going to find out the answered to these questions, and provide descriptions – To be done August 1st 2011.

Activity: Folder Description Developer Lecturer Tutor Student Guest

C81

of 98

mod/folder:managefiles Manage files in folder module

This allows the user to add, delete, update and move files in the folder.

1 1 0 0 0

mod/folder:view View folder content This allows the user to view the contents of the folder.

1 1 1 1 1

Developer: Can manage and view folders.

Lecturer: Can manage and view folders.

Tutor: Can view folders.

Student: Can view folders.

Guest: Can view folders.

Activity: Forums Description Developer Lecturer Tutor Student Guest

mod/forum:addnews Add news This allows a user to start discussions in a News forum

1 1 0 0 0

mod/forum:createattachment Create attachments This allows a user to create forum attachments

1 1 1 1 0

mod/forum:deleteanypost Delete any posts (anytime)

This allows a user to delete any forum post (at any time)

0 1 0 0 0

mod/forum:deleteownpost Delete own posts (within deadline)

This allows a user to delete their own forum posts within a certain time, usually 30 minutes (set by an administrator in Site policies)

0 1 1 0 0

mod/forum:editanypost Edit any post This allows a user to edit any forum post at any time.

0 1 1 0 0

mod/forum:exportdiscussion Export whole discussion

This allows a user to export an entire discussion thread to a portfolio.

0 1 1 1 0

mod/forum:exportownpost Export own post This allows a user to export any one of the user’s own posts to a portfolio.

0 1 1 1 0

mod/forum:exportpost Export post This allows a user to export any single post to a portfolio.

0 1 1 1 0

mod/forum:initialsubscription Initial subscription This allows a user to be subscribed initially 1 1 1 1 1

C82

of 98

s to forums

mod/forum:managesubscriptions

Manage subscriptions This allows a user to manage forum subscriptions

1 1 1 1 1

mod/forum:movediscussions Move discussions This allows a user to move discussions to another forum.

0 1 0 0 0

mod/forum:postwithoutthrottling

Exempt from post threshold

Threshold refers to a setting in whereby you can cap the number of posts a user can create in a time period (eg: 20 posts max per day). This is set in the individual forum configuration. This capability allows the user to ignore this setting, and post regardless of the threshold block.

0 1 1 0 0

mod/forum:rate Rate posts This allows a user to rate forum posts for forums which allow posts to be rated

0 1 1 1 0

mod/forum:replynews Reply to news This allows a user to reply to posts in a News forum

0 1 0 0 0

mod/forum:replypost Reply to posts This allows a user to reply to forum posts 0 1 1 1 0

mod/forum:splitdiscussions Split discussions This allows a user to split forum discussions. Splitting a discussion means that beginning with the post selected and going to the end of that thread, the posts are cut from the current discussion topic and put into a newly created discussion topic. If discussion has strayed away from the original topic, splitting the discussion can provide new attention and space for the tangent discussion while keeping the original discussion on topic.

0 1 0 0 0

mod/forum:startdiscussion Start new discussions This allows a user to start forum discussions

0 1 1 1 0

mod/forum:viewallratings View all raw ratings given by individuals

This allows a user to view all the original ratings given by users.

0 1 1 0 0

mod/forum:viewanyrating View total ratings that This allows a user to view any aggregated 0 1 1 0 0

C83

of 98

anyone received rating.

mod/forum:viewdiscussion View discussions This allows a user to view forum discussions.

0 1 1 1 1

mod/forum:viewhiddentimedposts

View hidden timed posts

This allows a user to create timed posts i.e. set a display start and end date for a new discussion. It also allows a user to view timed posts while they are hidden.

1 1 1 0 0

mod/forum:viewqandawithoutposting

Always see Q and A posts

This allows a user to view Q and A forum posts without first posting. (By default a Q and A forum requires students to post once before viewing other students' postings. After the initial posting, students can view and respond to others' postings. This feature allows equal initial posting opportunity among all students, thus encouraging original and independent thinking.)

0 1 1 0 0

mod/forum:viewrating View the total rating you received

This allows a user to view their own aggregated forum ratings

0 1 1 1 0

mod/forum:viewsubscribers View subscribers This allows a user to view forum subscribers

0 1 1 0 0

Developers: Can start news discussions. Can create attachments. Can initially be and manage subscriptions. Can view hidden timed posts.

Lecturer. Is allowed to do/view anything to do with forums. Is exempt from thresholds/restrictions on discussions.

Tutor: Is allowed to do/view almost anything to do with forums. Is exempt from thresholds/restrictions on discussions. Cannot add news, delete posts

anytime, move/split discussions and reply to news posts.

Student: Can create attachments. Can export discussions. Can initially be and manage subscriptions. Can rate posts. Can reply to posts. Can start/view

discussions.

Guest: Can initially be and manage subscriptions. Can view discussions.

C84

of 98

Activity: Glossary Description Developer Lecturer Tutor Student Guest

mod/glossary:approve Approve unapproved entries

This allows a user to approve glossary entries

0 1 1 0 0

mod/glossary:comment Create comments This allows a user to add a comment to glossary entries

0 1 1 1 0

mod/glossary:export Export entries This allows a user to export glossary entries to a XML format.

1 1 0 0 0

mod/glossary:exportentry Export single entry This allows a user to export any entries to a portfolio, one at a time.

1 1 0 0 0

mod/glossary:exportownentry Export single entry of yours

This allows a user to export any one of the user’s own entries to a portfolio.

1 1 1 1 0

mod/glossary:import Import entries This allows a user to import glossary entries in XML format.

1 1 0 0 0

mod/glossary:managecategories

Manage categories This allows a user to manage glossary categories

0 1 1 0 0

mod/glossary:managecomments

Manage comments This allows a user to edit or delete comments to glossary entries

0 1 1 0 0

mod/glossary:manageentries Manage entries This allows a user to manage glossary entries

0 1 1 0 0

mod/glossary:rate Rate entries This allows a user to rate glossary entries 0 1 1 0 0

mod/glossary:viewallratings View all raw ratings given by individuals

This allows a user to view all the original ratings given by users.

0 1 1 0 0

mod/glossary:viewanyrating View total ratings that anyone received

This allows a user to view any aggregated rating.

0 1 1 0 0

mod/glossary:viewrating View the total rating you received

This allows a user to view glossary entry ratings

0 1 1 0 0

mod/glossary:write Create new entries This allows a user to add glossary entries. 0 1 1 1 0

Developer: Can export(XML/Portfolio)/import any entry.

Lecturer: Is allowed to do anything related to glossary entries.

Tutor: Is allowed to do anything related to glossary entries. Tutor is NOT allowed to export/import entries.

Students: Can create entries. Can export own entries to a portfolio. Can comment on entries. Students cannot rate enties.

C85

of 98

Guest: Cannot do anything related to glossary entries.

Activity: Lesson Description Developer Lecturer Tutor Student Guest

mod/lesson:edit Edit a lesson activity This allows a user to update lesson settings, add/edit/remove lesson pages, import questions, view lesson reports (via the reports tab) and delete attempts, and grade essay questions (via the grade essays tab).

1 1 1 0 0

mod/lesson:manage Manage a lesson activity

This allows a user to view lesson reports (via the reports tab).

0 1 1 0 0

Developer: Can edit lessons.

Lecturer: Can edit lessons, and view lesson reports.

Tutor: Can edit lessons, and view lesson reports.

Student: Can’t do anything.

Guest: Can’t do anything.

Activity: Quiz Description Developer Lecturer Tutor Student Guest

mod/quiz:attempt Attempt quizzes This allows a user to attempt quizzes. 0 0 0 1 0

mod/quiz:deleteattempts Delete quiz attempts This allows a user to delete quiz attempts 0 1 1 0 0

mod/quiz:emailconfirmsubmission

Get email confirmation when submitting

This allows a user to receive email confirmation of their quiz submission

0 0 0 0 0

mod/quiz:emailnotifysubmission

Get email notification of submissions

This allows a user, usually a teacher, to receive email notification of quiz

0 0 0 0 0

C86

of 98

submissions.

mod/quiz:grade Grade quizzes manually

This allows a user to change the scores on a quiz, and manually grade quiz essay questions.

0 1 1 0 0

mod/quiz:ignoretimelimits Ignores time limit on quizzes

This allows a user unlimited time to attempt a quiz which has a time limit set

0 0 0 0 0

mod/quiz:manage Manage quizzes This allows a user to manage quizzes 1 1 0 0 0

mod/quiz:manageoverrides Manage quiz overrides

This allows a user to override constraints on the quiz for users, such as time limits.

1 1 0 0 0

mod/quiz:preview Preview quizzes This allows a user to preview quizzes. Note: It is currently not possible to allow a user to preview AND attempt quizzes.

1 1 1 0 1

mod/quiz:regrade Regrade quiz attempts This allows a user to overwrite a current grade

0 1 1 0 0

mod/quiz:reviewmyattempts Review your own attempts

This allows a user to review their old quiz attempts, separate from the ability to attempt the quiz.

0 0 0 1 1

mod/quiz:view View quiz information This allows a user to view the quiz introduction but not attempt the quiz itself

1 1 1 1 1

mod/quiz:viewreports View quiz reports This allows a user to view quiz reports 1 1 1 0 0

Developer: Can manage quizzes. Can override. Can preview. Can view quiz introduction. Can view quiz reports.

Lecturer: Can delete attempts. Can grade manually. Can manage quizzes. Can override. Can preview. Can regrade. Can view quiz introduction. Can view quiz

reports.

Tutor: Can delete attempts. Can grade manually. Can preview quizzes. Can regrade. Can view quiz introduction. Can view quiz reports.

Student: Can attempt a quiz. Can review attempts. Can view the quiz introduction.

Guest: Can preview a quiz. Can review attempts. Can view the quiz introduction.

C87

of 98

Activity: Survey Description Developer Lecturer Tutor Student Guest

mod/survey:download Download responses This allows a user to download survey responses

mod/survey:participate Respond to survey This allows a user to participate in a survey

mod/survey:readresponses View responses This allows a user to read survey responses

Please turn the Survey tool off. We would prefer to

use the Feedback tool instead.

Activity: Wiki Description Developer Lecturer Tutor Student Guest

mod/wiki:createpage Create new wiki pages Allow user to create new pages in existing wikis

1 1 1 1 0

mod/wiki:editcomment Add comments to pages

Allow user to add comments in existing wiki pages

0 1 1 1 0

mod/wiki:editpage Save wiki pages Allow user to save pages in existing wikis 1 1 1 1 0

mod/wiki:managecomment Manage wiki comments

Allow user to edit or delete comments in wiki pages

0 1 1 0 0

mod/wiki:managewiki Manage wiki settings Allow user to edit or delete wikis 1 1 0 0 0

mod/wiki:overridelock Override wiki locks This allows a user to override locked wiki pages

0 0 0 0 0

mod/wiki:viewcomment View page comments Allow a user to view comments on wiki pages

1 1 1 1 1

mod/wiki:viewpage View wiki pages Allow a user to view wiki pages 1 1 1 1 1

Developer: Can create/save/edit/view wiki pages. Can edit/delete wikis. Can view comments.

Lecturer: Can create/save/edit/view wiki pages. Can edit/delete wikis. Can add/edit/delete/view comments.

Tutor: Can create/save/edit/view wiki pages. Can add/edit/delete/view comments.

Students: Can create/save/edit/view wiki pages. Can add/view comments.

Guests: Can view wiki pages. Can view comments.

C88

of 98

Activity: Workshop Description Developer Lecturer Tutor Student Guest

mod/workshop:allocate Allocate submissions for review

This allows a user to allocate a submission for assessment and set a weight of the assessment.

0 1 0 0 0

mod/workshop:editdimensions

Edit assessment forms This allows a user to define and modify assessment forms

0 1 0 0 0

mod/workshop:manageexamples

Manage example submissions

This allows a user to submit example submissions, provide a reference assessment of example submissions and see all assessments of example submissions.

0 1 0 0 0

mod/workshop:overridegrades

Override calculated grades

This capability allows a user to override calculated grades for submission, override calculated grades for assessment, run aggregation tasks that calculate grades for submission and grades for assessment, clear aggregated grades and clear assessments.

0 1 0 0 0

mod/workshop:peerassess Peer assess All users with this capability are considered as potential reviewers during the allocation. Submissions can be allocated to these users for assessment. Note that the lack of this permission does not mean that the user is not able to become a reviewer. For example, users with a capability to allocate submissions can assess any submission as they can allocate it to themselves. This allows a user to see instructions for assessment and train assessment process on example submissions.

0 0 0 1 0

mod/workshop:publishsubmissions

Publish submissions This allows a user to publish submissions, that is to make them available when

0 1 0 0 0

C89

of 98

workshop is closed.

mod/workshop:submit Submit This allows a user to see instructions for submitting and submit own work.

0 0 0 1 0

mod/workshop:switchphase Switch phase This allows a user to change the current phase of the workshop.

0 1 0 0 0

mod/workshop:view View workshop This allows a user to see that the workshop exists, see workshop title and eventually some other basic information about it and see workshop introduction during the setup phase.

1 1 1 1 1

mod/workshop:viewallassessments

View all assessments This allows a user to view all assessments in the workshop.

0 1 1 0 0

mod/workshop:viewallsubmissions

View all submissions This allows a user to view all submissions in the workshop.

0 1 1 0 0

mod/workshop:viewauthornames

View author names This allows a user to see the name of submission author. This is typically used to control whether reviewers should know who they are assessing or whether the assessment is anonymous. (Note: view the butchers paper?)

0 1 1 0 0

mod/workshop:viewauthorpublished

View authors of published submissions

This capability allows a user to see the names of authors of published submissions.

0 1 1 0 0

mod/workshop:viewpublishedsubmissions

View published submissions

This allows a user to view published submissions when the workshop is closed.

0 1 1 0 1

mod/workshop:viewreviewernames

View reviewer names This allows a user to see the name of reviewer. This is typically used to control whether submission authors should know who they are assessed by or whether the reviewers are anonymous.

0 1 1 0 0

C90

of 98

Developer: Can view a workshop.

Lecturer: Can do anything with workshops, apart from peer assessment and submitting.

Tutor: Cannot manage example submissions. Cannot override calculated grades. Can view a workshop. Can view the names of authors, published authors

and reviewers. Can view published submissions. Can view all submissions and assessments (but based on groups, should only be able to view their own

groups). Default yes, how do we allow them to see only their own students? Use groups to allow gradebook as well as other activities.

Student: Can peer assess. Can submit. Can view a workshop, cannot view the name of an author or published author, and published submissions and

reviewer. However, permission overrides can be used to allow students to see author, published author and reviewer name.

Grades Description Developer Lecturer Tutor Student Guest

moodle/grade:edit Edit grades This allows a user to turn editing on/off in

the Grader report in order to edit grades

directly or to hide or lock individual

grades.

0 1 1 0 0

moodle/grade:export Export grades This allows a user to export grades of

other users.

0 1 1 0 0

moodle/grade:hide Hide/unhide grades or

items

This allows a user to hide/unhide

individual grades.

0 1 1 0 0

moodle/grade:import Import grades This allows a user to import grades. 0 1 0 0 0

moodle/grade:lock Lock grades or items This allows a user to lock grades. 0 1 0 0 0

moodle/grade:manage Manage grade items This allows a user to manage grade items

and categories in the gradebook (create,

edit, lock, hide, delete, etc.)

0 1 0 0 0

C91

of 98

moodle/grade:manageletters Manage letter grades This allows a user to edit Grade letters. 0 1 0 0 0

moodle/grade:manageoutcom

es

Manage grade

outcomes

This allows a user to manage Outcomes.

For example, when you login as a teacher

you should be able to see a link called

"Outcome" in the Course Administration

block and be able to "manage "Outcome".

0 1 0 0 0

moodle/grade:unlock Unlock grades or

items

This allows a user to unlock grades. 0 1 0 0 0

moodle/grade:view View own grades This allows a user to view their own

grades (in most contexts).

0 1 1 1 0

moodle/grade:viewall View grades of other

users

This allows a user to view all grades of all

users including hidden grades (in a

particular context). It can be also used at

user context.

0 1 0 0 0

moodle/grade:viewhidden View hidden grades

for owner

This allows a user to view grades that are

hidden.

0 1 0 0 0

Developer: Cannot do anything.


Tutor: Can edit/export/hide/manage grades. Can view own grades. A tutor cannot import grades. A tutor cannot manage grade items/categories in the

gradebook (create, edit, lock, hide, delete, etc.). Tutors can view all grades and hidden grades of only their own students (this is facilitated by the use of

groups).

Student: Can view grades.


C92

of 98

Questions Description Developer Lecturer Tutor Student Guest

moodle/question:add Add new questions This allows a user to add questions to a

category, move questions to a category

and import questions.

1 1 0 0 0

moodle/question:editall Edit all questions This allows a user to edit or delete any

question

1 1 0 0 0

moodle/question:editmine Edit your own

questions

This allows a user to edit or delete a

question they have created

1 1 0 0 0

moodle/question:flag Flag questions while

attempting them

1 1 0 0 0

moodle/question:managecate

gory

Edit question

categories

This allows a user to manage category

hierarchies i.e. creating, editing and

moving categories

1 1 0 0 0

moodle/question:moveall Move all questions This allows a user to move their or others'

question to another category

1 1 0 0 0

moodle/question:movemine Move your own

questions

This allows a user to move a question they

have created to another category

1 1 0 0 0

moodle/question:useall Use all questions This allows a user to preview any question

and include it in a Quiz activity

1 1 0 0 0

moodle/question:usemine Use your own

questions

This allows a user to preview a question

they have created and include it in a Quiz

activity

1 1 0 0 0

C93

of 98

moodle/question:viewall View all questions This allows a user to view all questions 1 1 1 1 0

moodle/question:viewmine View your own

questions

This allows a user to view a question they

have created

1 1 0 0 0

Developer: Can do everything.


Tutor: Can view all questions.

Student: Can view all questions.


Developer The Developer is an editor of unit content. They may change unit settings, add, edit or delete content and change the structure of the unit, but may not

assess student work, interact with students or view student contributions within the unit. The Developer role will be based on the default Manager role

within Moodle, but with some capabilities removed to meet the above definition.

Lecturer/Unit Coordinator The Lecturer/Unit Coordinator role provides the capabilities to perform all aspects of editing, assessing and administering at the unit level. It is based on the default Teacher role in Moodle, but without the ability to restore or reset units. For units in the controlled space, Lecturer/Unit Coordinator will have restricted access to edit such fields as Unit Name (both short and long), Unit Code and Unit Description.

Tutor A Tutor can interact with students, view unit content and assess student contributions, but cannot edit any elements of the unit in terms of structure or

content.

Student Students can view content, interact with other students, submit work for assessment and receive grades.

Archived Student Archived Students can view content and previously contributed work (including interactions), but cannot interact with others or submit work for assessment. This role is based on the Student role in Moodle, but with the capability to submit work removed. This is for the purposes of viewing Review Units.

C94

of 98

Category context roles

Faculty Administrator Faculty Administrator to be defined.

Site-wide context roles

Central Admin Standard Moodle Administrator role, including the capability to modify all configuration setting. Ability to perform all user, category, unit and front page

administration functions.

Staff Help Desk Staff Helpdesk To be defined.

Student Help Desk Student Helpdesk to be defined.

Guest Read only access to all units within Moodle.

Role allocations

Unit Coordinators would be allocated via the creation form and then they will be responsible for adding/removing other staff.

Security CI Description Default Actual Notes

IP Blocker

allowbeforeblock By default, entries in the blocked IPs list are matched first. If this option is No No

C95

of 98

enabled, entries in the allowed IPs list are processed before the blocked list.

allowedip Put every entry on one line. Valid entries are either full IP address (such as 192.168.10.1) which matches a single host; or partial address (such as 192.168.) which matches any address starting with those numbers; or CIDR notation (such as 231.54.211.0/20); or a range of IP addresses (such as 231.3.56.10‐20) where the range applies to the last part of the address. Text domain names (like 'example.com') are not supported. Blank lines are ignored.

Empty Empty

blockedip Put every entry on one line. Valid entries are either full IP address (such as 192.168.10.1) which matches a single host; or partial address (such as 192.168.) which matches any address starting with those numbers; or CIDR notation (such as 231.54.211.0/20); or a range of IP addresses (such as 231.3.56.10‐20) where the range applies to the last part of the address. Text domain names (like 'example.com') are not supported. Blank lines are ignored.

Empty Empty

Site Policies

protectusernames By default forget_password.php does not display any hints that would allow guessing of usernames or email addresses.

Yes Yes

forcelogin Normally, the front page of the site and the course listings (but not courses) can be read by people without logging in to the site. If you want to force people to log in before they do ANYTHING on the site, then you should enable this setting.

No No This will be set to ‘No’ in order to meet the need of UWA to have publicly accessible subjects.

forceloginforprofiles This setting forces people to login as a real (non‐guest) account before viewing any user's profile. If you disabled this setting, you may find that some users post advertising (spam) or other inappropriate content in their profiles, which is then visible to the whole world.

Yes Yes

opentogoogle If you enable this setting, then Google will be allowed to enter your site as a Guest. In addition, people coming in to your site via a Google search will automatically be logged in as a Guest.

No No

profileroles List of roles that are visible on user profiles and participation page. Teacher, Non‐editing

Dependent on role definitions.

C96

of 98

teacher, Student (YB: Changed)

maxbytes This specifies a maximum size that uploaded files can be throughout the whole site.

Server Limit

Server Limit

userquota The maximum number of bytes that a user can store in their own private file area.

100Mb 100Mb Will private files be used? YB: Get rid of

enablehtmlpurifier Use HTML Purifier instead of KSES for cleaning of untrusted text. Yes Yes

allowobjectembed As a default security measure, normal users are not allowed to embed multimedia (like Flash) within texts using explicit EMBED and OBJECT tags in their HTML (although it can still be done safely using the mediaplugins filter). If you wish to allow these tags then enable this option.

No No

enabletrusttext By default Moodle will always thoroughly clean text that comes from users to remove any possible bad scripts, media etc that could be a security risk. The Trusted Content system is a way of giving particular users that you trust the ability to include these advanced features in their content without interference. To enable this system, you need to first enable this setting, and then grant the Trusted Content permission to a specific Moodle role. Texts created or uploaded by such users will be marked as trusted and will not be cleaned before display.

No No

maxeditingtime This specifies the amount of time people have to re‐edit forum postings, glossary comments etc.

30 mins 30 mins

fullnamedisplay This defines how names are shown when they are displayed in full. Default is to define the display of names based on the Language pack.

Language Language

extendedusernamechars Enable this setting to allow students to use any characters in their usernames (note this does not affect their actual names). The default is "false" which restricts usernames to be alphanumeric lowercase characters, underscore (_), hyphen (‐), period (.) or at symbol (@).

No Dependent on other authentication settings.

sitepolicy If you have a site policy that all registered users must see and agree to before using this site, then specify the URL to it here, otherwise leave this field blank. This setting can contain any public URL.

Empty Empty

C97

of 98

sitepolicyguest If you have a site policy that all guests must see and agree to before using this site, then specify the URL to it here, otherwise leave this field blank. This setting can contain any public URL.

None None

usetags Should tags functionality across the site be enabled? Yes Yes

keeptagnamecase Check this if you want tag names to keep the original casing as entered by users who created them.

Yes Yes

profilesforenrolledusersonly To prevent misuse by spammers, profile descriptions of users who are not yet enrolled in any course are hidden. New users must enrol in at least one course before they can add a profile description.

Yes Yes

cronclionly If this is set, then the cron script can only be run from the command line instead of via the web.

No Yes No need to allow this from URL – no damage, but potential performance issue.

cronremotepassword This means that the cron.php script cannot be run from a web browser without supplying the password using the following form of URL: http://site.example.com/admin/cron.php?password=opensesame If this is left empty, no password is required.

Empty Empty

disableuserimages Disable the ability for users to change user profile images. No Yes

passwordpolicy Turning this on will make Moodle check user passwords against a valid password policy. Use the settings below to specify your policy (they will be ignored if you set this to 'No')

Yes To be determined – relevant for ‘manual’ accounts.

minpasswordlength Passwords must be at least these many characters long. 8 8

minpassworddigits Passwords must have at least these many digits. 1 0

minpasswordlower Passwords must have at least these many lower case letters. 1 0

Minpasswordupper Passwords must have at least these many upper case letters. 1 0

Minpasswordnonalphanum Passwords must have at least these many non‐alphanumeric characters. 1 0

Maxconsecutiveidentchars Passwords must not have more than this number of consecutive identical characters. Use 0 to disable this check.

0 0

Groupenrolmentkeypolicy Turning this on will make Moodle check group enrolment keys against a valid password policy.

Yes No

C98

of 98

emailchangeconfirmation Require an email confirmation step when users change their email address in their profile.

Yes Yes

HTTP security

loginhttps Turning this on will make Moodle use a secure https connection just for the login page (providing a secure login), and then afterwards revert back to the normal http URL for general speed.

No Yes Common practice to enhance security of password data.

cookiesecure If server is accepting only https connections it is recommended to enable sending of secure cookies.

No

cookiehttponly Enables new PHP 5.2.0 feature ‐ browsers are instructed to send cookie with real http requests only, cookies should not be accessible by scripting languages.

No

excludeoldflashclients Some versions of the Adobe Flash plugin are known to be vulnerable to attacks from malicious Flash content. You can specify a minimum supported version here, and Moodle will not show Flash files to users with lower versions. Instead they will see an alternate Flash file telling them how to upgrade. Leave this empty to disable all checks.

10.0.12 10.0.12

Module security

restrictmodulesfor Which courses should have the setting for disabling some activity modules? Note that this setting only applies to teachers, administrators will still be able to add any activity to a course.

No courses No courses

restrictbydefault Should new courses that are created that fall into the above category have their modules restricted by default?

No No

defaultallowedmodules For the courses which fall into the above category, which modules do you want to allow by default when the course is created?

None None

Notifications

displayloginfailures This will display information to selected users about previous failed logins. None None

notifyloginfailures If login failures have been recorded, email notifications can be sent out. Who should see these notifications?

Nobody Nobody

notifyloginthreshold If notifications about failed logins are active, how many failed login attempts by one user or one IP address is it worth notifying about?

10 10

Anti‐Virus

C99

of 98

runclamonupload When enabled, clam AV will be used to scan all uploaded files. No Check with NetSpot Dev team.

pathtoclam Path to clam AV (when enabled). “

quarantinedir Quarantine directory for failed ClamAV files. “

clamfailureonupload If you have configured clam to scan uploaded files, but it is configured incorrectly or fails to run for some unknown reason, how should it behave?

Treat files as OK

“

Course configuration

Default course configuration

To be determined in relation to subject templates.

Course settings


moodlecourse | format Default course format. Weekly Topics

moodlecourse | numsections

Default number of weeks/topics 10 13 Same as the number of weeks in a standard semester

moodlecourse | hiddensections

Default for how sections should appear Collapsed Collapsed

moodlecourse | newsitems Default number of news items to show 5 3

moodlecourse | showgrades

Show gradebook to students? Yes Yes

moodlecourse | showreports

Show activity reports to authorised users

Yes Yes

moodlecourse | maxbytes Default maximum file upload size for a 100Mb 100Mb Max file upload for both students and staff

C100

of 98

course

moodlecourse | legacyfiles Allow legacy course files feature to be used in all courses.

No No

moodlecourse | groupmode

Default group mode for all new courses. No groups

No groups

moodlecourse | groupmodeforce

Default setting for forcing group mode within a course

No No

moodlecourse | visible Default visibility/access setting for all new courses

No No Often better to make this a conscious choice to open a subject. – Default visibility should not be ‘no’; which leaves it up to the lecturer to remember to make it visible. This should be centrally controlled.

moodlecourse | lang Default for forcing the default language pack in all new courses

No No

moodlecourse | enablecompletion

Default course completion functionality status for all new courses

No No

moodlecourse | completionstartonenrol

Default setting for whether completion tracking for students should commence upon their enrolment within a course

No No

enablecourserequests Should the Course Request feature be enabled?

No No

defaultrequestcategory Default category for all new requested courses

Misc N/A

courserequestnotify Who should be notified when a course is requested.

Nobody N/A

Modules Enable the following modules

C101

of 98

Assignment, (Book – missing from module settings table), (Certificate – missing from module settings table), Chat, (Choice – missing from module settings

table), Database, Dialogue, Feedback, File, Folder, Forum, (Group Selection – missing from module settings table), Glossary, IMS Content Package, (Label ‐

missing from module settings table), Lesson, Page, Quiz, SCORM package, URL, (Wiki – missing from module settings table), Workshop.

Module settings CI Description Default Actual Notes

Assignment

assignment_maxbytes Default maximum assignment size for all assignments on the site (subject to course limits and other local settings)

1Mb 1Mb Suggested size only.

assignment_itemstocount Nature of items to be counted for student submissions in online assignments.

Words Words

assignment_showrecentsubmissions Everyone can see notifications of submissions in recent activity reports.

Yes No Privacy issue if this is left on.

Chat

chat_method The ajax chat method provides an ajax based chat interface, it contacts server regularly for update. The normal chat method involves the clients regularly contacting the server for updates. It requires no configuration and works everywhere, but it can create a large load on the server with many chatters. Using a server daemon requires shell access to Unix, but it results in a fast scalable chat environment.

Ajax YB: ? Normal YB: ?

chat_refresh_userlist YB: ? How often should the list of users be refreshed? (in seconds)

10 10

chat_old_ping YB: ? What is the maximum time that may pass before we detect that a user has

35 35

C102

of 98

disconnected (in seconds)? This is just an upper limit, as usually disconnects are detected very quickly. Lower values will be more demanding on your server.

chat_refresh_room YB: ? How often should the chat room itself be refreshed? (in seconds). Setting this low will make the chat room seem quicker, but it may place a higher load on your web server when many people are chatting. If you are using Stream updates, you can select higher refresh frequencies ‐‐ try with 2.

5 5 These settings matter only if you have selected "Normal method" for chat_method

chat_normal_updatemode YB: ? Chatroom updates are normally served efficiently using the Keep‐Alive feature of HTTP 1.1, but this is still quite heavy on the server. A more advanced method is to use the Stream strategy to feed updates to the users. Using Stream scales much better (similar to the chatd method) but may not be supported by your server.

KeepAlive KeepAlive These settings matter only if you have selected "Normal method" for chat_method

chat_serverhost YB: ? The hostname of the computer where the server daemon is

uwa2.moodlesites.com (note: is this our environment?)

uwa2.moodlesites.com These settings matter only if you have selected "Chat server daemon" for chat_method

chat_serverip YB: ? The numerical IP address that matches the above hostname

127.0.0.1 127.0.0.1 These settings matter only if you have selected "Chat server daemon" for chat_method

chat_serverport YB: ? Port to use on the server for the daemon 9111 9111 These settings

C103

of 98

matter only if you have selected "Chat server daemon" for chat_method

chat_servermax YB: ? Max number of clients allowed 100 100 These settings matter only if you have selected "Chat server daemon" for chat_method

Database

data_enablerssfeeds This switch will enable the possibility of RSS feeds for all databases.

No Yes Enhanced feature, no risk in enabling.

Dialogue

dialogue_trackreadentries Set to 'yes' if you want to track read/unread for each user.

Yes Yes

Feedback

feedback_allowfullanonymous If this option is set yes so the feedback can be completed without any preceding logon. It only affects feedbacks on the homepage.

No No

Folder

folder | requiremodintro Disable this option if you do not want to force users to enter description of each activity.

Yes No we don’t want staff to be forced to enter a description. Yes, disable this option.

We want staff putting in descriptions to be optional.

Forum

forum_displaymode The default display mode for discussions if one isn't set.

Display replies in nested form

Display replies in nested form

forum_replytouser When a forum post is mailed out, should it contain the user's email address so that

Yes No

C104

of 98

recipients can reply personally rather than via the forum? Even if set to 'Yes' users can choose in their profile to keep their email address secret.

forum_shortpost Any post under this length (in characters not including HTML) is considered short (see below).

300 300

forum_longpost Any post over this length (in characters not including HTML) is considered long. Posts displayed on the site front page, social format course pages, or user profiles are shortened to a natural break somewhere between the forum_shortpost and forum_longpost values.

600 600

forum_manydiscussions Maximum number of discussions shown in a forum per page

100 100

forum_maxbytes Default maximum size for all forum attachments on the site (subject to course limits and other local settings)

500kb 1Mb Suggested value only.

forum_maxattachments Default maximum number of attachments allowed per post.

9 9

forum_trackreadposts Set to 'yes' if you want to track read/unread for each user.

Yes Yes

forum_oldpostdays Number of days old any post is considered read.

14 14

forum_usermarksread If 'yes', the user must manually mark a post as read. If 'no', when the post is viewed it is marked as read.

No No

forum_cleanreadtime The hour of the day to clean old posts from the 'read' table.

2 2

forum_enablerssfeeds This switch will enable the possibility of RSS feeds for all forums. You will still

Yes Yes Enhanced feature, no risk in

C105

of 98

need to turn feeds on manually in the settings for each forum.

enabling.

forum_enabletimedposts Set to 'yes' if you want to allow setting of display periods when posting a new forum discussion (Experimental as not yet fully tested)

No No May be worth using when defined as not ‘experimental’. ?

forum_logblocked Forum cron may log blocked attempts to send emails to users with disabled email.

Yes Yes Not in Moodle version? ?

Glossary

glossary_entbypage Entries shown per page 10 10

glossary_dupentries Define if a glossary will allows duplicated entries by default

No No

glossary_allowcomments Define if a glossary will accept comments on entries by default

No No Often a more useful default.

glossary_linkbydefault Define if a glossary should be automatically linked by default

Yes No

glossary_defaultapproval Define the approval status by default of an entry posted by a student

Yes No

glossary_enablerssfeeds This switch will enable the possibility of RSS feeds for all glossaries.

No No Enhanced feature, no risk in enabling.

glossary_linkentries Define if an entry should be automatically linked by default

No No

glossary_casesensitive Define if an entry, when linked, is case sensitive by default

No No

glossary_fullmatch Define if an entry, when linked, should match the case in the target text by default

No No

IMS content package

imscp | requiremodintro Disable this option if you do not want to force users to enter description of each activity.



C106

of 98

imscp | keepold How many packages should be archived? 1 1

Lesson

lesson_slideshowwidth Sets the width of the slideshow if it is enabled

640 640

lesson_slideshowheight Sets the height of the slideshow if it is enabled

480 480

lesson_slideshowbgcolor Background colour to for the slideshow if it is enabled

#FFFFFF #FFFFFF

lesson_mediawidth Sets the width of the popup displayed for a linked media file

640 640

lesson_mediaheight Sets the height of the popup displayed for a linked media file

480 480

lesson_mediaclose Displays a close button as part of the popup generated for a linked media file

No No

lesson_maxhighscores Number of high scores displayed 10 10

lesson_maxanswers Default maximum number of answers per page

4 4

lesson_defaultnextpage The default action to take after a correct answer

Normal ‐ follow lesson path

Normal ‐ follow lesson path

Page

page | requiremodintro Disable this option if you do not want to force users to enter description of each activity.



page | displayoptions Select all options that should be available, existing settings are not modified.

Open Open

page | printheading Display page name above content? Yes Yes

page | printintro Display page description above content? No No

page | display Select display type. Open, Advanced Open, Advanced

page | popupwidth Specifies default width of popup windows (in pixels).

620, Advanced 800, Advanced More common stage size.

page | popupheight Specifies default height of popup 450, Advanced 600, Advanced More common

C107

of 98

windows. stage size.

Quiz

quiz | timelimit Default time limit for quizzes in seconds. 0 means no time limit.

0 0

quiz | attempts Restriction on the number of attempts students are allowed at the quiz.

Unlimited 1 More common default.

quiz | grademethod When multiple attempts are allowed, which method should be used to calculate the student's final grade for the quiz.

Highest grade Highest grade

quiz | maximumgrade The default grade that the quiz grade is scaled to be out of.

10 10

quiz | shufflequestions If you enable this option, then the order of questions in the quiz will be randomly shuffled each time a student attempts the quiz.

No No

quiz | questionsperpage When adding questions to the quiz page breaks will automatically be inserted according to the setting you choose here.

After adding each question

After every question More common default

quiz | shuffleanswers If you enable this option, then the parts making up the individual questions will be randomly shuffled each time a student starts an attempt at this quiz, provided the option is also enabled in the question settings.

Yes Yes

quiz | optionflags If you choose Yes for this option then the student will be allowed multiple responses to a question even within the same attempt at the quiz.

Yes Yes

quiz | penaltyscheme Penalty subtracted for each wrong response in adaptive mode.

Yes, Advanced No, Advanced

quiz | attemptonlast If multiple attempts are allowed then each new attempt contains the results of

No, Advanced No, Advanced

C108

of 98

the previous attempt.

quiz | review These options control what information users can see when they review a quiz attempt or look at the quiz reports.

Everything on Everything on

quiz | showuserpicture Show the user's picture on screen during attempts.

No No

quiz | decimalpoints Number of digits that should be shown after the decimal point when displaying grades for the quiz.

2 2

quiz | questiondecimalpoints Number of digits that should be shown after the decimal point when displaying the grade for individual questions.

Same as for overall grades

Same as for overall grades

quiz | showblocks Show blocks during quiz attempts. No, advanced No, advanced

quiz | password Students must enter this password before they can attempt the quiz.

Blank Blank

quiz | subnet Students can only attempt the quiz from these computers.

Blank Blank

quiz | delay1 If you set a time delay here, the student cannot start their second attempt until this much time has passed since the end of their first attempt.

0 0

quiz | delay2 If you set a time delay here, the student cannot start their third, fourth, ... attempt until this much time has passed since the end of their previous attempt.

0 0

quiz | popup Force the attempt to open in a popup window, and use JavaScript tricks to try to restrict copy and paste, etc. during quiz attempts.

No, advanced No, advanced

File

resource | framesize When a web page or an uploaded file is displayed within a frame, this value is the height (in pixels) of the top frame (which

130 130

C109

of 98

contains the navigation).

resource | requiremodintro Disable this option if you do not want to force users to enter description of each activity.



resource | displayoptions Select all options that should be available, existing settings are not modified.

Automatic, Embed, Force download, Open, In pop‐up

Automatic, Embed, Force download, Open, In pop‐up

resource | printheading Display resource name above content? Some display types may not display resource name even if enabled.

No No

resource | printintro Display resource description bellow content? Some display types may not display description even if enabled.

Yes Yes

resource | display Default display type Automatic Automatic

resource | popupwidth Specifies default width of popup windows.

640 800 More common stage size.

resource | popupheight Specifies default height of popup windows.

450 600 More common stage size.

resource | filterfiles Select type of file content filtering, please note this may cause problems for some Flash and Java applets.

None None

SCORM package

scorm | grademethod This preference sets the default grade method for an activity

Highest Grade Highest Grade

scorm | maxgrade This preference sets the default maximum grade for an activity

100 100

scorm | maxattempts 0 0

scorm | displayattemptstatus This preference sets the default value for the display attempt status setting

No No

scorm | displaycoursestructure This preference sets the default value for the display course structure on entry page setting

No No

C110

of 98

scorm | forcecompleted This preference sets the default value for the force completed setting

No No

scorm | lastattemptlock This preference sets the default value for the lock after final attempt setting

No No

scorm | whatgrade This preference sets the default attempts grading

Highest attempt Highest attempt

scorm | framewidth This preference set the default width for stage frame or window

100% 100%

scorm | frameheight This preference set the default height for stage frame or window

500 500

scorm | popup This preference sets the default of whether to display the package or not for an activity

Current window Current window

scorm | resizable Allow the window to be resized No No

scorm | scrollbars Allow the window to be scrolled No No

scorm | directories Show the directory links No No

scorm | location Show the location bar No No

scorm | menubar Show the menu bar No No

scorm | toolbar Show the toolbar No No

scorm | status No No

scorm | skipview This preference sets the default for when to skip content structure for a page

Never Never

scorm | hidebrowse This preference sets the default for whether to disable or enable the preview mode

No No

scorm | hidetoc This preference sets the default for whether to show or hide the course structure (TOC) in the SCORM player

To the side To the side

scorm | hidenav This preference sets the default for whether to show or hide the navigation buttons

No No

scorm | auto This preference sets the default auto No No

C111

of 98

continue for the activity

scorm | updatefreq This preference sets the default auto‐update frequency of an activity

Never Never

scorm | updatetime 2 2

scorm | allowtypeexternal Enable external package type No No

scorm | allowtypelocalsync Enable downloaded package type No No

scorm | allowtypeimsrepository Enable IMS package type No No

scorm | forcejavascript Force users to enable JavaScript No No

scorm | allowapidebug Activate API debug and tracing (set the capture mask with apidebugmask)

No No

scorm | apidebugmask API debug capture mask ‐ use a simple regex on <username>:<activityname> e.g. admin:.* will debug for admin user only

.* .*

URL

url | framesize When a web page or an uploaded file is displayed within a frame, this value is the height (in pixels) of the top frame (which contains the navigation).

130 130

url | requiremodintro Disable this option if you do not want to force users to enter description of each activity.

Yes No

url | secretphrase This secret phrase is used to produce encrypted code value that can be sent to some servers as a parameter. The encrypted code is produced by an md5 value of the current user IP address concatenated with your secret phrase. ie code = md5(IP.secretphrase). Please note that this is not reliable because IP address may change and is often shared by different computers.

Setting is masked

url | rolesinparams Enable if you want to include localized role names in list of available parameter

No No

C112

of 98

variables.

url | printheading Display URL name above content? Some display types may not display URL name even if enabled.

No No

url | printintro Display URL description bellow content? Some display types may not display description even if enabled.

Yes Yes

url | display Choose display type, unfortunately not all types are suitable for all URLs.

Automatic Automatic

url | popupwidth Specifies default width of popup windows.

620, Advanced 620, Advanced

url | popupheight Specifies default height of popup windows.

450, Advanced 450, Advanced

Workshop

workshop | grade Default maximum grade for submission in workshops

80 80

workshop | gradinggrade Default maximum grade for assessment in workshops

20 20

workshop | gradedecimals Default number of digits that should be shown after the decimal point when displaying grades.

2 2

workshop | maxbytes Default maximum submission file size for all (YB: ?) workshops on the site (subject to course limits and other local settings)

Course upload limit Course upload limit

workshop | strategy Default grading strategy for workshops Accumulative grading Accumulative grading

workshop | examplesmode Default mode of examples assessment in workshops

Assessment of example submission is voluntary

Assessment of example submission is voluntary

workshopallocation_random | numofreviews

Default number of submissions to be randomly allocated

3 3

workshopform_numerrors | grade0 The default word describing the negative assessment of an assertion.

0 0

workshopform_numerrors | grade1 The default word describing the positive Yes Yes

C113

of 98

assessment of an assertion.

workshopeval_best | comparison Default value of the factor that influence the grading evaluation.

Fair Fair

Blocks In the interest of usability and suitability the amount of available blocks were restricted for the initial release as follows:

Available blocks

Block Sticky (Enabled system wide)

Optional (Enabled locally)

Description

Activities Sticky The Activities block lists and allows navigation between the different activities available

in your course (Forums, Quizzes, Assignments, etc.).

The activities list grows as Activities are added to a unit.

As the default for any new unit Forums are always listed in the Activities block.

Calendar Sticky The Calendar block displays the following events:

Site (event viewable in all courses – created by admin users)

Course (event viewable only to course members – created by teachers)

Groups (event viewable only by members of a group – created by teachers)

User (personal event a student user can create – viewable only by the user)

Comments Optional The comments block, in Moodle 2.0 onwards, may be added to any page to allow users to

add comments.

Course completion

status

Optional The course completion status block, in Moodle 2.0 onwards, reports on the completion

status of your courses.

Feedback Optional The Feedback module allows you to create and conduct surveys to collect feedback from

Students. It is smaller in scope and therefore easier to use than the Questionnaire

C114

of 98

module, and unlike the Survey tool allows you to write your own questions, rather than

choose from a list of pre‐written survey instruments.

Prior to Moodle 2.0, the Feedback module was contributed code. It is included in Moodle

2.0, but disabled by default.

HTML Optional A HTML block is a standard block used to add text or images on a site or course page. The

title bar can be left blank.

The block is flexible and can incorporate a variety of functions and uses in the content

area. It has the standard Moodle HTML editor for formatting text, adding images or

creating links, switching to code view and allows any valid HTML markup to be used. This

enables embedding video, sounds, Flash, and other files which can add unique elements

to a course or site page.

Latest news

(Announcements; see

language preference)

Sticky Recent posts made in the News forum will display as a listed item in the Latest News

block, along with a link to older archived news.

By default, the Latest News block displays 3 news items. This may be changed in the

course administration block>Settings>News items to show.

People

* Students should not

have access to the class

list

Optional The People block contains a link to the list of the course participants. Generally speaking,

a teacher will see this block in their course.

The participants profiles are available by clicking on their name or picture. The list can be

sorted by first name, surname, city, country and last access. There is a pull down menu

which can filter the list for a specific role (tutors, students).

The “People” block can assign roles when the course’s edit mode is turned on. This is

done on the title bar and the “assign role” icon. This is a way to add students to a course.

Users without the correct permissions will not see this block.

C115

of 98

Quiz results Optional The quiz results block displays the highest and/or lowest grades achieved on a quiz within

a course. There must be a quiz in the course to correctly configure this block.

Random glossary

entry

Optional The random glossary block can be used to display random entries from a glossary, which

usually take the form of dictionary style definitions. However the flexibility of Moodle’s

HTML editor allow users to adapt this block for other purposes such as ‘Quote of the Day’

or a random picture gallery that changes each time the page is refreshed.

Recent activity

Only staff should be able

to track such activity

In Test environment but not listed in documentation

The Recent Activity block lists course activity, such as updated resources and activities,

forum posts and assignment submissions, since the user last accessed the course.

The activity report filter and generator may be accessed via the Full report of recent

activity link.

Remote RSS Feeds Optional The RSS feeds block enables RSS feeds from external websites to be displayed within

Moodle. As the information on the other site (for example, news headlines or recently

added documents) is changed the block will update to show the latest information. One

or more RSS feeds can be added to a course by selecting them from an existing list. Site

and course home pages are common places to place an RSS feed block(s).

Search forums Optional The Search Forum block allows you to search the course forums for a word or phrase.

Type the word or phrase you want to find in the text field space.

Disabled blocks

Block Description

Admin bookmarks In Test environment but not listed in documentation

Blog The blog menu block provides links to

* Add a new entry

* View my entries

* Blog preferences

C116

of 98

* View site entries

* Add/delete tags

The block menu block appears in the Blog tab of your profile page. The block may also be added to a course

homepage.

Community The community block, in Moodle 2.0 onwards, enables users to search for courses to download or enrol in

on a community hub and lists courses which the user is enrolled in.

Community finder In Test environment but not listed in documentation

Courses Navigation block A block which lists a students courses in a drop down list. This is useful for saving space when students are

members of a lot of courses. The courses are sorted alphabetically and hidden courses are not shown.

The block also contains a drop down of the top level categories along with a courses search box and a list all

courses button.

Course/Site description The Course/Site Description block provides a summary and/or description for your course as contained in

the summary text of the course settings.

Unit description In Test environment but not listed in documentation

Global search The Global Search Block is the user‐side visible part of the internal Global Search Engine of Moodle, which is

located in the “search” directory of the Moodle distribution.

The Global Search Block provides user with a search form interface, that will query all searchable entries in

Moodle.

Logged in user

Mentees A Mentees block is a front page block that provides mentors with quick access to their mentee(s) profile

page(s). The mentees block may be added to the site front page or to My Moodle.

Messages The message block displays a list of new messages you have received, with a link to your Messages window.

Online users The Online Users block shows a list of users who have been logged into the current course. This block can be

added or deleted by a teacher. The list is updated on a regular basis (the default is every 5 minutes). The

time frame can be modified for the entire Moodle site in Administration >> Configuration >> Blocks >>

Online Users by the site administrator.

Online Users Mentor In Test environment but not listed in documentation

C117

of 98

My private files (until we decide how we

provide students with a storage area) ?

The My private files block, in Moodle 2.0 onwards, enables access to a user's private files area.

Personal Profile ?

Section links The Section Links block helps the student or teacher to quickly navigate to a particular topic/week section of

the course (depending on whether the course uses either the “Topics” or “Weekly” format. The numbered

links displayed within the block are the numbers assigned to the course topic/week sections.

Self Completion The self completion block in Moodle 2.0 onwards provides a link for students to indicate when they have

completed the course.

It requires manual self completion to be enabled in the course completion settings. When a student

believes they have completed the course, they click on the link "Complete course" in this block.

Subjects ?

Tags A very effective way of viewing all tags is in a tags block, or "tag cloud". A unique feature of tag clouds are

that the size of each tag is related to the amount of items associated with it. The larger the tag, the more

items associated with it.

Units (i.e. courses) This page refers to the block "blocks/course_list". There are other, similar, blocks in existence, such as

"blocks/myCourses"

The Courses block lists and allows navigation between all of the courses in which the logged in user is a

participant (as tutor and/or student). The block title shows as "My courses" and allows one‐click access to a

course's home page.

C118

of 98


Unit list

block_course_list_adminview What should the admin see in the course list block?

Admin user sees all courses Admin user sees only their courses

Default not appropriate for large Moodle sites.

block_course_list_hideallcourseslink Hide "All courses" link at the bottom of the block. Link hiding does not affects Admin's view

No No

Online users

block_online_users_timetosee Number of minutes determining the period of inactivity after which a user is no longer considered to be online.

5 5

Online Users Monitor

block_online_users_monitor_limit Number of online users that will trigger notification to be sent.

50 50

block_online_users_monitor_email Email addresses to send notifications and reports to. Multiple addresses can added seperated by a comma (,).

moodle‐[email protected]

moodle‐[email protected]

block_online_users_monitor_alert Minimum time in minutes before subsequent notifications will be sent.

240 240

block_online_users_monitor_last_alert Empty Empty

block_online_users_monitor_last_weekly Empty 1310312370

block_online_users_monitor_last_monthly Empty 1309707476

RSS client

C119

of 98

block_rss_client_num_entries The default number of entries to show per feed.

5 5

block_rss_client_timeout Time in minutes before an RSS feed expires in cache. Note that this time defines the minimum time before expiry; the feed will be refreshed in cache on the next cron execution after expiry.

30 30

block_tags_showcoursetags Display the course tagging features in the tags block, allowing students to tag courses.

No No

Section links

blocks/section_links | numsections1 Once the number of sections in the course reaches this number then the increment by value is used.

22 22

blocks/section_links | incby1 This is the value the section is incremented each time a section link is displayed starting at 1.

2 2

blocks/section_links | numsections2 Once the number of sections in the course reaches this number then the Alternative increment by value is used.

40 40

blocks/section_links | incby2 This is the value the section is incremented each time a section link is displayed starting at 1.

5 5

Tags

block_tags_showcoursetags Display the course tagging features in the tags block,

No No

C120

of 98

allowing students to tag courses.

Enrolments Define enrolment methods, including references to Integration Document for enrolments driven from external sources.

Enabled:

‐ Manual Enrolments

‐ Guest Access

‐ Self Enrolment

‐ Cohort Sync


Cohort Sync

enrol_cohort | roleid Cohort enrolment plugin synchronises cohort members with course participants.

Student Student

Guest Access

enrol_guest | requirepassword Require access password in new courses and prevent removing of access password from existing courses.

No No

enrol_guest | usepasswordpolicy Use standard password policy for guest access passwords. No No

enrol_guest | showhint Show first letter of the guest access password. No No

Guest Access Enrolment instance defaults

enrol_guest | defaultenrol It is possible to add this plugin to all new courses by default. Yes Yes

enrol_guest | status Allow temporary guest access by default. No No

C121

of 98

Manual enrolments Enrolment instance defaults

enrol_manual | defaultenrol It is possible to add this plugin to all new courses by default. Yes Yes

enrol_manual | status Enable manual enrolments. Allow course access of internally enrolled users. This should be kept enabled in most cases.

Yes Yes

enrol_manual | enrolperiod Default length of the default enrolment period setting (in seconds). 0 0

enrol_manual | roleid Default role Student Student

Self Enrolment

enrol_self | requirepassword Require enrolment key in new courses and prevent removing of enrolment key from existing courses.

No No

enrol_self | usepasswordpolicy Use standard password policy for enrolment keys. No No

enrol_self | showhint Show first letter of the guest access key. No No

Self Enrolment Enrolment instance defaults

enrol_self | defaultenrol It is possible to add this plugin to all new courses by default. Yes Yes

enrol_self | status Allow users to self enrol into course by default. No No

enrol_self | groupkey Use group enrolment keys by default. No No

enrol_self | roleid Select role which should be assigned to users during self enrolment Student Student

enrol_self | enrolperiod Default length of the enrolment period (in seconds). 0 0

enrol_self | longtimenosee If users haven't accessed a course for a long time, then they are automatically unenrolled. This parameter specifies that time limit.

120 120

enrol_self | maxenrolled Specifies the maximum number of users that can self enrol. 0 means no limit.

0 0

enrol_self | sendcoursewelcomemessage

If enabled, users receive a welcome message via email when they self‐enrol in a course.

Yes Yes

Filters Filter Description Active Apply To

Glossary auto‐linking As the name suggests, this filter enables automatic linking of Glossary module entries. In addition to this filter, individual glossary entries should have the "This entry should be automatically linked" box checked.

Off Content

Multimedia Plugins The Multimedia plugins filter finds URLs that point to multimedia resources in text and On Content

C122

of 98

replaces them with an appropriate multimedia player.

TeX Notation The TeX Filter is a core Moodle filter intended to allow one to convert tex expressions into GIF images.

On Content

Algebra Notation This filter will convert algebra code into GIF images. On Content

Database auto‐linking This filter enables automatic linking of Database module entries. Off Content

Activity names auto‐linking This scans text for activity titles that exist in the same course and creates a link. Disabled Content

Email Protection This filter scans the text for any email addresses. Where found they are changed (obfuscated) to reduce the chance of being added to a spammers list.

Disabled Content

HTML Tidy This filter checks whether HTML code is XHTML compliant, tidying where necessary. Disabled Content

Multi‐language Content This filter enables resources to be created in multiple languages. It looks for <span lang="xx" class="multilang">...</span> tags which indicate that a text contains multiple languages. Then it selects and outputs the best language for the current user. The language of the resource will change when the user changes their selected Moodle language.

Disabled Content

Word Censorship This filter "blacks out" words found on a list. Disabled Content

Convert URLs into links and images On Content

Display emoticons as images On Content

CI Description Default Actual

Common Filter Settings

cachetext Text cache lifetime. For larger sites or sites that use text filters, this setting can really speed things up. Copies of texts will be retained in their processed form for the time specified here. Setting this too small may actually slow things down slightly, but setting it too large may mean texts take too long to refresh (with new links, for example).

1 minute 1 minute

filteruploadedfiles Process all uploaded HTML and text files with the filters before displaying them, only uploaded HTML files or none at all.

None None

filtermatchoneperpage Automatic linking filters will only generate a single link for the first matching text instance found on the complete page. All others are ignored.

No Yes

filtermatchonepertext Automatic linking filters will only generate a single link for the first matching text instance found in each item of text (e.g., resource, block) on the page. All others are ignored. This setting is ignored if the one per page setting is yes.

No Yes

C123

of 98

Multimedia Plugins

filter_mediaplugin_enable_youtube YouTube video sharing site, video and playlist links supported. Yes Yes

filter_mediaplugin_enable_vimeo Vimeo video sharing site. No Yes

filter_mediaplugin_enable_mp3 Files with extension *.mp3. Plays audio using Flowplayer, requires Flash plugin. Yes Yes

filter_mediaplugin_enable_flv Files with extension *.flv and *.f4v. Plays video clips using Flowplayer, requires Flash plugin and javascript. Uses HTML 5 video fallback if multiple sources psecified.

Yes Yes

filter_mediaplugin_enable_swf Files with extension *.swf. For security reasons this filter is used only in trusted texts. Yes No

filter_mediaplugin_enable_html5audio Audio files with extension *.ogg, *.acc and others. It is compatible with latest web browsers only, unfortunately there is no format that is supported by all browsers. Workaround is to specify fallbacks separated with # (ex: http://example.org/audio.acc#http://example.org/audio.acc#http://example.org/audio.mp3#), QuickTime player is used as a fallback for old browsers, fallback can be any audio type.

No No

filter_mediaplugin_enable_html5video Video files with extension *.webm, *.m4v, *.ogv, *.mp4 and others. It is compatible with latest web browsers only, unfortunately there is no format that is supported by all browsers. Workaround is to specify fallbacks sources separated with # (ex: http://example.org/video.m4v#http://example.org/video.acc#http://example.org/video.ogv#d=640x480), QuickTime player is used as a fallback for old browsers.

No No

Legacy Media Players Following formats are not recommended for general usage, they are usually used in intranet installation with centrally managed clients.

filter_mediaplugin_enable_qt Files with extension *.mov, *.mp4, *.m4a, *.mp4 and *.mpg. Requires QuickTime player or codecs.

Yes No

filter_mediaplugin_enable_wmp Files with extension *.avi and *.wmv. Fully compatible with Internet Explorer in Windows, may be problematic in other browsers or operating systems.

Yes No

filter_mediaplugin_enable_rm Files with extension *.rm, *.ra, *.ram, *.rp, *.rv. Requires RealPlayer. Yes No

LaTeX renderer Settings

filter_tex_latexpreamble Enables the LaTeX preamble to be specified. The default should work for most users, but you may need to change it to support non‐latin character sets etc. Please see the LaTeX documentation for further details.

Too large to include here

Too large to include here

filter_tex_latexbackground This should be set to your normal text background colour. The default setting is #FFFFFF (i.e., white).

#FFFFFF #FFFFFF

filter_tex_density This setting effects the size of the resulting image. The default setting is 120 pixels, 120 120

C124

of 98

and it produces an image of reasonable quality, but for some complicated equations, this still may not be enough. It may be that anything less is not going to produce an image of sufficient quality but the image size can be controlled by the TeX encoding when the page is rendered.

filter_tex_pathlatex Path to standard latex binary. /usr/bin/latex

/usr/bin/latex

filter_tex_pathdvips Path to standard dvips binary ‐ generally distributed as part of a LaTeX system. /usr/bin/dvips

/usr/bin/dvips

filter_tex_pathconvert Path to standard convert binary. /usr/bin/convert

/usr/bin/convert

filter_tex_convertformat If latex, dvips and convert are available, the images are created using the specified format. If it is not, mimeTeX will be used and it will create GIF images.

GIF GIF

Portfolios Define integration with Portfolios, potentially with a link to the Integration Document.

Repositories Define active repositories, potentially with a link to the Integration Document.

Name Active?

Server files Enabled and Visible

Recent files Enabled and Visible

Upload a file Enabled and Visible

Private files Disabled and Invisible

Flickr public Enabled and Visible

Google Docs Enabled and Visible

Youtube videos Enabled and Visible

Alfresco repository Disabled

C125

of 98

Box.net Disabled

Legacy course files Disabled

Dropbox Disabled

File system Disabled

Flickr Disabled

Merlot.org Disabled

Picasa web album Disabled

Amazon S3 Disabled

URL downloader Disabled

WebDAV repository Disabled

Wikimedia Disabled


Common repository settings

repositorycacheexpire The amount of time that file listings are cached locally (in seconds) when browsing external repositories.

120 120

Repositoryallowexternallinks This option enables all users to choose whether or not external media is copied into Moodle or not. If this is off then media is always copied into Moodle (this is usually best for overall data integrity and security). If this is on then users can choose each time they add media to a text.

Yes Yes

legacyfilesinnewcourses By default legacy course files areas are available only in upgraded courses. Please note some features like single activity backup/restore are not compatible with this setting.

No No

Configuration for server file repository

Repository plugin name If you leave this empty the default name will be used. Empty Empty

Configuration for recent files repository


Number of recent files Empty Empty

Configuration for upload plugin


Configuration for user private files

C126

of 98

repository Repository plugin name If you leave this empty the default name will be used. Empty Empty

Flickr public configuration

API key Get a Flickr API Key for your Moodle site. Key Key

Allow users to add a repository instance into the course

Yes Yes

Allow users to add a repository instance into the user context

No No

Flickr public configuration Repositories instances of the site

Name

Email address

Add watermark to photos

Configurate Google Docs plugin

Repository plugin name If you leave this empty the default name will be used. Google Docs

Google Docs

YouTube repository type configuration

Repository plugin name If you leave this empty the default name will be used. YouTube YouTube

Backups <How should backups be managed>


General backup defaults

backup | backup_general_users Sets the default for whether to include users in backups.

Yes Yes

backup | backup_general_anonymize

If enabled all information pertaining to users will be anonymised by default

No No

backup | backup_general_role_assignments

If enabled by default roles assignments will also be backed up

Yes Yes

C127

of 98

backup | backup_general_user_files

Sets the default for whether user files will be included in backups.

Yes Yes

backup | backup_general_activities Sets the default for including activities in a backup.

Yes Yes

backup | backup_general_blocks Sets the default for including blocks in a backup.

Yes Yes

backup | backup_general_filters Sets the default for including filters in a backup. Yes Yes

backup | backup_general_comments

Sets the default for including comments in a backup.

Yes Yes

backup | backup_general_userscompletion

If enabled user completion information will be included in backups by default.

Yes Yes

backup | backup_general_logs If enabled logs will be included in backups by default.

No Yes

backup | backup_general_histories Sets the default for including user history within a backup.

No Yes Can a staff member export student tracking information before a unit is backed‐up?

Automated backup setup

backup | backup_auto_active Choose whether or not to do automated backups. If manual is selected automated backups will be possible only through the automated backups CLI script. This can be done either manually on the command line or through cron.

Disabled Enabled

backup | backup_auto_weekdays Choose which days of the week to perform automated backups.

None Sun, Mon, Tues, Wed, Thurs, Fri, Sat

backup | backup_auto_hour Choose what time automated backups should run at.

0:0 15:15 Does this means 3.15pm in the afternoon? If so, will this have implications for server performance?

backup | backup_auto_storage Choose the location where you want backups to be stored when they are automatically created.

Course backup file area

Course backup file area

C128

of 98

backup | backup_auto_destination Full path to the directory where you want to save the backup files (leave blank to save in its course default dir)

Empty /app/uwa‐mdl2‐prod/htdocs/backups

backup_sche_expire_days Choose how long to keep backups for. They will be deleted when they reach this age.

None None

backup | backup_auto_keep How many recent backups for each course do you want to keep? (older ones will be deleted automatically)

1 1

Automated backup settings

backup | backup_auto_users Select whether you want to include all the users in the server or only the needed users for each course

Yes Yes

backup | backup_auto_role_assignments

If enabled by default role assignments will also be backed up.

Yes Yes

backup | backup_auto_user_files Sets the default for whether user files will be included in backups.

Yes Yes

backup | backup_auto_activities Sets the default for including activities in a backup.

Yes Yes

backup | backup_auto_blocks Sets the default for including blocks in a backup.

Yes Yes

backup | backup_auto_filters Sets the default for including filters in a backup. Yes Yes

backup | backup_auto_comments Sets the default for including comments in a backup.

Yes Yes

backup | backup_auto_userscompletion

If enabled user completion information will be included in backups by default.

Yes Yes

backup | backup_auto_logs If enabled, then course logs will be included in automated backups

No Yes

backup | backup_auto_histories Sets the default for including user history within a backup.

No Yes

C129

of 98

Grades

General settings


gradebookroles Roles which will be graded and appear in the gradebook.

Student Student

grade_profilereport Grade report used on user profile page.

User report

User report

grade_aggregationposition This setting determines whether the category and course total columns are displayed first or last in the gradebook reports.

Last Last After std ID/number/on after all assignment columns.

grade_includescalesinaggregation You can change whether scales are to be included as numbers in all aggregated grades across all gradebooks in all courses.

Yes No, Advanced

Generally go with ‘no’. Difficulties in having ‘total’. If you set scales as ‘good’ ‘bad’ ‘average’.

grade_hiddenasdate If user cannot see hidden grades show date of submission instead of '‐'.

No Yes More useful view for students. Not showing stds particular column will not blank but will be populated w/date

gradepublishing Enable publishing in exports and imports: Exported grades can be accessed by accessing a URL, without having to log on to a Moodle site.

No No

grade_export_displaytype Grades can be shown as real grades, as percentages (in reference to the minimum and maximum grades) or as letters (A, B, C etc..) during export. This can be overridden

Real Real We need to decide the default display type – real percentage or letter grades?

C130

of 98

during export.

grade_export_decimalpoints The number of decimal points to display for export.

2 2

grade_navmethod Default navigation method for the gradebook.

Dropdown menu

Tabs Easier to navigate.

gradeexport Choose which gradebook export formats are your primary methods for exporting grades.

None None Choose an export format – plain text or excel?

unlimitedgrades By default grades are limited by the maximum and minimum values of the grade item. Enabling this setting removes this limit, and allows grades of over 100% to be entered directly in the gradebook.

No No

Grade categories


grade_hideforcedsettings Do not show forced settings in grading UI.

Yes Yes

grade_aggregation The aggregation determines how grades in a category are combined

Simple weighted mean of grades Sum of grades More common scenario.

grade_aggregations_visible Aggregation types that should be available.

Mean of grades, Weighted mean of grades, Simple weighted mean of grades, Mean of grades (with extra credits), Median of grades, Lowest grade, Highest grade, Mode of grades, Sum of grades.

Mean of grades, Median of grades, Lowest grade, Highest grade, Sum of grades.

Suggest restricted set to reduce complexity.

grade_aggregateonlygraded An empty grade is a grade which is missing from the gradebook. It may be from an assignment submission which

Default: Yes, Not forced, Advanced Default: Yes, Not forced, Advanced

C131

of 98

has not yet been graded or from a quiz which has not yet been attempted etc.

grade_aggregateoutcomes If enabled, outcomes are included in the aggregation.

Default: No, Not forced, Advanced Default: No, Not forced, Advanced

grade_aggregatesubcats This setting determines whether grades in subcategories are included in the aggregation.


grade_keephigh If set, this option will only keep the X highest grades, X being the selected value for this option.

Default: No, Forced, Advanced Default: No, Forced, Advanced

grade_droplow This setting enables a specified number of the lowest grades to be excluded from the aggregation.


Grade items

(when things are graded, what is displayed?)


grade_displaytype This setting determines how grades are displayed in the grader and user reports.

Real Real

grade_decimalpoints This setting determines the number of decimal points to display for each grade.

2 2

grade_item_advanced Select all elements that should be displayed as advanced when editing grade items.

Default: Item info, ID number, Grade to pass, Offset, Multiplicator, Grade display type, Overall decimal points, Hidden until, Lock after

Default: Item info, ID number, Grade to pass, Offset, Multiplicator, Grade display type, Overall decimal points, Hidden until, Lock after

‐ x by default student ID is not displayed. Double check 1st name last name

C132

of 98

Scales

Enables you to create your own scales. Eg: prac demo – pass / fail – use scale rather than real, percentage, letter

Scale List Used

Likert Very good, Good, Average, Poor, Very poor Yes

Likert 2 Strongly Agree, Agree, Not Applicable, Disagree, Strongly Disagree Yes

Separate and Connected ways of knowing

Mostly Separate Knowing, Separate and Connected, Mostly Connected Knowing No

Outcomes

Learning outcomes can be added – site wide and create unit specific – link to activities.

Field name Description Required Format

outcome_name The full name of the outcome Yes String

outcome_shortname The short name of the outcome Yes String

outcome_description The description of the outcome Yes String

scale_name The name of the scale used Yes String

scale_items A comma‐separated list of scale items Yes String

scale_description The description of the scale Yes String

C133

of 98

Letters

Highest Lowest Letter

100.00% 80.00% HD

79.99% 70.00% D

69.99% 60.00% CR

59.99% 50.00% P

49.99% 45.00% N+

44.99% 0.00% N

Grader report


grade_report_studentsperpage This setting determines the number of students displayed per page in the grader report.

100 100 Option to increase length of loading?

grade_report_quickgrading If enabled, when editing is turned on, a text input box appears for each grade, allowing many grades to be edited at the same time.

Yes Yes

grade_report_showquickfeedback If enabled, when editing is turned on, a feedback text input box with a dotted border appears for each grade, allowing the feedback for many grades to be edited at the same time.

No No

grade_report_fixedstudents Allows grades to scroll horizontally without losing sight of the students column, by making it static.

No Yes Improves usability of gradebook in most cases.

grade_report_meanselection This setting determines whether cells with no grade should be included when calculating the average (mean) for each category or grade item.

Non‐empty grades

Non‐empty grades

grade_report_enableajax Adds a layer of AJAX functionality to the grader report, simplifying and speeding up common operations.

No Yes Improves usability of gradebook.

grade_report_showcalculations If enabled, when editing is turned on, a calculator icon is No Yes Useful for calculated fields.

C134

of 98

shown for each grade item and category, with tool tips over calculated items and a visual indicator that a column is calculated.

grade_report_showeyecons If enabled, when editing is turned on, a show/hide icon is shown for each grade for controlling its visibility to the student.

No Yes Improves usability.

grade_report_showaverages If enabled, the grader report will contain an additional row displaying the average (mean) for each category and grade item.

No No

grade_report_showlocks If enabled, when editing is turned on, a lock/unlock icon is shown for each grade for controlling whether the grade can be automatically updated by the related activity.


grade_report_showranges If enabled, the grader report will contain an additional row displaying the range for each category and grade item.


grade_report_showuserimage Whether to show the user's profile image next to the name in the grader report.

Yes No ? Will we use photo ID in callista?

grade_report_showuseridnumber If enabled, user ID numbers are shown in an additional column.

No Yes Improves usability. By default, student ID NOT displayed in graded. We need to make sure it is.

grade_report_showactivityicons If enabled, activity icons are shown next to activity names.

Yes Yes

grade_report_shownumberofgrades If enabled, the number of grades used when calculating the average (mean) is displayed in brackets after each average.


grade_report_averagesdisplaytype This setting determines whether the average (mean) is displayed as real grades, percentages or letters, or whether the display type for the category or grade item is used (inherit)

Inherit Inherit

grade_report_rangesdisplaytype This setting determines whether the range is displayed as real grades, percentages or letters, or whether the

Inherit Inherit

C135

of 98

display type for the category or grade item is used (inherit).

grade_report_averagedecimalpoints This setting determines the number of decimal points to display for each average or whether the overall decimal points setting for the category or grade item is used (inherit).

Inherit Inherit

grade_report_rangesdecimalpoints This setting determines the number of decimal points to display for each range or whether the overall decimal points setting for the category or grade item is used (inherit).

Inherit Inherit

Overview report


grade_report_overview_showrank This setting determines whether the position of the student in relation to the rest of the class is shown for each grade item.

No No

grade_report_overview_showtotalsifcontainhidden This setting specifies whether totals which contain hidden grade items are shown to students or replaced with a hyphen (‐). If shown, the total may be calculated either excluding or including hidden items.

Hide Hide

User report


grade_report_user_showrank This setting determines whether the position of the student in relation to the rest of the class is shown for each grade item.

No No

grade_report_user_showpercentage This setting determines whether the percentage value of each grade item is shown.

No No

grade_report_user_showgrade Show the grade column? Yes Yes

grade_report_user_showfeedback Show the feedback column? Yes Yes

C136

of 98

grade_report_user_showrange Show the range column? Yes Yes

grade_report_user_showweight Show the grade weight column? No No

grade_report_user_showaverage Show the average column? Students may be able to estimate other student's grades if the average is calculated from a small number of grades. For performance reasons the average is approximate if it is dependent on any hidden items.

No No

grade_report_user_showlettergrade Show the letter grade column? No No

grade_report_user_rangedecimals The number of decimal points to display for range. 0 0

grade_report_user_showhiddenitems Whether hidden grade items are hidden entirely or if the names of hidden grade items are visible to students.

Only hidden until

Only hidden until

grade_report_user_showtotalsifcontainhidden This setting specifies whether totals which contain hidden grade items are shown to students or replaced with a hyphen (‐). If shown, the total may be calculated either excluding or including hidden items.

Hide Hide

Location settings CI Description Default Actual Notes

timezone Set the default timezone here. This is the only the DEFAULT timezone for displaying dates ‐ each user can override this by setting their own in their profile. "Server time" here will make Moodle default to the server's operating system setting, but "Server time" in the user profile will make the user default to this timezone setting. Cronjobs that depend on a time of day to run will use this timezone.

Server’s local time

Server’s local time

forcetimezone Users can either individually select their timezone, or be forced to use a common timezone. Users can choose their own timezone

Users can choose their own timezone

country If you set a country here, then this country will be selected by default on new user accounts. To force users to choose a country, just leave this unset.

Choose… Australia

defaultcity A city entered here will be the default city when creating new user accounts.

geoipfile Location of GeoIP City binary data file. N/A N/A

C137

of 98

googlemapkey For use with Google Maps for IP address lookup visualization N/A N/A

allcountrycodes This is the list of countries that may be selected in various places, for example in a user's profile.

Empty Empty

Language settings

General language settings


autolang Detect default language from browser setting, if disabled site default is used. Yes Yes

lang Default language for the whole site. EN EN

langmenu Choose whether or not you want to display the general‐purpose language menu on the home page, login page etc. This does not affect the user's ability to set the preferred language in their own profile.

Yes Yes

langlist Languages to appear on the language drop‐down menu. Empty Empty

langcache Cache the language menu. Saves a lot of memory and processing power. If you enable this, the menu takes a few minutes to update after you have added or removed languages.

Yes Yes

langstringcache Caches all the language strings into compiled files in the data directory. If you are translating Moodle or changing strings in the Moodle source code then you may want to switch this off. Otherwise leave it on to see performance benefits.

Yes Yes

locale Choose a sitewide locale ‐ this will override the format and language of dates for all language packs (though names of days in calendar are not affected). You need to have this locale data installed on your operating system (eg for linux en_US.UTF‐8 or es_ES.UTF‐8). In most cases this field should be left blank.

Blank Blank

latinexcelexport Choose the encoding for Excel exports. Unicode Unicode

Language packs

Installed language packs: English(en)

C138

of 98

Warning on page: Because Moodle can not connect to download.moodle.org, we are unable to do language pack installation automatically. Please download the appropriate zip file(s) from http://download.moodle.org, copy them to your /app/uwa‐mdl2‐prod/htdocs/moodledata/lang/ directory and unzip them manually.

Language customisation

Moodle Terminology UWA Terminology

Editing Teacher Lecturer

Course/s Unit/s

Latest News Announcements

Forums Discussions

News Forum Announcements

Themes CI Description Default Actual Notes

themelist Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you can specify a comma‐separated list of names here (Don't use spaces!). For example: standard,orangewhite.

Empty Empty YB: Don’t use more than

3 levels of themes.

‘magazine’

themedesignermode Normally all theme images and style sheets are cached in browsers and on the server for a very long time, for performance. If you are designing themes or developing code then you probably want to turn this mode on so that you are not served cached versions.

Off Off

C139

of 98

Warning: this will make your site slower for all users! Alternatively, you can also reset the theme caches manually from the Theme selection page.

allowuserthemes If you enable this, then users will be allowed to set their own themes. User themes override site themes (but not course themes)

No No

allowcoursethemes If you enable this, then courses will be allowed to set their own themes. Course themes override all other theme choices (site, user, or session themes)

No No Restriction on who can modify this setting.

allowcategorythemes If you enable this, then themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme.

No No Dependent on the structure of categories used.

allowthemechangeonurl If enabled, the theme can be changed by adding theme={themename} to any Moodle URL.

No No

allowuserblockhiding Do you want to allow users to hide/show side blocks throughout this site? This feature uses Javascript and cookies to remember the state of each collapsible block, and only affects the user's own view.

Yes Yes

allowblockstodock If enabled and supported by the selected theme users can choose to move blocks to the dock.

No No No

custommenuitems You can configure a custom menu here to be shown by themes. Each line consists of some menu text, a link URL (optional) and a tooltip title (optional), separated by pipe characters. You can specify a structure using hyphens.

Empty Empty YB: To be determined in discussion with UWA web office.

Appearance CI Description Default Actual Notes

Calendar

calendar_adminseesall Do admins see all calendar events or just those that apply to themselves?

No No

calendar_site_timeformat You can choose to see times in either 12 or 24 hour format for the whole site. If you choose "default", then the format will be automatically chosen according to the language you use in the site. This setting can be overridden by user preferences.

Default Default

calendar_startwday Which day starts the week in the calendar? Sunday Monday

C140

of 98

calendar_weekend Which days of the week are treated as "weekend" and shown with a different colour?

Sunday, Saturday Sunday, Saturday

calendar_lookahead How many days in the future does the calendar look for upcoming events by default?

21 21

calendar_maxevents How many (maximum) upcoming events are shown to users by default?

10 10

enablecalendarexport Enable exporting or subscribing to calendars. Yes Yes

calendar_exportsalt This random text is used for improving of security of authentication tokens used for exporting of calendars. Please note that all current tokens are invalidated if you change this hash salt.

Random string of text?

Blog

useblogassociations Enables the association of blog entries with courses and course modules.

Yes Yes

bloglevel This setting allows you to restrict the level to which user blogs can be viewed on this site. Note that they specify the maximum context of the VIEWER not the poster or the types of blog posts.

All site users can see all blog entries

Disable completely. YB: Not using blogs.

useexternalblogs Enables users to specify external blog feeds. Moodle regularly checks these blog feeds and copies new entries to the local blog of that user.

Yes Disable completely

externalblogcrontime How often Moodle checks the external blogs for new entries.

24h 24h

maxexternalblogsperuser The number of external blogs each user is allowed to link to their Moodle blog.

1 1

blogusecomments Enable comments Yes Yes

blogshowcommentscount Show comments count Yes Yes

Navigation

defaulthomepage This determines the home page for logged in users Site My Moodle

navshowcategories Show course categories in the navigation bar and navigation blocks. This does not occur with courses the user is currently enrolled in, they will still be listed

Yes No Reduce clutter in navigation.

C141

of 98

under mycourses without categories.

navshowallcourses Setting this ensures that all courses on the site are shown in the navigation at all times.

No No

navcourselimit Limits the number of courses shown to the user when they are either not logged in or are not enrolled in any courses.

20 20

HTML Settings

formatstringstriptags Uncheck this setting to allow HTML tags in activity and resource names.

Yes Yes

emoticons This form defines the emoticons (or smileys) used at your site.

Default Default

Moodle Docs

docroot Defines the path to the Moodle Docs. http://docs.moodle.org http://docs.moodle.org

doctonewwindow If you enable this, then links to Moodle Docs will be shown in a new window.

No No ?

Course contacts

coursecontact This setting allows you to control who appears on the course description. Users need to have at least one of these roles in a course to be shown on the course description for that course.

Unit Coordinator, Lecturer

Unit Coordinator, Lecturer

AJAX and Javascript

enableajax This setting allows you to control the use of AJAX (advanced client/server interfaces using Javascript) across the whole site. With this setting enabled users can still make a choice in their profile, otherwise AJAX is disabled for everybody.

Yes Yes

useexternalyui Instead of using local files, use online files available on Yahoo‘s servers.

No No

yuicomboloading This options enables combined file loading optimisation for YUI libraries. This setting should be enabled on production sites for performance reasons.

Yes Yes

cachejs Javascript caching and compression greatly improves Yes Yes

C142

of 98

page loading performance. it is strongly recommended for production sites.

Enablecourseajax Allow AJAX when editing main course pages. Note that the course format and the theme must support AJAX editing and the user has to enable AJAX in their profiles, too.

Yes Yes Improves ease of editing.

Additional HTML

additionalhtmlhead Content here will be added to the bottom of the HEAD tag for every page.

Empty Empty For discussion

additionalhtmltopofbody Content here will be added in to every page immediately after the opening body tag.


Additionalhtmlfooter Content here will be added in to every page right before the body tag is closed.


Advanced settings


enableoutcomes Support for Outcomes (also known as Competencies, Goals, Standards or Criteria) means that users can grade things using one or more scales that are tied to outcome statements. Enabling outcomes makes such special grading possible throughout the site.

No Yes Can be a powerful tool once understood.

usecomments Enable comments anywhere blocks are shown through using the ‘comments’ block.

Yes Yes

enablenotes Enable storing of notes about individual users, accessed through their personal profile.

Yes No For discussion.

usetags Should tags functionality across the site be enabled? Yes Yes

enablenotes Enable storing of notes about individual users. No No

enableportfolios This will allow administrators to configure remote systems for users to export content to.

No No

C143

of 98

enablewebservices Web services enable other systems to log in to this Moodle and perform operations.

No Yes Critical to integration.

messaging Should the messaging system between site users be enabled?

Yes No

messaginghidereadnotifications Hide read notifications of events like forum posts when viewing messaging history

No No

messagingdeletereadnotificationsdelay Read notifications can be deleted to save space. How long after a notification is read can it be deleted?

1 week 1 week

enablestats If you choose 'yes' here, Moodle's cronjob will process the logs and gather some statistics. Depending on the amount of traffic on your site, this can take awhile. If you enable this, you will be able to see some interesting graphs and statistics about each of your courses, or on a sitewide basis.

No No

enablerssfeeds This switch will enable RSS feeds from across the site. No Yes Enhanced feature.

bloglevel This setting allows you to restrict the level to which user blogs can be viewed on this site. Note that they specify the maximum context of the VIEWER not the poster or the types of blog posts.

All site users can see all blog entries

Disable completely.

X

mnet_dispatcher_mode MNet allows communication of this server with other servers or services.

No No X

enablecompletion When enabled, this lets users turn on completion tracking (progress) features at course level.

No Yes Useful feature.

enableavailability When enabled, this lets users set conditions (based on date, grade, or completion) that control whether an activity is available.

No Yes Critical feature for those used to WebCT.

enableplagiarism This will allow administrators to configure plagiarism plugins (if installed).

No Yes So that Moodle is set up when TurnItIn is installed integrated.

C144

of 98

Server CI Description Default Actual Notes

System paths

Gdversion Indicate the version of GD that is installed. The version shown by default is the one that has been auto‐detected. Don't change this unless you really know what you're doing.

GD 2.x is installed

GD 2.x is installed

Pathtodu Path to du. Probably something like /usr/bin/du. If you enter this, pages that display directory contents will run much faster for directories with a lot of files.

Empty Empty

Aspellpath To use spell‐checking within the editor, you MUST have aspell 0.50 or later installed on your server, and you must specify the correct path to access the aspell binary. On Unix/Linux systems, this path is usually /usr/bin/aspell, but it might be something else.

Empty Empty

Pathtodot Path to dot. Probably something like /usr/bin/dot. To be able to generate graphics from DOT files, you must have installed the dot executable and point to it here. Note that, for now, this only used by the profiling features (Development‐>Profiling) built into Moodle.

Empty Empty

Email Smtphosts Give the full name of one or more local SMTP servers that Moodle should

use to send mail (eg 'mail.a.com' or 'mail.a.com;mail.b.com'). To specify a non‐default port (i.e other than port 25), you can use the [server]:[port] syntax (eg 'mail.a.com:587'. If you leave it blank, Moodle will use the PHP default method of sending mail.

Empty cookie.netspot.com.au:2500

Smtpuser If you have specified an SMTP server above, and the server requires authentication, then enter the username and password here.

Empty Empty

Smtppass If you have specified an SMTP server above, and the server requires authentication, then enter the username and password here.

Empty Empty

Smtpmaxbulk Maximum number of messages sent per SMTP session. Grouping messages may speed up the sending of emails. Values lower than 2 force creation of new SMTP session for each email.

1 1

Noreplyaddress Emails are sometimes sent out on behalf of a user (eg forum posts). The noreply@uwa2. noreply@netsp

C145

of 98

email address you specify here will be used as the "From" address in those cases when the recipients should not be able to reply directly to the user (eg when a user chooses to keep their address private).

moodlesites.com

ot.com.au

Digestmailtime People who choose to have emails sent to them in digest form will be emailed the digest daily. This setting controls which time of day the daily mail will be sent (the next cron that runs after this hour will send it).

17 17

Sitemailcharset All the emails generated by your site will be sent in the charset specified here. Anyway, every individual user will be able to adjust it if the next setting is enabled.

UTF‐8 UTF‐8

Allowusermailcharset Enabling this, every user in the site will be able to specify his own charset for email.

No No

Mailnewline Newline characters used in mail messages. CRLF is required according to RFC 822bis, some mail servers do automatic conversion from LF to CRLF, other mail servers do incorrect conversion from CRLF to CRCRLF, yet others reject mails with bare LF (qmail for example). Try changing this setting if you are having problems with undelivered emails or double newlines.

LF LF

Supportname This is the name of a person or other entity offering general help via the support email or web address.

Yvonne Button Admin User

Supportemail This email address will be published to users of this site as the one to email when they need general help (for example, when new users create their own accounts). If this email is left blank then no such helpful email address is supplied.

[email protected]

[email protected]

Supportpage This web address will be published to users of this site as the one to go to when they need general help (for example, when new users create their own accounts). If this address is left blank then no link will be supplied.

Empty Empty

Jabber

Jabberhost The server to connect to to send jabber message notifications Empty Empty

Jabberserver XMPP host ID (can be left empty if the same as Jabber host) Empty Empty

Jabberusername The user name to use when connecting to the Jabber server Empty Empty

Jabberpassword The password to use when connecting to the Jabber server Empty Empty

Jabberport The port to use when connecting to the Jabber server 5222 5222

Session handling

C146

of 98

Dbsessions If enabled, this setting will use the database to store information about current sessions. This is especially useful for large/busy sites or sites built on cluster of servers. For most sites this should probably be left disabled so that the server disk is used instead. Note that changing this setting now will log out all current users (including you). If you are using MySQL please make sure that 'max_allowed_packet' in my.cnf (or my.ini) is at least 4M.

Yes No

Sessiontimeout If people logged in to this site are idle for a long time (without loading pages) then they are automatically logged out (their session is ended). This variable specifies how long this time should be.

2 hours 2 hours

Sessioncookie This setting customises the name of the cookie used for Moodle sessions. This is optional, and only useful to avoid cookies being confused when there is more than one copy of Moodle running within the same web site.

Empty Empty

Sessioncookiepath If you need to change where browsers send the Moodle cookies, you can change this setting to specify a subdirectory of your web site. Otherwise the default '/' should be fine.

/ /

Sessioncookiedomain This allows you to change the domain that the Moodle cookies are available from. This is useful for Moodle customisations (e.g. authentication or enrolment plugins) that need to share Moodle session information with a web application on another subdomain. WARNING: it is strongly recommended to leave this setting at the default (empty) ‐ an incorrect value will prevent all logins to the site.

Empty Empty

Statistics

Statsfirstrun This specifies how far back the logs should be processed the first time the cronjob wants to process statistics. If you have a lot of traffic and are on shared hosting, it's probably not a good idea to go too far back, as it could take a long time to run and be quite resource intensive. (Note that for this setting, 1 month = 28 days. In the graphs and reports generated, 1 month = 1 calendar month.)

None None

Statsmaxruntime Specify the maximum time allowed to calculate the statistics for one day, bearing in mind that stats processing can put a big load on the server. The maximum number of days processed in one cron can be specified below.

Until complete Until complete

Statsruntimedays Specify the maximum number of days processed in each stats execution. When stats are up‐to‐date, only one day will be processed, so adjust this

31 31

C147

of 98

value depending of your server load, reducing it if shorter cron executions are needed.

Statsruntimestarthour What time should the cronjob that does the stats processing start? Please specify different times if there are multiple Moodles on one physical server.

0:0 0:0

Statsuserthreshold This setting specifies the minimum number of enrolled users for a course to be included in statistics calculations.

0 0

HTTP

Framename If you are embedding Moodle within a web frame, then put the name of this frame here. Otherwise this value should remain as '_top'

_top _top

Slasharguments Files (images, uploads etc) are provided via a script using 'slash arguments'. This method allows files to be more easily cached in web browsers, proxy servers etc. Unfortunately, some PHP servers don't allow this method, so if you have trouble viewing uploaded files or images (eg user pictures), disable this setting.

Yes Yes

Reverse proxy

Getremoteaddrconf If your server is behind a reverse proxy, you can use this setting to specify which HTTP headers can be trusted to contain the remote IP address. The headers are read in order, using the first one that is available.

HTTP_CLIENT_IP, HTTP_X_FORWARDED_FOR, REMOTE_ADDR

HTTP_CLIENT_IP, HTTP_X_FORWARDED_FOR, REMOTE_ADDR

Web proxy Fill in following options if your Moodle server can not access internet directly. Internet access is required for download of environment data, language packs, RSS feeds, timezones, etc. PHP cURL extension is highly recommended.

Proxyhost If this server needs to use a proxy computer (eg a firewall) to access the Internet, then provide the proxy hostname here. Otherwise leave it blank.

Empty Empty

Proxyport If this server needs to use a proxy computer, then provide the proxy port here.

0 0

Proxytype Type of web proxy (PHP5 and cURL extension required for SOCKS5 support).

HTTP HTTP

Proxyuser Username needed to access internet through proxy if required, empty if none (PHP cURL extension required).

Empty Empty

Proxypassword Password needed to access internet through proxy if required, empty if Empty Empty

C148

of 98

none (PHP cURL extension required).

Proxybypass Comma separated list of (partial) hostnames or IPs that should bypass proxy (e.g., 192.168., .mydomain.com)

localhost, 127.0.0.1

localhost, 127.0.0.1

Maintenance mode

maintenance_enabled For upgrades and other work Disable Disable

maintenance_message Empty Empty

Cleanup

Deleteunconfirmed If you are using email authentication, this is the period within which a response will be accepted from users. After this period, old unconfirmed accounts are deleted.

7 days 7 days

Deleteincompleteusers After this period, old not fully setup accounts are deleted. Never Never

Logguests This setting enables logging of actions by guest account and not logged in users. High profile sites may want to disable this logging for performance reasons. It is recommended to keep this setting enabled on production sites.

Yes Yes

Loglifetime This specifies the length of time you want to keep logs about user activity. Logs that are older than this age are automatically deleted. It is best to keep logs as long as possible, in case you need them, but if you have a very busy server and are experiencing performance problems, then you may want to lower the log lifetime. Values lower than 30 are not recommended because statistics may not work properly.

Never delete logs

Never delete logs

Disablegradehistory Disable history tracking of changes in grades related tables. This may speed up the server a little and conserve space in database.

No No

Gradehistorylifetime This specifies the length of time you want to keep history of changes in grade related tables. It is recommended to keep it as long as possible. If you experience performance problems or have limited Database space, try to set lower value.

Never delete history

Never delete history

Performance

Numcoursesincombo The combo list doesn't work well with large numbers of courses. When the total number of courses in the site is higher than this setting then a link to the dedicated course listing will be shown instead of trying to display all the courses on the front page.

500 500

Extramemorylimit Some scripts like search, backup/restore or cron require more memory. Set 512M 128M

C149

of 98

higher values for large sites.

Curlcache Time‐to‐live for cURL cache, in seconds. 120 120

Curltimeoutkbitrate This setting is used to calculate an appropriate timeout during large cURL requests. As part of this calculation an HTTP HEAD request is made to determine the size of the content. Setting this to 0 disables this request from being made.

56 56

C150

6 LMSPrj_ProjMan_CommunicationPlan_V0 3_250711_SJ page 1 of 4 Created by Shannon Johnston on 11 July 2011

UWA MOODLE IMPLEMENTATION PROJECT 2011-2012

Project Communications Plan

Document created 11th July 2011 by Shannon Johnston (LMS Project Manager) Initial preparation May 2011 18th April 2011 Approved by D Chalmers

Version control

Version Date Name of editor Reason for edit 0.1 11/07/11 Shannon Johnston Initial project documentation 0.2 15/07/11 Jen Tomczak Minor edits / review

Document Contents

Overview of project and communications plan.............................................................................. 1 Purpose......................................................................................................................................... 1 Stakeholders ................................................................................................................................. 2 Strategy......................................................................................................................................... 3

344

Risks to communication plan ........................................................................................................ Process / Actions .......................................................................................................................... Records management...................................................................................................................

Overview of project and communications plan The aim of this project is to implement the Learning Management System (Moodle) for full implementation by Semester 1, 2012. Staff may elect to implement it from mid January 2012. This implementation requires a complex process of integrating Moodle with UWA systems, configuring it to work for the UWA users, and a change management process around migration and training of users. A part of a successful project and management of change is the way project processes, plans and progress, are communicated to stakeholders, as well as how risks are communicated and managed. This Communications plan outlines the LMS implementation stakeholders, and their importance to the project success, and the ways project processes, plans, progress, risks and so on are managed and when.

Purpose The communications plan forms a risk mitigation strategy in itself. The various stakeholders have varying degrees of communication needs, and the appropriateness and level of communication may have an impact on the project success.

Stakeholder Reason for inclusion Degree/depth of communication

Project and LMS Owner Business owner needs to be fully involved in decisions, progress and risk mitigation of the project

Regular updates, and more frequent if major decisions or issues arise

C151


Project teams Integral to the successful preparation and implementation of the LMS at UWA

Integral to design, development and implementation work. In-depth and constant communication.

NetSpot, LMS Partner Integral to preparation, implementation, and on-going hosting and support of Moodle.

LMS end users Core stakeholders – those involved in using the LMS for teaching and learning

Kept informed, with some opportunity to be involved in implementation processes.

Technical Systems

User support

Eventually to be providing T&L (CATL) or technical (IS) support to staff and students around the use of the LMS.

Kept aware, trained

University executive Approved the new LMS and budget.

Kept informed only

Stakeholders This table indicates the relative importance and impact of communication with particular stakeholders.

Stakeholder Role Communication level Importance and impact

LMS Owner (Director, CATL)

Owner Keep informed, major decision maker and approvals

Medium

Project team – CATL

Implementation and owners of LMS

Core to project implementation High

Project team – Systems integrations

Design and development of integrations

Core to LMS integrations implementation

High

Project team – NetSpot Pty Ltd

Hosting Partner Core to LMS implementation and on-going hosting

High

LMS support team – T&L

CATL EDS – train and help staff with using LMS

Integration to project and LMS implementation

High

LMS support team – technical help

Helping staff with technical issues post implementation

Ensure training Low

Academic staff Teacher users High

Administrative staff Admin support users High

Other staff Other users e.g. research

Keep aware, informed, and involved Low-Medium

Students Learner users Keep aware Low

University Executive Project sponsors Keep aware Low

University Committees

Approve LMS acquisition, policy and guidelines

Keep informed Low

Comment [j1]: Do you need to insert info for these fields?

C152


Strategy For the more detailed strategy, see Excel document Communications Plan Schedule LMSPrj_ProjMan_CommunicPlanSched_V0.2_110711_SJ.xls. Essentially, the strategy is as follows: LMS and LCS Business Owners and Sponsors, University executive and Committee

Inform of project process as required.

Status update, risks and issues mitigation, major decision-making – monthly status update meetings with brief report, and ad-hoc communication as necessary.

LMS implementation project team

Frequent, extensive planning and design meetings.

Regular weekly progress updates and request/issues meetings between UWA LMS Project Manager and CATL Project Coordinator / team, Systems Integrations Project Coordinator, Netspot project manager.

Email, telephone, or face-to-face discussions for design, planning, and implementation processes.

Milestone reports for sign-off by Project Coordinators, Project Manager and Project Owners.

Users: Teaching and admin staff, students, other staff

Various forms of information dissemination: website (monthly update), all-staff email (with key activities), eLearning mailinglist (new: quick, regular updates), faculty and school invited presentations (on request), all-staff information sessions (x 3, or in faculty/school if requested), student communication channels via Student Guild.

Risks to communication plan

Risk Likelihood Impact Mitigation

Missing deadlines, frequency of communications

Low Medium Admin Officer to develop and maintain a process of tracking what needs to happen when.

Others (project team members) needing to give Project Manager information not doing it and not on time.

Low-Medium

High Use the tracking process above, and communicate requirements in advance.

Develop samples or templates to aid

Various reporting and project team staff unable to attend meetings to report.

Medium High Use the above process.

Share documents via Sharepoint or email, depending task.

C153


Process / Actions 1. LMS Project Manager monitors communications, and conducts specific communication

tasks as allocated.

2. LMS Project Manager to create, discuss and share a Communications document for specific project teams, including a status report template for brief weekly reports.

3. LMS Project Admin Officer keeps a record of communications, ensuring that strategy is implemented and communications occur in the time mentioned.

4. Strategy implemented as listed in the document.

Records management A records management process is available in the Records Management document LMSPrj_Admin_DocStorage&RcordKpg_V2.0_2406/11_JT.doc. Essentially, the document comprises

File storage process: Staff not to use personal computers. In-progress documents used and stored on relevant local p: drive. Documents shared between CATL, IS, Netspot, etc via Sharepoint. Sharepoint is

managed by the LMS Project Admin Officer, but all members can post documents. Version #.0 documents or significant other version archived in TRIM. TRIM storage is

managed by LMS Project Administration Officer. File naming convention: To indicate the project, the project area, the file name, and the version. The CATL Naming includes the date and author initials.

C154