One project I worked on last semester was for my job at RPI Helpdesk; we needed a system to track how many people came in, along with the general type of problem they were having. We had an old system in place that was written in python but it broke, and did not give the administration side that much information. I wanted to keep the same easy to use interface that the previous program had, along with add features. and give more information on the back end.

This system is used to be a white webpage, with 12 options on it. Then a new interface was added for the touch screen at the desk, this interface had 12 big buttons that used JavaScript to submit it. One of them was user-error, which was not recorded. There was nothing else on the page but these 12 buttons, which tracked the number of clicks per week.

An entire code rewrite was planned; MySQL was going to be used for the database, while the front end was JavaScript and PHP. JQuery was used to make JavaScript work easily across browsers.

While I was making this I was thinking of things I could add to the software, first the old options were built into the tool; instead of having the options build in the database holds available options and which ones the administrator wants active. The new version connects to the CAS (Central Authentication System) of the school; once users are authenticated they are given rights.  Administrators get a settings option given to them, which standard users don’t ever see that option.

JavaScript was used for the button submits, this way the entire page doesn’t have to refresh. At the request of the helpdesk workers, an indication was put in that the ticket was submitted successfully. The top right corner displays “Recorded, entry: #”, this starts at a black box and fades into that number.

The look started as a genetic design, but then at version 3.2 the program look on the look of the Print Queue webpage that the helpdesk hosts. This is the start to a unified look to helpdesk software. As a side note, the version numbers started at 3 because this is the third version of QuickLogs to my knowledge.  Also the main interface is in a folder called “lite” because for a time a enhanced interface was being worked on, a entire ticketing system that included full descriptions, tickets, and follow ups with students who came in.  With course work, this was scarped but the folder structure remained.

One feature that wasn’t requested but I put in for fun was ticket tracking, when a user is not logged in and hits a button then the transaction is recorded under user “default”. When a user is logged in then they are given credit for the ticket. This doesn’t effect anything with the users work, no incentives were given, just friendly competition. The system was in use for about half a semester and this feature was not used at all. Then when a handful of users started using that system, it snowballed into more and more of the users logging in. Now users wanted to beat their coworkers and thus remembered to log a lot more often then before when the data went into a black hole. Later we found in the code there was a stats page, but this was not shown to anyone but administrators who knew about it. Also the old system did not have any long-term user facing statistics, it gave the weekly number then reset. The new system graphs 30 days of problems, what percentage went to each; last 30 days tickets per user; finally, a chart of 24 hours, 7 days, 30 days, 90 days, 365 days and all time tickets recorded. That way the user gets to see their part in records recorded.

Another problem in the past for software like this has been a lack of documentation and information, after a student graduated and built a system like this all the knowledge was lost, it ran until it broke and a new person took over building a new one. Here the code was put on GitHub, all commented up.

That is a general overview of the QuickLogs project. It was a good learning experience for writing a whole web system. I got a enjoyment out of seeing people really use the system, and give feedback. At 8 months in there are around 5,000 records in the system at this point. Below is a gallery of two of the old interfaces, with 3 of the new ones.

 

GitHub: https://github.com/daberkow/QuickLogs