...
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).
...
2. Several users tried to scroll the race view, only to realize that by starting the drag operation in the map cell, they were actually moving the map view. This lead to some temporary confusion (luckily it is reversible) and frustration since the scrolling is handled entirely by the iPhone and putting map views into table cells isn't standard Apple UI. We decided the best option would be to disable map view scrolling, since users will want the map to be centered on their boat anyways, and instead provide a slider that will customization change the zoom level if desired.
...
1. Each of our users, including those familiar with standard iOS interface elements, did not initially notice the scrollable nature of the recording race screen. When When asked to add notes to a race, they were confused and asked for clarification on the task (the Notes field is initially obscured on a new race). After After between 5 and 15 seconds, the users simply blindly dragged the screen, and were somewhat surprised when it scrolled, noting that that was not obvious. UnfortunatelyUnfortunately, there is no easy fix to this problem, as this is the standard iOS user interface style. If the data point is important to the user, they will find it.In actuality, there is a scrollbar that is displayed when the page is first shown, which indicates there is more data below, but most users didn't see it. One fix would be to make this scrollbar more apparent, either by lengthening the time it is there or increasing its contrast.
2. Some 2. Some of our users noted that it was not obvious that maps needed to be setup (oriented, zoomed, panned to desired location) prior to starting the race. Once the race had started and the users were examining the updating data, they wanted to zoom and pan the map screen. A design decision was made that all fields lose the ability to be manipulated during the race. This decision should be irrelevant because during an actual race, as the coxen or rower should not have attention to devote to manipulation of data fields. As mentioned in the second Major problem above, this could be fixed by not allowing for panning and instead putting in a slider that changes the zoom level.
3. Our second user wished that the notes section could be longer (~1/2 pages) for practice sessions, but this was also not implemented because of a design decision. Our We decided that our application should not support display of large bodies of text, as it is an app designed specifically to show many short snippets of valuable information simultaneously.
...
1. Our first user thought the thumb for scrubbing through playback data was a volume indicator, due to its similarity with the Music application in iOS. This user quickly realized the true functionality, but a fix to this would be to add a time elapsed and time remaining value just above the left and right sides of the scroll thumb respectively (this is how it is differentiated from the volume indicator in the iOS music application).
2. Another user was unsure if the screen he had entered when first handed the application to test was in fact the first screen. This screen does appear in the same way a screen in a view stack on which a previous user left the application when closing it. When asked directly, after the test, the user stated that it felt as though he was stumbling on where ever the previous user left the application. A possible remedy for this is to have a splash screen or a simple title screen that leads you to a list of data. This was originally in our design, but the idea was abandoned after no other features could be added to this screen. It is essentially a tradeoff between learnability and efficiency, and we decided to emphasize efficiency.
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.
...