...

"New Race" pressed -> New Race Screen

1. This screen was the major aspect of our design, and the work we paid in 

2. Title editing is intuitive, again via use of standard iPhone affordance.

23. 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).

34. 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.

45.  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).

56. 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.

67. We also nixed the combined data rows because they are not normal iPhone affordances.

...

Playback Screen with navigation controls minimized

Implementation

Luckily, we chose to develop our app for iOS deployment. Apple provides a very nice set of UI elements that are standard and used commonly in most apps. This meant that most of our implementation involved dynamic data logging and displaying instead of trying to reinvent UI for the iPhone. Below are listed the two parts of our implementation that went beyond the UI and impacted some of our design decisions.

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.

...

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

Our 3 users were two MIT rowers and one coxswain. One of our team members knew them from rowing in a past year. Thus our users were very representative of our user population. Each of the users were comfortable with iOS, so we didn't need to introduce them to the UI that a regular iPhone user should know. We gave them the following briefing and tasks:

Briefing

You are a coxen of a crew (rowing) team--the person who sits at the back of the boat and uses her hands to make steering adjustments.  Additionally, you give the rowers encouragement and set the pace for the race (though you do not actually row).  Rowing generally takes place in a river, and rowers use oars to propel the boat.  The boat will accelerate/deccelerate based on oar movement.  Each pull of an oar is one "stroke."  The time it takes to row 500 meters is referred to as a "split." A Spring race generally lasts approximately eight minutes.

A coach is usually alongside you and tells you what your goal is before a race. For example, the coach may want the coxen to keep a close eye on the stroke rate and the split.

This application serves to monitor various race data, such as the stroke rate, split, total strokes, coxen's notes, and trail (the path taken through the river during the race).  It allows for monitoring of race data during a race as well as playback functionality to study race data after a race.

Your iPhone running this application will be mounted to the boat, directly in front of you.  Because you cannot use your hands to manipulate the application during an active race (they are busy performing steering adjustments and the like); you must pre-set all settings for this application before the race begins.

Tasks:

1. Set up a new race
   1. Re-order data considering stroke rate is the most important datum for this race and split is the least important
2. Start recording race data and cox (encourage and guide) your rowers through the race
3. Stop recording and save race data after race has finished
4. Playback recorded race data

After letting them read over these two sections, we let them use the app and took notes on some of the problems they encountered. Each is enumerated below with comments on how these could be fixed.

Catastrophic

1. Luckily, we only encountered one catastrophic problem, and it is a problem that we have been working on for several iterations. When you are in the new race screen and you press the "Ready" button, the screen immediately counts down for the race. Several users thought that they might have done this when the screen was set up but they weren't actually ready to race yet, in which case they might have to scramble to setup. To fix this, we realized that pressing the "Ready" button should just display a large "Start" button in the middle of the screen, and this button should start the countdown. This improves error prevention and correction and makes the outcome of the button much more obvious.

...

3. Part of the user tasks was to save the race data. Since the race data is automatically saved, some users were confused by this. We decided that when you first go to the race summary screen, the "Races" back button should actually say "Save". Every other time you go to the race summary screen, it should say "Races". This makes it more obvious that you are saving the race data.

Minor

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 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 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.  Unfortunately, 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.

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, the coxen or rower should not have attention to devote to manipulation of data fields.

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 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.sfd

Cosmetic

sfd

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.

...