Design
Login page
The Login page is the first page the trainer sees. We wanted a simple user interface that allowed both the athlete and trainers to login.
Trainer - Home page
Logging in as a trainer takes them to the Trainer Homepage. The trainer's home page presents the trainer with athletes that he or she has been working with, giving them a snapshot of the health and injury status of the athletes they work with. The user can view the profile page for an athlete by clicking on their thumbnail if it appears, or using the auto-completing search bar if it does not. If the trainer wants to add a new athlete, clicking on the "add a new athlete" button brings up a form to enter a new athlete into the system. The look and feel of this page has changed very little since the original paper prototype. One important difference is the way new athletes are created; rather than having a "+" button next to the search bar, the button now explicitly states that it is for adding a new athlete. This helped with usability for first time users, who did not understand what the plus button represented.
Trainer - Individual Athlete
The trainer can view an individual athlete's program. The trainer can see his personal info (name, hometown, sport) as well as information about his health, injury history, and workout plan. In the upper right corenr of the screen is the athletes status; a short summary of his current health and buttons that allow the user to change that status. Below are three tabs: workout program, injury history, and notes. The workout program is the most interesting of these. On the left, the user can find exercises that can be added to the current program by dragging and dropping into the current workout. The sets and reps of exercises can be changed by clicking on the values, and exercises can be removed by clicking on the "x" button on the right.
Clicking on the injury history tab will bring up a list of the athlete's previous injuries and clicking on the player notes tab brings up a list of notes, which can be added to by typing in the box and clicking the add note button. This page changed significantly from the paper prototype. We removed images of the exercise to make the page aesthetically simpler, and changed the way dates worked. Based on the feedback we received, we decided that rather than having "Day 1", "Day 2", etc. it was better to organize the workout by weeks. Also, since many users seemed confused by the ambiguity, we changed the interface to give concrete dates as well. Finally, many users, in all of our user tests, struggled with adding exercises to the workout. Most didn't intuitively guess that exercises needed to be dragged and dropped, so we added a help message that told them this.
Adding a new athlete
The user sees this page when they want to add a new athlete to the database. This page allows them to enter vital information about the athlete. It has changed very little since our paper prototyping sessions.
Adding a new injury
Adding an injury to a student takes the user to this page, where he or she adds the basic information needed to update the athlete's profile page. We originally had the user enter a custom date, which caused formatting problems once we began implementation. We changed the date field to three separate input boxes for day, month, and year. Unfortunately, this added another level of confusion because users were unaware if January was 1 or 0.
Implementation
We used Ruby on Rails with Twitter Bootstrap as the main components of our implementation.
One workout per athlete - We chose to give each athlete one workout. We felt that an athlete can only be completing one workout at a time, so it seemed superfluous to assign them multiple workouts in the database. This design choice simplified the back end of our system, but limited some of the features we could add. For example, with only one workout per athlete, we could not show the workouts they completed for previous injuries.
Athletes belong to one trainer - We modeled the system to have each athlete belong to one trainer. MIT trainers say that each athlete works with a single trainer, but this limited other trainers from editing the workouts. Although it reduced the flexibility of the system, it provided a level of safety that only allowed the specified trainer to edit the workouts.
Two Way Notes Communication - Both an athlete and a trainer could add notes to the athlete's log. Originally, we built the system to only allow the trainer to store notes about the athlete. However, allowing both groups to write notes back and forth offered a more interactive communication between the student and trainer. We also added colors to the notes. We intentionally did not specify what the colors represent, giving the trainer the freedom to use the colors as they pleased.
Reordering of exercises - In our original decision, we wanted to add the ability to reorder exercises within a workout. However, implementations problems prevented us from being able to include this feature. (The feature actually worked, but it broke the drag and drop functionality. We felt the drag and drop functionality was more important to the overall usability for the trainer).
Evaluation
Users:
We conducted our user test with two MIT athletic trainers and one MIT student who has had a lot of encounters with athletic trainers. Since the site is a tool for athletic trainers, the athletic trainer is the core of our target population. We also needed one MIT student because they were the target user for the athlete side of Easy Trainer.
Briefing:
The users were given basic information about the class and the goals of our website. They were told that we would give them a set of tasks, observe them while they completed the tasks, and discuss any suggestions afterwards.
Tasks:
1. Create a new athlete, Josh Smith, and update his injury status to reflect a broken ankle.
2. Mark Kobe as healthy.
3. Remove lunges from his workout and add Clean and jerk (3x15) and add rows (3x10) for all 5 weeks.
4. Add a note to his profile saying that he’s recovered from his injury.
Usability Problems:
Trainer:
The user didn’t recognize a body area in the ‘create a workout’ tab and tried clicking ‘select a different body area’ label to search for it. This is not very severe. We should just make the label a search bar for body areas not being displayed.
In the add a new injury form you should be able to enter the date as the word instead of numerical. This is not very severe. We should just replace the input box with a dropdown.
The drag and drop functionality in ‘create a workout’ wasn’t obvious at first. We tried fixing this by adding a label saying ‘drag exercises here’ where a workout would go when the workout program is empty. In a real scenario the user would see this message before beginning to create a workout and there should not be a problem.This is not very severe.
He missed the significance of the colors in the note section.This is not very severe. Perhaps we could make selecting a color change the background of the input text box also to indicate the message will have that background.
He felt like we should be able to edit multiple days of reps for a single exercise at once. This would be a minor change.
He also said it would be nice to have a way to contact the athlete when updates to his profile are performed.
He thinks the dashboard player boxes should have more information such as the most recent note. He also suggested that a sort of news feed for recent injuries and notes could be nice to have on the dashboard also.
-Quick sort of trainer cards
Student 1:
When told to update a player’s injury status, this user was confused by the ‘select a body area’ list in the ‘create a workout’ tab. This is somewhat severe. Perhaps the create a workout area should be grayed out when the player is healthy. This would take attention away for it and allow the user to look at all of the page and see the injury section.
This user understood the significance of and used the colors for athlete notes.
When looking for Kobe Bryant it took this user a long time to find the athletes bar. Also when he found it he said that with the number of athletes a trainer is actively treating, showing them all in a dropdown is not very realistic. This is very severe. If we replaced the athletes dropdown with a search bar the user would be more likely to see it and know it needs to use it to find additional athletes.
This user had no problem at all creating a workout.
Student 2:
No problem creating athlete
“how do I find kobe bryant?” It took him a long time to find the athletes drop down. Again this is severe. The same suggestion applies from above.
He struggled to find how to add exercises (clicked around until he found the side bar). This is somewhat severe. Maybe we could make the workout locked in, and require the user to enable editing once a workout is set. Then the area would be in his field of view and more clear.
When trying to add an exercise he kept clicking the clean and jerk button (eventually figured out that he needed to drag and drop). The drag exercises here message should also be displayed on click and not just drag.
He had no problem changing sets/reps, or adding a note.
To add an injury, his first instinct to click injury history, but he found the actual button immediately after. No real problem here.
Reflection
There were two big things we took away from this course that we think we had all undervalued prior to the course; prototyping, and user testing. Most of us thought that going into this class we would learn more about what makes a good UI rather than the process of creating one. Even when presented with these ideas, some of us thought the idea of creating a paper prototype wasn't worth the time. It seemed nearly as easy to make the website in html and then later change whatever small things needed to be changed. I don't think any of us realized that getting a good UI on the first try just isn't going to happen, and the paper prototypes definitely allowed us to see problems with our UI before we created it. It was pretty surprising how some of the elements in our UI that we considered intuitive were anything but to the users we tested.