This project was my final project for the Tech Support class I took in high school. With it being chosen my the teacher from three projects I had proposed.

The project was intended to solve a few problems in the Tech Office involving the Chromebooks. Mostly with notifying the students of when their Chromebook was repaired. As well as notifying them of when their Chromebook’s charger made it’s way to the Tech Office.

Repair Notification

Before the project’s implementation when a student came in with a Chromebook that needed repairs they would fill out a sheet of paper describing the issue and recording their Chromebook’s ID number. Which every Chromebook had on a bar code as well as written on the front with a paint marker. The Chromebook with that sheet was then place into an intake pile and the student would be given a loaner. Later those of us in the Tech Office in charge of repairs would then take the ticket, perform the needed troubleshooting and repairs. And once done we would record on the sheet who did the repair and what was done. After that the Head Tech Support would then determine what period the student had Study Hall and send a paper note to Study Hall for that student to come pickup their Chromebook. And if the student didn’t have a study hall for one reason or another a note would be sent to the class they are in that current period.

For keeping track of who’s Chromebook was broken, who repaired it, and what was done to repair it this was fine. The main issue was when the notes where sent to notify the student that their Chromebook was ready for pickup. Often times students would either forget about it, or claim to forget about it in order to have a “newer” or “nicer” Chromebook in the form of the loaner. And while it was more often the case that they simply forgot there where a few who thought they could get a new Chromebook this way. This also caused another issue because we had a limited number of loaners.

So my solution was simple. As part of checking their Chromebook in for repair the students would be asked for their student email. The Chromebook’s status would then be entered into the system and tied to their email. And once the Chromebook was marked as repaired they would receive two emails a day. One around the starting time of 8 and another an hour before school was released around 2 or 3. When the student then eventually picked up their Chromebook the status would then be updated again to stop the emails.

Chargers Lost and Found

But that wasn’t the only issue that the project was intended to solve. Which how they distributed Chromebooks each one had a corresponding charger that was explicitly labeled as belonging to that Chromebook. This was to allow them to hold students accountable for losing chargers when they eventually turned in Chromebooks at the end of the year.

But being human, students would often leave chargers in a class. So what typically happened is the chargers would be sent down to the Tech Office. Where they would then be thrown in a box where they would become a tanged mess. Students would then come to see if we had their charger. Which would then result in upwards of 5 minutes digging through the box. Checking chargers to see if their charger was in the box.

And while this did work, it was time consuming and the students often times had another class to get to. So their options where to either be late for their next class or leave before they can be told whether we have their charger or not.

My solution was to also track the chargers. So when a charger made it’s way to the office the charger’s number would be entered into the system. And if the owner of the corresponding Chromebook had entered their email and Chromebook number they would begin to receive emails informing them that we found their charger. If their information wasn’t in the system though the list of chargers found could be easily searched through. So students could quickly check whether or not we had their charger without needing to dig through the box to simply be told that we don’t.

Implementation

All this was achieved using Python, with Google’s Spreadsheets API being used to implement a rudimentary database as well as a dashboard where techs could see information on Chromebooks that needed repaired or picked up. Google’s Gmail API was also used to tie into a Gmail account that would then send the emails to the students.

The system also required some sort of approachable user interface for students as well though. Which was done using the Python library PyQT4 to create windows where students could enter their email and Chromebook ID as well as search the Chromebook Charger List.

Unfortunately I don’t have images of the project when it was working. And sense I originally created the project some of the libraries I used such as PyQT4 are no longer supported. So in order to get example images would require me to rebuild the project to use PyQt5 as well as determine what has changed with Google’s APIs sense the project last ran.

Final thoughts

Overall it was an interesting project that did actually solve the problems it set out to solve. With it actually being deployed for the last three weeks of the school year as a demonstration.

There are some things I would change though. Such as the fact that I ended up using Python to create the interface. When I originally did the project the intention was to use something like a Node.js application for the interface. Unfortunately due to how the school’s filter was set up any attempt to access a nonstandard port through a browser would fail. Even if the server was hosted locally.

Other than that it I feel like I could call it a success. The project functioned as described and was delivered within the time constraints given. While also allowing me to learn how to interact with APIs while still in High School.