Developing the course manager module for the management of course requests

IRELAND & UK MOODLEMOOT 2012

IRELAND & UK

MOODLEMOOT

2012

Daniel McSweeney & Kyle Goslin

Institute of Technology Blanchardstown

Dublin



SOME BACKGROUND

• Commenced VLE usage with Web CT in 2003.

• That was a mistake.

• Began using Moodle 1.3 in 2004.

• Used on one distance education course.

• Small number of staff

• Began promoting for use on all courses


TYPICAL GROWTH AND CHANGE

• Initially all student accounts created via CSV.

• Staff accounts created on request.

• Courses created on request.

• This was fine while numbers using moodle were low.


THE CRUNCH

• By 2007 almost 55% of academic in the institution were using moodle.

• Managing over 1000 students.

• Hundreds of module requests at the start of each semester.

• Trying to convince IT services to integrate ‘novelty system’ with core IT functions.

• Managing my teaching load.


“THE POPULARITY OF THE VLE WENT FROM CULT TO MAINSTREAM OVERNIGHT AND WE WERE NOT READY”

“STAFF (INCLUDING MANAGEMENT) WERE UNAWARE OF THE PRESSURES OF KEEPING THE VLE RUNNING AND EVERYONE HAPPY”

“WE ARE TRAPPED IN A LOOP. WE KNOW WHAT WE NEED TO DO BUT DON’T HAVE THE TIME TO STOP AND DO IT!”


THINGS CAN ONLY GET BETTER?

• 2008 we integrated with LDAP for automatic student account creation.

• Made a significant difference.

• Examined integration with ‘Banner’ based on experiences of other colleges.

• We ran into a classic problem.


THE MISMATCH

• Mismatches between real world and IT representation

• Students enrolled in courses before IT system updated

• Students locked out of courses for admin reasons but attending class

• Staff assigned modules before IT system is updated

• Common modules a problem.


COURSE REQUESTS

• One of biggest issues is handling course requests.

• In absence of system requests were originally accepted via email.

• Typical semester – January 2006 (two week period) • 212 unique module requests via email in January

• Almost 30% required a clarification email response which in return would result in responses from staff.

• 280+ responses emails sent by admin • Module enrolment key

• Other module details


MANUAL WORKFLOW OPTIMUM EXPERIENCE

1. Read request email (30 seconds)

2. Log into moodle and go to create new course screen (30 seconds)

3. Enter new course details (30 seconds)

4. Assign lecturer to course (30 seconds)

5. Create email for user with course details and send (30 seconds)

3 minutes and 30 seconds for a manual request from start to finish Multiply this by 300 requests per semester!


MANUAL WORKFLOW NIGHTMARE EXPERIENCE

1. Read request email (30 seconds)

2. Respond to request asking for clarification (60 seconds)

3. Read clarification (30 seconds)

4. Log into moodle and go to create new course screen (30 seconds)

5. Enter new course details (30 seconds)

6. Realise that course already exists (10 seconds or grinding teeth)

7. Send email asking for next action (90 seconds)

8. Read clarification (30 seconds)

9. Send mail to module owner that another lecturer is now delivering module (30 seconds)

10. Read handover email (30 seconds)

11. Assign new lecturer to existing course (30 seconds)

12. Create email for user with course details and send (30 seconds)

• Almost 7 minutes (on a very good day) for one request


HOW DID I GET HERE?


COURSE REQUESTS – NEXT STEP – FORM BASED REQUESTS

• Used google form to gather data

• Structured requests

• Separate from email account

• Easier to manage and share

• Did not eliminate the process of manually creating courses for staff or sending response mails.

• Helped reduce ‘fuzzy’ requests!


THE MOODLE COURSE REQUEST FEATURE - CORE

• We examined the internal moodle request form

• Shortname

• Fullname

• Other details

• Several problems

• ‘Fuzzy’. It allows users too much freedom in the structuring of their request data

• Does not allow for confirmation mail customization etc.

• Lacks communication and management facilities for request management.


OUR REQUIREMENTS FOR A SOLUTION

• Part of moodle – we wanted to avoid ‘another IT system’ for academics. Had to be a block or module.

• Structured data for requests

• Automated course creation on course approval – “click a button”

• Automated communication emails sent to requestor and admin

• Highly customisable – request process and communications

• Easy to use

• Sharable with community – not just for our needs


OUR IMPLEMENTATION

• Created Course Manager block

• Can be added anywhere on site.

• Available on github now for download and testing.

• Recommend for production sites!

DEMO


THE ADVANTAGES

• Request form easy to find for academics

• Requests can be structured to suit needs

• All information gathered in one place

• Can approve courses in seconds

• Course automatically created on approval

• Emails automatically sent when courses created

• History of requests

• Easy to use

• Easy to configure

• Massive time saver. A process that took almost 4 minutes per request has been replaced by one that takes under 30 seconds per request.


NEXT STEPS

• Moodle 2 release

• Reporting

• Allow user to choose catalog location at request time

• Invoke backup and resets for existing courses during handoff

• Allow users to be assigned to a course approved (divide up workload among multiple admins)


http://www.moodleprojects.com/ https://github.com/Kylegoslin/Course-Manager-Block-for-Moodle

https://github.com/Kylegoslin/Course-Manager-Block-for-Moodle














QUESTIONS?

Education

Developing the course manager module for the management of course requests