2. The City of Glasgow College
• Colleges in Scotland merging into
regional super-colleges.
• City of Glasgow College formed in
2011, when three Glasgow city
centre colleges merged.
3. The City of Glasgow College
Bb
8.0
m
1.9.8
m
1.9.8
469 Courses 672 Courses 609 Courses
628 Sta! Accounts 363 Sta! Accounts 157 Sta! Accounts
4. The City of Glasgow College
m
2.4.0
3,932 Courses
16,102 Active Users
5. The Merger
• Colleges merged in Summer 2011.
• We had to launch a new Moodle
while every other IT system in the
college was changing.
• New Novell login system, new
student record system.
7. Plan B
• Lots of IT systems changing at the
same time made it hard to get time
to discuss Plan A with the IT team.
• Too many ‘fringe use cases’ (e.g.
students with multiple part-time
courses).
8. Plan B
• Pull data from student record
system into ‘middle man’ database.
• Use the database structure to
manage enrolments.
• Gave our team much more control
over enrolments.
10. Plan B
• Moodle comes with several
enrolment plugins.
• One lets you take enrolments from
an external database.
11. Plan B
Data gets Exported in
exported a format
from MIS. Moodle understands
Student
SQL
Record Moodle
DB
System
12. Database Structure
• Required data exported from UNITe
student record system.
• Relational database structure used
to manage enrolments
13. Database Structure
• Students belong to the class group.
• Class groups get assigned to a
course.
• Courses may be associated with one
or more units.
14. Meta Link Mayhem
• Our database structure has its own
meta-link system.
• Don’t do this! Use Moodle’s built-in
meta-link facility.
• There were reasons we had to do
this.
15. Meta Link Mayhem
• In Moodle 2, you can add users
directly to metalinked courses. You
couldn’t in Moodle 1.9.
• We were merging three Moodles,
with thousands of courses and
existing metalinks.
• mdl_course_metalink table was
removed from Moodle 2.
16. Student Enrolments
Data export Lecturers add Migrated
from student cohorts to from old
record sys. courses systems.
student › cohort cohort › course course › unit
city12345 HNDPHO student
city12345 HNDPHO11 student
city12345 HNDPHO12 student
Moodle
17. Sta! Enrolments
Data came Migrated
from legacy from old
systems. systems.
lecturer › course course › unit
awalker HNDPHO lecturer
awalker HNDPHO11 lecturer
awalker HNDPHO12 lecturer
Moodle
18.
19. Getting Data from MIS
• Central College (Glasgow)
developed a front-end for the Unit-e
student record system, called
Enquirer.
• Central College is now part of the
City of Glasgow College.
• We get Enquirer for free.
20. Getting Data from MIS
• Enquirer generates a CSV of the
student usernames and their class
cohorts.
• This CSV is automatically picked up
at midnight by our Moodle server,
which adds these records to our
enrolment database.
21. Getting Data into Moodle
• Moodle expects to read from one
database table.
• We used a view to pull the sta! and
student lists into one table.
22. Scalability
• 16,000 students.
• 20,000 student:cohort records.
• 1,500 cohorts added to top level
courses.
• About 30 ‘All Student’ courses
x 16,000 students = 480,000 rows!
23. Scalability
• Entire view contains 715,604 rows.
• Takes 5 seconds to generate.
• Moodle generates this view every
time a user logs in.
• During peak times, Moodle was slow
and unreliable.
25. Scalability
• Cache the contents of the view in a
regular table.
• Index the username column to
speed up Moodle’s query.
• Update the cache regularly with the
latest contents of the view.
26. Scalability
• select * from allEnrolments
where username=“awalker”
3.03 seconds
• select * from cachedEnrolments
where username=“awalker”
0.01 seconds
27. Administration
• When using the SQL database, only
the developer could look into issues
or change enrolments.
• Wrote a front-end, allowing the
Learning Technologists to modify
and troubleshoot enrolment issues.
41. Building Finder 2.0
• Finder can’t be easily released,
because it’s tightly tied to our
custom enrolment database.
• Work has just started on Finder 2.0,
which is modular and can be
released for those just using
Moodle.
42. Building Finder 2.0
• Renamed ‘Finder’ to ‘Inspector’.
• More detailed reporting tools.
• ‘Course info panels’ to show number
of assignments, forum posts and
"les in a course.
• New ‘Timeline’ feature to see what a
user has done, or what’s done on a
course.
51. Advantages
• Latest enrolment data automatically
pulled from MIS every night.
• Lecturers can add students to their
courses themselves, by cohort.
• New students automatically see
their courses when they log in for
the "rst time.
52. Advantages
• Non-developers have the power to
check, modify and troubleshoot
enrolment issues.
• Learning technologists have the
power to check and "x issues
themselves.
• No waiting for a developer to check
issues.
• Developer able to take holidays.
53. Disadvantages
• Lecturers and students don’t show
up on list of participants until they
log in for the "rst time.
• Newly enrolled users won’t show up
until the next time they log in.
• Can’t manage database enrolments
through Moodle. Have to edit them
at the database level.
55. Disadvantages
• ‘Yet another system’ for Learning
Technologists to use.
• New Learning Technologists already
familiar with Moodle still have to
learn Finder.
• Requires a developer in-house to
oversee and manage.
56. Future Improvements
• Working on Finder 2.0 (Inspector),
with a greater emphasis on reports
and a smoother work#ow.
• Get rid of meta links at the database
level. Use Moodle’s meta links, or
don’t use them at all.
