...
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.
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 analysistasks focused on the race view and playback, not on quantitative data analysis.
...
Navigating
...
We spent considerable effort in this phase of development considering the specific actions each upper navigation button would take, as this is the most fundamental way the user navigates through the application. Changing such simple things as the wording of a button or whether the button appears by default came to have large effects on the usability and learnability of our application. Additionally, enabling text fields to be saved either using the Done button in the native keyboard or using the confirm button in the upper navigation bar helped new users complete the edit they had set out to make without a second thought.
...
Implementation Problems
...
As the iOS standard user interface elements are few, well-known, and well-documented, we had a concrete idea of the interface capabilities at the outset of our implementation. Few major problems with the interface eluded us, and overall there were no shortcomings in the interface that significantly change the users' experience with our application. Small issues such as the difficulties in rendering graphs or dynamically replaying the acceleration data are not major problems, and do not affect the interface's usability.
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:
- Set up a new race## Re-order data considering stroke rate is the most important datum for this race and split is the least important
- Start recording race data and cox (encourage and guide) your rowers through the race
- Stop recording and save race data after race has finished
- 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.
...
Major
...
1. One user thought that she would want to input notes on the summary page of the race, so that she could reflect on it while looking at the data. We think that this could be fixed by adding a text field to the race summary screen that would allow the user to enter notes while seeing the summary data.
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 change the zoom level if desired.
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. 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.
...
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. 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.
...
Cosmetic
...
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.
...
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).