...
2. If there exists no data for the stroke rate/split we grayed out the "Plot" button and replaced the numbers with "- " or "- - : --" respectively. Users found this to be very intuitive and never confused that feedback with lost data (usually it meant their accelerometer or GPS were turned off).
...
All in all, our project was very well scoped and the user interface we settled on was a natural fit for the iPhone. We were happy with our designs and we picked the simplest ; we of them. We wanted the user to know how to use it immediately and not have to relearn basic iPhone user interface affordances. Our Our paper prototypes worked well and were very useful in determining which features didn't work and which did. The The medium of paper also made it easy to move around the UI when changes were necessary; for . For example we made the rows separate from the background (on the New Race screen) so that you could reorder the elements with ease and just simply flip them over when the race started.
Our computer prototype was not as useful as we thought it would be, but we did cut a few features after making it and rearranged several elements in the interface. We We don't think that the lack of usefulness came because it was a low fidelity prototype, but simply because we had already located most of the problems with our UI in the previous stage of paper prototyping. From From a design standpoint, building this digital prototype was probably just about as helpful as another iteration on our paper prototype would have been, but having a checkpoint for implementation was very helpful.
Our riskiest decisions were to include playback, maps, and acceleration plots (each had high technical overhead), but we managed to pull it off accomplish most of them because a few of our group members were already sufficiently experienced in Objective-C (the coding language used).