In a previous post I introduced an ‘at risk’ system we are trialing this term. Very simply, we are combining data from Moodle and the student information system into a webpage whereby the teaching academic can quickly ascertain which students may need some extra support. Feedback from teaching staff has identified a number of improvements that will need to be made for the next version which is due to start in term 2 of this year. These are:
- More intervention options are required at different levels. At the moment we are only providing the teaching staff with a mail merge option as an initial intervention. This is obviously inadequate and there should be a range of intervention options for teaching staff to choose from. These may include things like phone calls or SMS messages and the like. The important point being that the details required for the teaching academic to conduct an intervention need to be provided.
- Linked with intervention options are the levels of intervention. One thing we are seeing is students who have low levels of Moodle activity across a number of their courses. The intervention for a student who is not engaging across all of their courses is probably not the responsibility of a particular teaching staff member. The system should notify the student support centre by default in addition to providing the teaching academic with the option of referring the student to the student support centre.
- Tracking triage. At the moment our system does not track interventions that are made, based on the information provided. I am thinking of rectifying this with a doctor’s surgery approach. So when an academic raises an intervention event for a particular student, a case is generated and ‘patient’ history is tracked. This allows for the tracking of intervention effectiveness along with a range of reporting options. It also generates useful intelligence for the teachers taking on these students in future terms.
- The order of the student list. At the moment the students are sorted based solely on their GPA. The next version uses a basic algorithm that sorts the students based on the urgency with which they need support. This takes into account the student’s current course load, GPA and Moodle activity. The Moodle activity component is looking for consecutive weeks of low Moodle activity that we know from past experience is a useful indicator of a struggling student.
- Key dates. At the moment the system does not recognize key dates throughout the term. It needs to identify mid term breaks and assessment due dates for future version.
- Assessment submission and gradebook information. At the moment, this system does not recognize assessment due dates or Moodle gradebook grades. The grades that students receive for early assessments are a valuable indicator of how that student is tracking. This system needs to include assessment data in order to present a more complete picture to the teaching academics.
One other thing is bugging me with regards to this system. That is that the language that we are using is very much deficit language. Eg ‘at risk’ student. This suggests that the student is the problem and I do not believe that this accurately portrays the purpose of this system, which is to more efficiently personalize student support. Perhaps ‘student success indicators’ is a more positive way to frame it?