A goal tracking app for students with special needs
IEP Goal Tracker is a web application that helps teachers manage and track cognitive and behavioral goals of students with special needs.
Introduction
IEP Goal Tracker is a web app that makes it easier to manage and monitor the goals laid out in a student’s individualized education plan.
Key features:
- Create student profiles with IEP information
- Enter unique goals for each student
- Break goals down into distinct tasks
- Log evaluations
- Charts that show student progress over time
You can create an account and start using the free version of the app by visiting www.iepgoaltracker.com. Currently, you can only use the app by logging into a web browser (Chrome, Safari, etc.). I would suggest entering your student/goal information from your desktop or laptop. Once your goals are set up, you can open your web browser on your phone, login at www.iepgoaltracker.com, and log your evaluations with just a few taps.
If you’re a teacher interested in using IEP Goal Tracker at your school or have any suggestions for new product features (or have any other feedback at all), feel free to shoot me an email at jordan.england.nelson at gmail dot com.
The first part of this post explains how the app works. The second part is more technical and details some of the engineering challenges/solutions that I came across while developing the project.
Background
Every student enrolled in a special education program in the U.S. has what is known as an IEP, or Individualized Education Plan. An IEP is a legally binding document that stipulates which services the student needs and includes a list of performance goals (academic, cognitive, behavioral, etc.) that are unique to that student.
Students with special needs typically do not take standardized tests, so the IEP goals serve as a way to gauge a student’s progress (and a school’s effectiveness) from year to year. Goals are often quite simple, such as “Johnny will spell his name correctly during five consecutive trials” or “Sally will express her desire to go to the bathroom by raising her hand”. Parents can sue a school for failing to deliver the services outlined in an IEP.
Problem
Teachers have difficulty tracking student performance because goals are tracked by hand using pen and paper. Say a teacher has 15 students, each with 10 goals, the teacher is expected to rummage through 150 forms any time one of those students accomplishes one of their goals. For example, if a student’s goal is “After recess, Sally will wash her hands with soap, dry her hands, and throw the paper towel in the trash without being prompted by the instructor, during five consecutive trials”, the teacher is expected to document how well a student performed during each evaluation.
There is no state or even district-wide standard for gathering results. Data collection practices vary from school to school and district to district. Teachers may receive blank evaluation forms, but their rigid format does not accommodate the custom-nature of each student’s set of goals, which are, by definition, individual to that student. For example, if a student’s goal is “Juan will dress himself without assistance during 4 out of 5 consecutive trials”, a teacher may wish to break that goal down into separate tasks (say, one task for each article of clothing) so that incremental progress can be measured.
At the three schools I visited to conduct user research, teachers could only break goals down into 1, 5 or 10 tasks because they were only provided with spreadsheets with that number of blank spaces per evaluation instance.
Solution
A web app that allows teachers to create, manage and track performance of their students’ goals.
IEP Goal Tracker allows teachers to:
- create goals and attach them to student profiles
- digitally submit an evaluation that gets stored on the goal being tracked
- instantly see evaluation data charted over time
- break a goal down into as many or as few tasks as needed
IEP Goal Tracker — How it works
Since many of the target users of this app are non-technical, I designed the UI to be as simple and easy-to-use as possible. The hope is: if we minimize the friction associated with logging evaluations, teachers will be able to more easily log goal accomplishments (i.e. evaluations) in real time and keep more accurate records. Since those records are time-stamped and stored digitally, teachers will also be able to make better use of their data when writing quarterly progress reports.
Dashboard view
After logging in to the app, the user sees a list of all their students.
Future releases will include an admin view to allow administrators to see all students grouped by instructor.
(The app is built with Meteor, and the meteor-roles package makes it very easy to manage these kinds of sub/pub permissions.)
*
*
*
*
*
Student Detail view
After clicking on a student, a user can see all the goals associated with that student.
The student’s personal information and IEP details are also on this page.
I used the Bootswatch Paper theme to style the app, and used this Sass mixin for the background gradient on the login screen.
*
*
*
*
*
*
*
*
*
Goal Detail View
After clicking on one of the student’s goals, the user is brought to the Goal Detail screen.
This page shows all of the details for the goal, including a graph of all evaluations that have been logged to date.
*
*
*
*
*
*
*
*
*
*
*
Creating new goals
All forms in the app are based on the paper spreadsheets currently used by instructors in the Orange County Dept of Education’s special needs department.
One of the (many) advantages of using digital spreadsheets is users are not limited by the number of tasks that can be tracked on one particular goal.
The “Tasks to track” input in the form to the left maps to an array that can store as many tasks as are needed for each particular goal. The same goes for the “Short-term objectives”.
While short-term objectives are not required, each goal needs at least 1 task in order to log evaluations.
*
*
*
*
*
*
*
*
Writing the HTML and validation logic for forms can be a nightmare, especially for an app like IEP Goal Tracker, which is essentially a form management system.
Luckily, there’s Autoform, a Meteor package that autogenerates the HTML for forms by referencing the schemas that structure of your data. It does this by piggy-backing on top of another Meteor package called Simple Schema, which provides reactive schema validation.
In the code below on the left, you can see the beginning of my schema for the Goals collection. On the right, you can see the form that Autoform generates based on that SimpleSchema logic:
By defining the goals.tasksToTrack property as an array of strings (i.e. type: [String]), I am able to capture the tasks that the user wishes to track for that goal.
Later on, when the user wants to log an evaluation, I reference the goals.tasksToTrack array to generate a custom form for the evaluation (more on that below, in the Autoforms limitations section).
Structuring data with Simple Schema
After doing the user research for the app, the first thing I did was sit down and map out the schemas for my data. I knew I would need at least 3 collections: users, students and goals.
Since goals are unique to each student, I thought about making goals a subarray on the students collection, but after mapping out the goals object –which grew to over two dozen properties– I decided to break it out into its own collection. If I ever wanted to allow instructors to save common goals or to add them to a shared “goals bank”, it would be nice to have a dedicated goals collection to work with.
I considered creating a separate collection for evaluations, but since those objects are relatively simple (all they have is a timestamp and an array of task objects, each with a task description and a Boolean value for whether or not the task was completed successfully) I decided to attach them to the goal object to which they correspond. Unlike goals, which could in theory be reused for other students with similar IEPs, evaluations are meaningless on their own. They are defined by the goal that they are meant to evaluate.
To fully appreciate the power of Autoform/SimpleSchema, the only code I had to write to generate the form in the section above (Creating new goals) came from this tiny code block:
If you’re familiar with Meteor’s Blaze templating library and/or React, this will probably look strange to you because it looks like I’m using React to pass in a component called Blaze: <Blaze />
Which is exactly what is happening. Autoform only works with Blaze, so I needed to use Meteor’s blaze-react-component package to pass in a Blaze template that renders the HTML generated by Autoform. Kind of hacky, but it works, and it saved me countless hours of tedious tinkering with form logic/HTML.
Autoform’s limitations
When I first came up with the idea of IEP Goal Tracker, I knew I wanted users to be able to pull out their phones and log an evaluation with just a handful of taps:
1: Open the app
2: Tap the student being evaluated
3. Tap the goal they are being evaluated on
4. Tap the “New evaluation” button
5. Check the boxes of the tasks that were completed successfully
6. Submit the evaluation
This is the point where Autoform was failing me. No matter how much I tinkered with the settings, I couldn’t get the form to render the way I wanted it to.
I was storing evaluation instances as objects that lived on a subarray of the goals doc that each evaluation corresponded to. I did not like the way that Autoform creates forms for subarrays, because it would force the user to select each task from a dropdown menu before checking the “Successfully completed” checkbox. The form also just looked way to busy.
While it may have seemed trivial from a data management perspective, I knew that adding those extra steps — as well as the messy UI that resulted from several nested dropdowns — would make the app clunky, thus defeating the entire purpose of the app: make logging evaluations super simple.
In the end, I opted for creating my own custom form, which uses a pretty hefty helper function that takes the form inputs, creates a new evaluation object, and then pushes that object onto the goal.evaluations array of the original goal doc that’s being evaluated:
In the end, I was able to get the clean, straight-forward layout that I was looking for:
UPDATE (Oct 2018)
I have started work on this project again and will be releasing a mobile version for Android/iOS soon.
