Niles West Literacy Center Postmortem

I had an idea and tried to make it work. I dug myself into a hole on the first try, but got it right the second time around. I learned a lot in the process; here's my story.


Since my sophomore year, I've been a tutor for my school's peer tutoring center, the Literacy (Lit) Center. I noticed that towards the end of last year, there were problems with the tutor-tutee pairing process.
When a student walked in and asked to be tutored in subject X, the supervisor would have to yell out, "Who can tutor X?" The tutors were spread around the large room, so often available tutors wouldn't hear or wouldn't walk up to volunteer. Instead of teachers walking around, asking who could tutor subject X, a notecard system was created.

At the beginning of the period, each tutor would get out a notecard. These notecards included the tutor's name, photo, and all the subjects he/she can tutor. Good system, right?

There were some flaws.

  • There are sometimes 10 students waiting in line to be tutored. This means the secretary has to look through up to ~20 notecards for each student
  • The secretary moves a notecard over to a different pile once its tutor pairs with a student. This seems like a decent solution, but what if she forgets? What if the line is held up because the secretary is looking for a notecard that was hidden under all the others?
  • Let's say the secretary finds a notecard match for the student seeking help. How does she get the tutor to pair with the student? She has to manually track down the tutor or yell out for them.

This might've just been me, but I personally never saw the notecards being used by the faculty. Many times the secretary had to yell loudly because tutors either weren't paying attention or couldn't hear her asking who could tutor.

Meanwhile, I was participating in the Verizon App Challenge and decided that the Lit Center would be a good topic to focus on for the Education category. Come the due date for the idea, my entire group bailed an hour before the submission was due. I was pretty frustrated, especially as they chose to work on the problem I identified. I felt exasperated, but I was set on submitting the idea to the App Challenge.
I got a few friends to fill the spots at the last minute and we successfully submitted the idea proposal; however, we didn't move on to the next round.

To get permission for the potential app, I had already talked to the Lit Center's director and he was pretty excited about the idea. I didn't want to let him down, so I continued to work on the idea.


Version 1!

I don't think I had any plan for this. I did talk with my teacher about how to set up the database tables (databases/back-end were completely new to me), and I started with a simple PHP script. Made a couple of HTML pages, with Javascript to go with. After wandering somewhat aimlessly for a month or two, I found myself with this app:

  • Could sign in with school Google account
  • Login seemed to work. Logout, sort of. I remember signing users out by reference to ID not working, which was a problem.
  • Multiple SQL injection vulnerabilities, yay! These were in a public, non-obfuscated Javascript file. (Again, this whole 'database' thing was new to me.)
  • Just looking at my code for a few minutes made me really sad. It was disorganized, painful to manage, and at one point I found myself wondering why I wrote some lines, not even remembering putting them there.

So you could sign in with your Google account, and see yourself appear on the left or right side (student vs tutor). That was all. It was a painful experience.

Skip forward a month or two, when I started working at Dev Bootcamp.

They used some "Ruby on Rails" framework. Hmm, maybe I should try making the app with that.
Over time, I learned more Ruby, and then Rails, through self-teaching and assisting students. And I did learn something from my the first version of the project: make a plan.

Version 2!

I started by drawing out the data relationships in a SQL mapper. I was taking it slow, which was good. Some DBC instructors helped me out with this; I'm really grateful for the positive reinforcement. While I was taking this at a relaxed pace, I was still afraid of getting stuck like last time.

At one point, I was a little overwhelmed with the problem: All tutors are students, but not every student is a tutor. I ended up making a new table tutor_abilities, so I just had to check if the student ID had a record in there. Okay, ORM's planned out.

I then wrote out the models, views, and controllers (everything was in one controller, first Rails app :P). Got stuck for a week because I was, well, scared of Rails. It turned out that I just named an attribute class. Whoops. After I figured that out, I sped up. I was just really excited that for the first time, I could put in work, and Rails helped me get the results I wanted.

What the final project did:

  • Any student could sign in with Google account
  • Tutors could choose to tutor or to be tutored, students can only be tutored
    • Students choose what subject they want help with, and what topic they are studying
  • Tutor could edit their tutor abilities (how well they could tutor certain subjects)
  • Students appear on left side, tutors appear on right, tutoring sessions in the middle
    • Live updating via ajax requests (for example, pairs appear/disappear as they are made and finished)
    • Google account pictures shown next to elements for easier recognition
    • In a planned feature, tutors could be sorted by their abilities for a given student's subject, and students could be sorted in order of the subjects a selected tutor knows
  • When a tutor clicks on a student, they form a pair
    • The tutor then fills out a conference form that is emailed to the student and the student's teacher at the end.

In short, this was a graphical interface to manage the tutors and tutees in the Literacy Center.

I finished several weeks before school started, and was able to show a more-than-MVP demo to the new Lit Center coordinator. He liked it!

In the end, we tutors were trained more vigorously and the Lit Center rules were set more rigidly, so the initial problem ended up getting solved, and my software never needed to be implemented.

What would I change?

1. Testing
At that time, for some reason I didn't see the value of testing an application. I do now, and I think TDD would have been a good way to stay safe and slow like I wanted to.
2. Controllers
I put all my code in one controller. Routes could've been cleaned up too.
3. Front end
I would definitely separate different Javascript functions into different files. Is it really necessary to see all that ugly ajax code in the main js file?
Also, CSS: There was very little design, which I purposely didn't do. My excuse was "I'm bad at design", but I really could have drawn out a nice design and styled it based off that.

Honestly, I was really happy with myself about the latter project. I took it at a manageable pace, and for the first time, made a usable, functioning piece of software.