Design
The design of EZ-FIX allows housing managers the ability to quickly process and assign jobs to the house mechanics (mechanics in this context refer to anyone employed by the facility staff for repair related purposes). EZ-FIX was designed to allow users (house managers) to easily filter and view information about repair requests, known by our system as jobs. As seen in the image above, a user is able to filter jobs by clicking in the left most column, view a listing of jobs in the middle column, and view specific information about a selected job in the right most column.
One major design decision that was influenced by the heuristic evaluation is the stucture of the middle panel. Initially the jobs listed in the middle panel were grouped into three different categories: unassigned, assigned, and completed. This allowed the user to quickly discern the status of a repair job and find unassigned and assigned jobs quickly and efficiently. We found this to be an issue during the heuristic evaluation, though. It became a problem trying to keep a consistent layout with a varying number of jobs in each section; listing all jobs in a group didn't work well, fixed heights of each group didn't work well, and finally hiding empty groups (zero jobs) didn't work well. For this reason, we pivoted and build the middle panel to list all jobs and provided labels to allow the user to discern job status. Every job is listed and has a colored label used to indicate the status of a job (green = assigned, blue = unassigned, orange = completed). Job assignment is indicated with a picture of the mechanic responsible for the job if it has been assigned or completed, otherwise the picture is default which allows for quick scanning of mechanic's jobs.
Another design stemming from the heuristic evaluation was the consistency of the right panel. Initially the design had action buttons (mark complete, assign, submit update) on both the left and right sides of the panel. Additionally, these buttons were not all the same style -- two were red while the mark complete button was default and looked very out of place. The purpose of this was originally to not attract as much attention but it seemed as if this back fired as most users noted this as a major area for improvement. As seen in the screen shot above the right panel was improved to be more consistent and streamlined. The mark complete button took on the custom styling, the assignment widget was improved to be more streamlined with more safty (unassignment), and the submit button for updates was moved to the right side in order to maintain consistency.
Implementation
EZ-FIX is implemented as a web application; it is written in html, css, and javascript. A choice was made to use well known, trusted frameworks as to mitigate cross-browser conflicts. For this reason, we decided to use Twitter Bootstrap's CSS and Javascript framework for major layout and JQuery for javascript functionality.
The layout of the UI is structured using Bootstrap's grid layout. There are three major columns: one for tabs/filtering, one for listing jobs, and one for displaying the selected job. In addition, there is a navigation bar that includes a system search and user options (logout).
The javascript is very cleanly separated into modular components. EZ-FIX mainly consists of models to hold the data, event listeners to capture user actions, and functions to handle user actions. There are 3 main models in our application: jobs, updates, and people. Each model is constructed with available information retrieved from Firebase (described below) and contains appropriate mutator methods.
There is technically no "backend" to our application; rather, we're using Firebase to persist all changes. Firebase provides a javascript library that gives an API to create, read, update, and destroy data. Every addition, deletion and modification to the database triggers and event to be called on each client connected. More succinctly, it allows us to easily handle creation and modification of data. All jobs, updates, and people are loaded onto the client through firebase as soon as the page is loaded.
The clean separation of concerns of our front end code allowed changes and new features to be quickly built. The typical flow is: a user makes an update to an existing model instance (stars a job, adds a label, creates an update, etc), the client side code calls the appropriate mutator method on the object, the mutuator method takes care of persisting the change by updating Firebase, finally the view renders the updated instance. The simplicity of this flow allows for additional features to be very easily implemented by simply adding the corresponding model methods and view changes.
Evaluation
EZ-FIX is designed for housing managers, as such it is ideal to do user testing on them. Unfortunately, the semester wrapping up and Bexley hall closing has consumed resources and we were only able to do user testing on one house manager. This specific house manager was part of our initial need finding and was familiar with the problem we were trying to solve. In addition to the one house manager, we were able to test one professional staff and two student desk workers. The professional staff is close to our target user population because she is responsible for contacting various services (elevator and plumbing repair) for jobs within McCormick Hall and cares more about the overview of the facility status. Finally, student desk workers were chose and the closest alternative because they are sometimes faced with repair requests and are well informed of the building status.
Users were briefed by being told of the problem -- that house manager have a difficult time organizing and prioritizing repair requests and the primary method for doing so it by making mental notes. They were told that they are acting as the house manager of McCormick hall and were not given a demo of the application. They were asked to speak aloud and especially note things they find confusing or visually unappealing so that we could get a better sense of the problems that they experience. A demo was not given because we felt that showing users how to perform different tasks would prevent us from finding learnability issues.
Users were asked to perform the following set of tasks, one after another:
1) You just marked a repair job as finished, but you need to get information about that job again. Find the important information about that job.
2) Record the fact that the “Elevator broken” job is important.
3) Record the fact that the “Elevator broken” job is a mechanical job.
4) Assign the “Elevator broken” job to Billy Bob.
5) Record the fact that the “Door lock jammed” job is finished.
6) Find all repair jobs related to McCormick Hall.
7) Record the fact that the “Toilet clogged” job is not finished.
8) Let the mechanic working on the “Toilet clogged” job know that the toilet has not actually been fixed and needs to be fixed immediately.
9) You realize there’s a cockroach infestation in the Maseeh Hall 1st floor restroom. Record that this problem exists and needs to be fixed by Jenks Jenkinson.
10) Find Home Depot’s phone number.
11) Find all jobs that have not been completed but are being worked on by a mechanic.
House Manager
Professional Staff
Desk-worker 1
Desk-worker 2
Reflection
Rebecca