...

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

Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.

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.

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.

...