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
- Problem summary
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
Professional Staff
- Did not immediately realize the jobs could be clicked.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Could not figure out how to make the job "important", instead made an update noting that the job was important.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- User hits submit after assigning a mechanic -- does this several times for changes to a job.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Had a very difficult time marking a job as "mechanical". Tried to filter and assign a mechanic.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- A lot of trouble finding all jobs in McCormick, eventually used search feature.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Attempted to click all to remove "McCormick" text from the search bar.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Assigned a mechanic and then clicked "submit" to save.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Difficulty creating a new job.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Kept using "Submit" on update form for any change made to the job, whether it was an update or not.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
Desk-worker 1
- Could not easily discern the meaning of "important", looked to add an important label.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Attempt to add label by filtering by the given label -- click "Mechanical" to add label.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Confused as to how communication with mechanic was done through the update widget, especially when no previous updates from mechanic listed. "Does starring let him know it's important? I don't know how to communicate him through this."
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- "This is really cool and addictive. I want to assign everything to Jenks Jenkinson and Billy Bobby because I'm Michael McIntyre and I don't want to do anything."
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
Desk-worker 2
- Cannot find a way to mark the job as "important" -- surprised when found the star.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Had difficulty finding a way to add a label to a job.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- User suggested having the "add a label" ability in the left-most column to be with the other labels.
- Could not easily find a way to find all jobs for McCormick -- did not realize search was possible.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Creating a new job did not immediately show up in the list because "McCormick" was still in the search bar.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
- Attempted to search for "Home Depot" in the job search bar.
- Severity: Cosmetic | Minor | Major | Catastrophic
- Solution:
Reflection
As a result of this project, our team learned that using an iterative design process, specifically the spiral model, results in a better product and also reduces stress and time wasted along the way.
If we had jumped right in and implemented our website before interviewing potential users or doing any user testing, we would have created a high fidelity product that might not have met users’ goals in terms of functionality, and the product probably would not have had a good user interface design. Then, if we were to conduct user testing after the high fidelity implementation, we may have been stubborn and not wanted to make changes that users suggested to us. Or alternatively, we would have wanted to make the changes users suggested to us, but that potentially would have required us to completely change the design of our interface, which would take much time and effort.
Using an iterative design process allowed us to build a little; get some feedback; make changes, improve, and build more; get more feedback; and so on. It gave us the opportunity to work with users and make smaller changes along the way instead of needing to make larger changes and redo large parts of the implementation process as might be necessary if using the waterfall model. Using an iterative design process forced us to think about the user at all times, and this resulted in a highly usable interface.
Paper-protoyping was useful to us for several reasons. Users didn’t have much time with the prototype so the best feedback this type of user testing gave us was on learnability, a huge part of usability. Giving users specific tasks to complete allowed us to gain insight into the user’s understanding of the system before getting to know it well (i.e., how they expect the system to behave). Also, we didn’t need to worry about the exact shape or color of particular features; we could focus on size and location of individual features as well as the overall layout of our interface. Additionally, it was exciting to see users successfully complete tasks during the paper-prototype user testing sessions, and this motivated us to actually include those relevant features in our implementation. On the other hand, seeing users struggle with certain tasks motivated us to find good solutions to those problems.
Having other students do heuristic evaluations of our website was also useful because they spent a lot of time with the website and carefully explored all aspects of it, from aesthetics to learnability to user control, providing useful insight.
If we were to do this project again, there are a couple things we could do differently. One, we would have thought more about how to incorporate categories like job type (e.g., plumbing) and dorm name (e.g., McCormick) into our design during the paper-prototype stage. We focused more on getting the general layout of our interface figured out before including this extra feature, and it turns out we didn’t implement filtering by job type or dorm name until much later in the process (during the final implementation), so our only chance to test this filtering feature was during the final user testings. It was a little stressful when we tried to incorporate this filtering feature toward the end of the implementation process. So much of the design had effectively been made concrete at this point and there weren’t many options for how to incorporate the filtering or many locations for where to include the filtering elements (we were a little unsure where to include the dropdown for adding a label to a job). If we had thought about this major feature of our design earlier perhaps we could have better incorporated it into our design and we could have gotten more user feedback. A second thing we would have done differently would be to conduct more user testing along the way of individuals in our user population (i.e., MIT dorm house managers) instead of just students. Unfortunately we didn’t have easy access to house managers, but if we had, it might have been nice to get feedback from them more often.
We really enjoyed this project! Using an iterative design process was very effective, and we feel like we learned a lot.