a) Group Name: Group 6 – GARP
b) Members: Gene, Phil, Rodrigo, Alice
Our product, the GaitKeeper, is an insole pad that can be inserted into a shoe, and an associated device affixed to the user’s body, that together gather information about the user’s gait for diagnostic purposes.
d) 3 Tasks:
In the first task (easy) the user will look at the display of a past run to evaluate their gait. They will use the computer interface to examine the gait heat map from an “earlier run”. The second task (medium) is a runner live checking how their gait is. The user will need to put on the GaitKeeper then go for a run and check the GaitKeeper display at their hip periodically. For the third task (hard) the user will go for a run with the device on, at the end of their run they will plug the device into the computer and check how their run went by using the UI.
e) Changes from the previous tasks:
We decided that some of our previous tasks were a little bit too broad for accurately getting an idea of how this prototype will worke. We are using the same basic idea of the previous tasks but we broke them down into the true individual components. Task 1 is the main functionality that both the running store employer and doctor will be interested in. Two of our previous tasks involved this task, we decided to pull this out as its own task as it is the easiest and most important user element to test. The second task is pretty much the same task we had in previous testings. This is still a component that needs to be tested and consists of one basic task. The third task is the full set of actions that would be required for either a runner to examine their own gait or a doctor or running store clerk to examine a client’s gait. This is essentially the same task as the tasks 2 and 3 from the previous testing, except that we realized that live heat mapping that we had hoped for in the previous task 3 was not possible, meaning that both the doctor’s and the store clerk’s needs would be very similar and this task captures what all users will ultimately need to do with the GaitKeeper to use it.
f) Changes to Prototype:
i) We changed the layout of the sensors. previously we had sensors on the front of the foot, the outer edge, and the heel. We have added sensors to the arch because several users commented that the arch was one of the most important places to have sensors, that way the user can check for internal pronation. We also had several sensor on the bottom of the foot (InsertInShoe.JPG) we now have only 2 sensors at the heel and 4 at the ball of the foot. This was due to the size of the sensors. We only had 4 smaller sensors and decided that more nuanced input would be better at the ball of the foot.
We changed the box containing the arduino to a hip box instead of an ankle box (Running2.JPG). This was because all testers said that that would be far more comfortable. We also decided to attach the real time display to the hip box instead of to the wrist. This was change was made due to the practicality of actually implementing the device. A wrist band would require have more wires run from the hip box to the wrist. Users commented on the potential discomfort of wires and having the display connected with the hipbox means adding no extra external wires to the device. The last change is that there is now a small ankle strap containing a breadboard, this was to minimize the number of wires that will need to run up a user’s leg. Users remarked that the ankle strap was irritating but we think that this will be small enough that it will not be too irritating.
g) New Prototype
i) implemented functionality: We have a simple user interface that has buttons for importing data and saving data. There is also a depiction of the insole with the sensors. There is a play and a pause button that will change the insole display based on the the pressures on the sensors over time. The display can also be changed based on a time slider. We have an insole prototype as well. This prototype has all of the sensors attached and was constructed so as to be able to change its size depending on the user’s shoe size. The insole is connected to both and ankle strap breadboard and a hip box containing the arduino. As part of the hip box there is a simple read green led display implemented for “live tracking”.
ii) We decided to leave out several screens from the ui. We left out the login system as well as the user and/or date selector. We did this because those pages were not necessary for the core functionality that we are interested in testing. Those would be ideal for an actual product, but are concepts that most people are familiar and do not really need to be tested. We also did not cover up the arduino. Eventually we want it to be in a nice little box with 2 leds sticking out, we did this so that we can easily access the arduino and breadboard to do more work on it in the future.
iii) The actual data that is displayed on the UI has been wizarded as has the “live tracking” that decides whether the green or the red led should be lit up. We decided to wizard the actual data because the functionality and understanding of the product is testable without real data. We wanted to make sure that the UI and device were well designed and something that users would be happy with before actually implementing the data collection and analysis. A change in our basic design could render any data reading and analysis we implemented useless. We wanted to create something that would provide us with good feedback while still not limiting any future design changes that might require.
iv) See previous sections for rational of what to prototype and what not to prototype.
v) The code for the UI makes use of the CP5 library, but was otherwise constructed by our group. The current code for the lighting up of the leds for the “live tracking” is a modified version of the code from Lab 1.
h) UI design: http://youtu.be/izl5lIuC3zQ
Prototype Pictures: https://docs.google.com/file/d/0B6XMC9ryo5M5WVpId1dJVTJ4ODQ/edit?usp=sharing