Design
In order to showcase our design, we took a screenshot of each of the screens used and made some comments on them. Each comment highlights either an important design choice or a feature that was modified after receiving user feedback.
Start Screen
1. We removed the login screen because we determined that it was an excessive feature (iPhones generally belong to one person, so chances are high iCoxBox will only have one user per app). This also removed the logo-like image we had on the splash screen, which was deemed superfluous after our Computer Prototype.
2. We would have liked to have an alternative view for this screen that shows a map with all of the locations of past races to select from, so the user could essentially group and view past races by location, but this required far more technological overhead than it was worth.
3. Races are now sorted by date rather than by title, a change from our GR4 computer prototype.
Edit Pressed @ Start Screen
1. Here we used the standard iPhone UI affordance for editing and deleting entries in order to increase learnability.
"New Race" pressed -> New Race Screen
1. Title editing is intuitive, again via use of standard iPhone affordance.
2. Acceleration plot shows real time before race, instead of reading zero. (Note: This screenshot was taken with a device simulator, so acceleration plot is empty here, but would not be for a real user).
3. The dragging affordance used (the three dashes on the right of each row) were not as intuitive as we hoped; though again it is a standard iOS affordance, users did not seem familiar with it.
4. Large type makes data easy to read, even for a user who is at a further distance from the screen than normal (as the coxen will have the device mounted).
5. Early on, we thought users would want to save settings to use them for new races, but they showed little interest so we nixed the feature.
6. We also nixed the combined data rows because they are not normal iPhone affordances.
New Race Screen: Scrolled down to view lower elements
1. This map allows the same gesture-based controls that are available in the iPhone Maps application, which meant that users were intimately familiar with it already.
"Ready" Pressed @ New Race Screen -> Countdown timer
We added this countdown sequence (UI disables, screen shades, and there is a countdown from 3...2...1...Start!) after every user mentioned in the Paper Prototype that this would be necessary, in order to allow for the user to get ready to race before the data starts recording.
Countdown timer ended -> Live Race Screen
1. Once the race starts, we wanted to make sure users didn't feel like they should be editing the UI (since being in a race means that you will not have time to interact with the iPhone). We accomplished this by removing the affordances for dragging rows and editing the race title.
2. We still allowed users to scroll since a user might actually want to quickly take a peek at the other pieces of data during a race (if their coach tells them that they need to keep an eye on that). This improves error correction if they accidentally misplace the data but don't want to restart the race to rearrange it.
"Stop Race" Pressed -> View Past Race Screen
1. We organized the summary of our data into a table, using whitespace to delineate rows/columns. This was immediately intuitive to our users.
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 are turned off).
"View Map" Pressed from previous (View Past Race) Screen -> View Map Screen
1. Our view map screen shows a green pin where the race started, a red pin where the race ended, and intermediate icons indicating points along the path. Users found this feature very enjoyable and intuitive, since it looks very similar to Google Maps (and allows all the same gestures).
"Playback" Pressed -> Playback Screen
1. Our controls overview had several iterations, but we are very happy with how it turned out. The hide/show button was initially placed on the top navigation bar, which was inefficient and not intuitive. After our first computer prototype, we modified it and users found this much easier to use.
2. We decided to make the UI for using the playback screen exactly the same as the pre-race screen, so that users found it natural to drag rows and scroll around. The controls overlay didn't confuse anyone since it is clearly an overlay (the transparency give it the appearance of a window placed over the original view).
3. Our controls interface is very similar to the iPod controls, which improved learnability. Unfortunately, some users were confused at first by the slider; some thought it was for volume instead of a time-controller. Once they tried it once, they realized what it was and thought that the scrubbing was very intuitive and natural.
4. As the race plays back, each piece of data is added exactly as it would be if you were recording the race again (the map updates, new strokes are logged, etc). This allowed users to playback a race and view the race again as an observer instead of a participant.
Playback Screen with navigation controls minimized
Implementation
Data
Our initial designs kept data separated by user login so that you needed to login before any races would be logged. We cut this because it was a large feature to implement that wouldn't be used other than the first time you turn on the app, and there were many more interesting aspects of our UI that we wanted to iterate on. However, we kept our data saved on a hierarchical per-race basis (a race holds collections of GPS points, accelerometer points, and stroke points; each collection of points is a timestamp and a value, and so on), which would allow us to abstract it again so each race is saved on a per-user basis if we wanted to add logins back in.
Similar to cutting the login feature, we cut our voice recording feature and our data sharing feature, since the UI wouldn't be interesting to iterate on but it would involve a substantial amount of extra effort during implementation.
Plotting
Our plotting is currently very simple; it simply shows a line graph of the saved split and stroke points. We decided to focus our efforts on the race view UI and ignore the plotting UI, so you cannot compare pieces of data or show a plot while viewing other pieces of data. This is because our tasks focused on the race view and playback, not on quantitative data analysis.
Evaluation
details
Reflection
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 wanted the user to know how to use it immediately and not have to relearn basic iPhone user interface affordances. Our paper prototypes worked well and were very useful in determining which features didn't work and which did. The medium of paper also made it easy to move around the UI when changes were necessary; 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 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 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 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 because a few of our group members were already sufficiently experienced in Objective-C (the coding language used).