The Perfect Software

By Ross Woods, written 11 June, 2003
Revised 26 April, 2004 and 12 August, 2005. Reformatted Feb. 2014, 18.

 

This article is presented substantially in its original form. The central ideas are still valid: Data is typed only once into an online database by the person who originates it. The database permissions need to be hierarchical to reflect the role of each person in the process. Otherwise, however, many aspects of the article are now out of date because the quality standard has been replaced. Besides, some software functions are not suitably separated from the core functions of the database.

It is essentially a Learning Management System like Moodle in that in includes an assessment system with the ability to record assessment results. To this is added a student management system.

 

The main idea

This idea is not greatly different from the grades function in Moodle, except that it has a fully interactive database to support it. I once saw a college database that had the forms described. They looked like a regular paper assessment form, but were actually a database form.

Moodle and its add-ons have a range of features that a quite similar to those described later, but it does not have full data basing capacity for academic records.

The main idea of the database is:

• Data is typed in only once, by the person who originates it.
• Several schools could share the same database over the Internet.
• Each school might have several departments and/or campuses.
• Most compliance (e.g. AQTF) is automatic and electronic.
• It incorporates an archiving system so that the server maintains itself.
• It would generate qualifications, transcripts and statements of attainment in pdf form in a way that they could be printed out at other locations. It would also keep archived copies.
• It could generate reports for government.
• It could include time-tabling, finances, correspondence, work-log records, and a system of generating student statistics.
• All additions and changes to official records need to be approved by someone authorised to so so.

The website should also have a template for everything else that we do (e.g. training and assessment plans, student information, policy and procedures, blank forms for hard-copy printout, document register, staff induction, legislation, compliance systems, student induction materials, e-learning materials, html libraries, links to outside on-line resources, etc.).

The system depends of staff and students being computer literate and having Internet access. Teaching staff would need some training. Most of this is already available. Some of it is either expensive or tailor-made for particular situations.

 

Permissions

These levels are hierarchical, and somewhat resemble those of Moodle.

• Central administrators oversee technical functions and assign permissions.
• Academic deans have the rights to print off qualifications from the database.
• Supervisors are people in charge of academic programs. Their scope would need to be identified by school, branch or department. They have permission to view everything at lower levels and alter at least some records (e.g. based on complaints, reported errors, etc.).
• Editing instructors are people in charge of units and classes who can also edit their materials.
• Instructors are people in charge of units and classes, but can't edit materials.
• Tutors (including admin staff) are people with a right to view all information in their school, branch or department.
• Evidence gatherers may lodge records for assessment and verify students' work.
• Students only have a right to general information and their own information.
• Auditors can view everything but change nothing.

Like Moodle, at installation, the installer specifies the overall system administrator(s) who then authorizes others users downwards through the hierarchy:

• Each member has defined scope (what they can view-only and what they can change)
• Administrators can authorise other administrators below them.
• Supervisors can authorise other supervisors below them.
• There could be more than one person at any one level for any one item of scope.
• Supervisors authorise instructors, tutors and students, and define the level of moderation scope (the level on the hierarchy under which instructors teaching all similar Units would have to collaborate on moderation).
• People could be administrators, supervisors and instructors in any combination.

 

Student and staff applications

The point is that the person types in the information once over the Internet, and that's enough.

• It has a client management function that monitors inquiries, prospective students, and applicants (what people asked about, contact details, follow-up).
• Student or staff member fills in form on line.
• Student or staff member goes through any induction process.
• Supervisor verifies details (e.g. identity, signed paper form, certified documents, etc.) and approves form.
• Form contents are used to become a new record in student or staff lists. (This might be a copy sub-program i.e. copying contents of form boxes into appropriate fields in a data base record.)

There needs to be a way of doing applications and results in bulk for large numbers of students for the same course or unit.

 

Change of details

1. Procedure is the same for personal details, but old details are stored to an archive file.
2. Only supervisors can change academic records (e.g. through a grievance), and old details are stored to a kind of archive file.

 

Running a Unit

Supervisor assigns unit to instructor. (i.e. gives permission for empty class page). At that time, he/she also assigns a monitor or co-assessor and student list. These are generated automatically by a time-tabling program that schedules students, units, staff, rooms/locations, and equipment.

Instructor accesses library of validation and review notes from the people who taught the unit before.

Instructor posts full unit description to class page (unit title and name, name of instructor [and tutor if applicable], timetable, dates, purpose, outcomes, assessment activities, reading, etc. etc.) Staff use a wizard to simplify this process, so they didn't have to depend on what they can remember.

 

Assessment

The instructor/assessor posts the assessment procedure on a class bulletin board.

Students click "accept" or "not accept" to agree with the assessment procedure.

• "accept" is registered in class data
• "not accept" prompts a form be filled in and sent to the instructor.

At assessment time:

• Instructor saves any assessment tools (e.g. exam paper, etc.) not already provided in the Unit description.
• Instructor uses a standardised form to input results, his/her Unit review, and feedback to student.
• Results and feedback to student are posted to students' home pages.
• Unit review is sent to review and moderation folder, together with instructors details.

Students retrieve Unit results:

• Student clicks on his/her homepage link to see results
• Before seeing results, student fills in "happy form" (mixture of multiple choice and open-ended questions) and clicks to submit.
• Student sees new results complete with feedback to student from instructor. The opening of this is automatically registered in class data (i.e. that students have received the instructor's feedback)
• Students click "accept" or "not accept" to agree with the result. "Accept" is registered in class data and "Not accept" prompts a grievance form be filled in and sent to the supervisor.

When all assessments are in and posted from all classes that semester running that Unit in that scope, the program generates an interim moderation and review report comprising:

• Unit description information
• Feedback to students
• Review notes from each assessment
• List of feedback collated from happy forms
• Grievances

The instructor then adds:

• Details of co-assessment or reassessment
• Review conclusions

Report is posted to supervisor.

Supervisor approves or asks for improvements until it is considered adequate until he/she approves it.

Final moderation and review report is archived (I.e. saved to separate archive directory and deleted from the active directory. It might need a standardised format.) Only staff can view it.

 

Registers

• Staff
• Enquiries [Prospective students]
• Students
• Institutional risks and risk management strategies
• Units and Unit clusters
• OHS review report
• OHS hazard report
• OHS incident report
• Grievances
• Professional Development
• Insurances
• Attendance
• Billing (including discounts and scholarships)
• Staff wages (including payroll and tax)
• Staff hollidays
• Anything else we put in the End of Semester Review form
• Library
• Practicum placements
• Alumni database

 

Student records

Personal details (ID), full academic record, and finances.

 

Graduation

• Computer generates print-out of required data (diplomas, transcripts, Certificates of attendance, etc.)
• Student record is moved to archive.
• If the student continues to another qualification, there is something that identifies the difference.

 

Staff records

The database could also include full staff information, including identification details, full updated CV information (qualifications, publications, etc.) and a running log of professional development.

The staff member could view and change his/her own page, but only the supervisor could verify it for the changes to be actually made. The old records would go straight to archive.

 

Pages

Kind of page or form	Who controls it	Contents/Links to ...
Install	Programmer	Permissions
Staff form	Programmer (or Administrator?)	Submit / cancel
Student Inquiry form	Programmer (or Administrator?)	Student Application form All the stuff in the How to apply section
Student Application form	Programmer (or Administrator?)	Submit / cancel
Student Induction form	Programmer (or Administrator?)	Okay / repeat / cancel Your new student page
Log-on	Programmer
Administrator	Administrator	Permissions
Supervisor	Supervisor	Permissions (instigate below) Permissions (view only those hierarchically above) Timetable/calendar Archives Status of all current Units Class pages Staff lists Student lists Usage tracking Student section of website Staff area of website Moderation archives Unit description library Registers (grievances, ohs, etc.
Instructor	Supervisor	Current class pages Timetable/calendar Supervisor announcements Student area of website Staff area of website Moderation archives Assessment form Unit description library Registers (grievances ohs, students, etc.) Monitoring form (if applicable)
Tutor	Supervisor	Same as instructor
Student	Supervisor	Personal academic record Current class page Timetable/calendar Student area of website Instructor announcements
Monitor form	Basically an assessment form based on Cert IV TAA requirements
Unit description form	Instructor	Based on current template
Assessment form	Instructor	Based on current template
Staff Monitoring form	Monitor	Submit/not submit
Class	Instructor	Class list Unit description Instructor announcements
Grievance form	Administrator	Place for grievance

 

Moodle discussion

User talk: Ross Woods
From MoodleDocs
Added Feb '10

Projects for new developers

Here's a bunch of things below, some sections of which are systemic and interdependent. Basically, I want Moodle to automate as much as possible of my college admin as a database can. Presently we have to keep all these different data sets and relate them manually: Local campus student and staff data, local campus finances, central office student and staff data, central office finances, central office archives. That doesn't make sense. It could easily be all one program and Moodle is the perfect platform.

The more data entry and update that is done in the field, the less needs to be done in database upkeep. If people depend on the system and it's easy to use, we don't have to motivate them to use it.

Okay, after learning more about Moodle 1.9, I've found that some of the things I first asked for are now there, either built in to Moodle itself or in the website. For example, help is quite context sensitive and easier to use, and there is now a way to have a structure that allows for different campuses/ departments/ regions/ etc. There is now better a better orientation to Moodle tutorial for staff.

So here's my updated wish-list:

1. have a simple install wizard, with tick-box selection of features (aka modules) to be installed.
2. intuitive menus and wizards (Doing better, but could perhaps still improve. If someone looks at a screen and doesn’t know what to do, we’ve probably still got it wrong.)
3. orientation to Moodle tutorial for system administrators, with less techno-babble.
4. move selected add-on modules to the core and make them optional installs. This has started to happen, but some core items are still only available in modules.
5. have a way for students to input their own data by on-line application
6. have the full automated database of student information for administrators (admissions, personal particulars, enrollments, enrollment statistics, academic records, payments),
7. have a way for students to update their own data on-line, while keeping records of past details
8. have a way online for new staff to do staff induction and input their own data
9. have a way for staff to update their own data on-line, while keeping a record of past data.
10. graduate students/print diplomas and transcripts,
11. archive academic records,
12. take credit card payments (only one option available as a module and then its quite standalone, not integrated)
13. have an automated bookkeeping system to integrate online credit card payments, offline payments students data (e.g. billing, receipting, accounting, functions) and then export reports for institutional reporting, bank reconciliations, etc. Some of it could be adapted from Gnucash. That's a full accounting program and the GNU source code is easy to get.
14. manage staff, which are really just a special class of students from a database management point of view.
15. have a simple structure (and way of organizing) to differentiate between permitted areas: public website, library bookshelves, staff area, separate class area, separate campus admins, etc.

As far as I can tell, Moodle can't integrate these things so far through plugins, but it is all so closely interrelated and overlapping that the core needs to offer them.