IT Request Tracker Trends

To view the applet, click here.

Project Overview

The IT department for which I work uses a web-based service request ticketing system called RT. Service tickets are created a number of ways, including filling out and submitting forms on the department’s website. Separate forms are available for specific requests such as requests for VPN accounts, or e-mail accounts. Tickets created from these particular forms are labeled appropriately.

The IT department routinely creates reports of tickets in RT (among other things) to gauge type and quantities of requests coming in. This helps management understand if resources (staffing, training, etc.) are sufficient and well allocated. Reports are made based on various criteria, and results are returned in the form of text, a list of all tickets matching the search criteria. The more tickets returned, the more difficult to interpret the results.

This visualization aims to more readily demonstrate to a user what the trends of tickets are. Besides just general usage patterns of the system (how many tickets are there total), what are basic trends of ticket influx? How many tickets are coming in during given time periods? How are these tickets distributed between the possible requests?

Data Collection

The user creates reports by querying the system from the web-based front-end. The result is contained in pages containing very basic ticket information, and links to each ticket’s page. Ticket number, ticket type (from the subject), date (broken down into day, month, and year), and time (hour, minute) were scraped from the HTML of each ticket page. Tickets are created through many other methods and for various other departments and groups, so the scraper (written in Python) first identified the relevant tickets. Of about 63,500 tickets in 2008, 1066 (roughly 1.6 percent) were appropriate for this visualization. The automated data collection encountered numerous errors of different sorts (not specifically recorded), and as a result required regular attention. However, the overall process was still less labor intensive than manually performing reports and manually extracting the data.

Design

The purpose of the visualization is to provide comparison over time of tickets created. A time series graph with bar charts showing quantity of tickets provides a straightforward visualization of change in ticket creation over time because the values to compare are side-by-side here.

An alternative visualization containing all ticket types at once, and employing an interactive timeline slider could show all ticket types side by side. A timeline slider could allow the user to see quantities of all ticket types over time. But this would only show shorter periods’ worth of data at a time. To compare different screens when they cannot be placed next to each other requires more mental effort and probably a lot of switching between views. An animated time sequence of this would be nice to watch, but wouldn’t be effective for data analysis.

The visualization begins at the year view, where each bar is a week’s worth of data. The user may select to view a month, where each bar is a day’s worth of tickets. Mousing over a bar brings up a breakdown of ticket types, which are color coded. To the right is the legend indicating which color represents each ticket type. Above the legend are mini views, which also act as links to what the view contains. The first is of the year. The other two are of months. When in a month view, these allow the user to move from month to month, and back up to the year.

Future Work

Additional features that would improve usability and usefulness of this visualization include scrolling (left and right) to view earlier or later statistics in user-specified quantities, and filtering of ticket types (ability to select any number of tickets to view at a time, with a line graph rather than bar graph). For full effectiveness, live and easily updated data would be useful as well. Once the visualization is caught up with existing tickets, keeping up with new tickets would be less time consuming than the initial data collection.