CS6750 Assignment M3

Anna He
annahe@gatech.edu

Abstract— This series of M assignments seeks to investigate and

redesign an aspect of Strava: an exercise tracking and social media
app. In particular, the investigation will deep dive and discuss the
interface while the user is engaged in a physical activity i.e., run-
ning or cycling. The goal of this project is to use findings from the
investigation to improve the efficiency and ease of accessing
Strava metrics during an activity.

1 BRAINSTORMING PLAN

For this brainstorming session, I plan to allocate two fifteen-minute sessions this
evening a brief five-minute break in between. The intention of taking a break is
to prevent fatigue, clear my mind and refocus.

During the first 15-minute session, the goal will be on generating broad and very
distinct ideas. After a brief break, the goal of the second session will be to refine
and built upon ideas generated earlier. Ideas may be combined during this time,
or new ideas may emerge.

Ideas will be generated using a paper and pen. Ideas may be composed of a mix
of written descriptions and sketched diagrams. The more ideas generated the
better, but the general target is around 10 ideas or more. No judgement on the
ideas will be passed until after the brainstorm execution has concluded.

2 BRAINSTORM EXECUTION

Four overarching ideas were identified. Some include variations. Each unique
idea is accompanied by a heading. See the Appendix for the raw paper output.

2.1 Widget on lock screen

• No need to unlock phone with password, fingerprint, face recognition etc.

• Widget contains metrics? Map? Route? Options for map to be scrollable or
centered on current location only.
• Mini screen; not full screen to avoid confusion with unlocked interface.

1
• Only access to metric and map; no access social Strava feed
• Used for when stopped e.g. at a stoplight or brief resting or if phone screen
is continuously visible e.g. on a phone mount

2.2 Wearable-like: motion activated

• Swing like a watch wearable? Once swung show widget on lock screen
• Alternative actions: tilt i.e. if on phone mount or shake
• Phone might be shaken if user keeps phone in bag while biking/running,

2.3 Voice activated

• Requires mic and headphones to be audible over wind if user is moving.

• Especially on bikes; users may be moving quite quickly.
• Okay for metrics or numbers but not for seeing route.
• Needs beep or other feedback to confirm to user that activity has been
paused/started or to respond to query for metric data.
• Could this intervene if user is listening to something else (directions, music)
while running/riding?

2.3.1 Activate similar to Siri or Google voice

• “Hey Strava” to invoke

• “How long have I been running?” to receive information and data.

2.3.2 Activate with simpler commands

• “MILEAGE!” or “PAUSE!”

2.4 Tap on external phone e.g. back tap phone

• Different patterns of taps can represent asking for feedback.

• Users can keep phone in their pocket if cannot or does not want to take it out
• How does Strava respond and convey the information back?

2.4.1 Haptic feedback via buzzing/vibration

• May only be able to handle yes/no requests e.g. “Have I gotten any Personal
Records during this activity?”

2.4.2 Buzzing/Vibration convey information via morse code.

• Requires user to understand morse code likely without pen and paper.

2
2.4.3 Audible feedback

• User needs headphones or phone speaker nearby that is loud enough.

2.4.4 Visible feedback onscreen

• Feedback appears onscreen: cannot be used if phone is kept in pocket.

2.4.5 Alternate idea: taps are for pausing/restarting the activity only

• Needs a buzz to confirm the activity has been paused/restarted.

• Preferably different vibration patterns for starting/pausing so the user is cer-
tain of the action without having to check onscreen.

3 SELECTION CRITERIA

The first requirement from M2: to convey information on the lock screen without
the need to unlock the phone. All the designs meet this criterion.

Idea 2.1 (Strava widget on Lock Screen) was chosen for its consistency with the
Strava interface when the phone is unlocked. Strava already uses a simplified
interface while an activity is in progress. This idea is to move a familiar interface
into a widget form on the mobile phone lock screen.

The data inventory indicated that the user’s task is to complete a running a cy-
cling activity where there may be a lot of shaking movement. Idea 2.2 to trigger
Strava by swinging, tilting, or shaking the phone was discarded. It is too likely
that the interface could be accidentally triggered by shakes that occur naturally
while the user is running or riding a bike over a bumpy stretch of road.

Given the users are running or cycling, they may be out of breath during the
activity. Thus, Idea 2.3.2 (Asking “Hey Strava, what is my mileage?”) was dis-
carded in favor of Idea 2.3.1 (Command “MILEAGE”). Since running or cycling
competes for the user’s attention, more direct actions were prioritized. Thus, Idea
2.4.5 (Tapping back of phone to start and pause the activity) was chosen over
2.4.1 (Tapping specific patterns to the back of phone to request certain metrics).

The data inventory suggests both novices and experts using Strava, but many
ideas of 2.4 required significant additional expertise in other area. For instance,
Idea 2.4.2 suggests receiving data from the phone haptically via morse code.
However, decoding morse code is too much to expect from even expert users.

3
Idea 2.4.3 and 2.4.4 requires the user to make the request haptically but delivers
the response either audibly or visually. These ideas were eliminated because of
the inconsistency of feedback. Instead, it introduces additional subtasks such as
checking the phone screen and listening for the audio feedback.

Overall, ideas 2.1, 2.3.2, and 2.4.5 were chosen to be prototyped.

4 PROTOTYPE 1: PAPER PROTOTYPE OF IDEA 2.1

Idea 2.1 is a phone widget that displays on a user’s lock screen.

4.1 The Prototype

Figure 1 shows the designed lock screen widget as it would appear on iOS and
Android lock screens. The Metric Screen as displayed on the top two screens,
and the Map Screen as displayed on the bottom two screens. Switching between
the two screens is done with a swipe and is afforded by the two dots which ap-
pear and is consistent with other mobile interfaces. In either screen the user can
stop the activity with the dark circular button at the bottom of the widget. This
is consistent with the button found on the Strava app when it is open.

4.2 Revisiting Requirements and Data Inventory

The idea meets the usability requirement mentioned in M2 most directly. The
usability requirement was to convey information on the Lock Screen without un-
locking the mobile device such as a Lock Screen widget.

The data inventory indicated that subtasks included unlocking their phone to
check data during an activity. The data inventory also indicated that the navi-
gating the environment while running or cycling competes for the users attention
while they check certain metrics. This prototype attempts to reduce the amount
of attention diverted away from the users’ main task by reducing the subtasks
needed to check the metrics.

The data inventory lists the physical objects needed as mobile phone. This pro-
totype uses the existing objects that the user already needs without burdening
the user to carry more objects. Overall, this prototype is supported by the audi-
ence described in the data inventory while meeting all the requirements.

4
Figure 1—Strava lock screen widget as it would ap-
pear on iOS and Android Lock Screens.

5
5 PROTOTYPE 2: TEXTUAL PROTOTYPE OF IDEA 2.3.2

Idea 2.3.2 is the idea that a user can use voice commands to receive auditory
feedback on a user’s metrics and to stop or resume their Strava activity.

5.1 The Prototype

The functionality is that during an activity the user can say aloud certain key-
words and the app will respond with the corresponding metric. For instance, if
the user says “Mileage,” they app may respond “3 miles” or some other audible
reading of the current mileage of the activity. The user will be able to issue voice
commands and receive feedback without needing to unlock their mobile device.

The available metrics that the user can ask for are listed below. The keyword for
each metric is the name of the metric.

• Mileage / Distance
• Time (Elapsed)
• Elevation
• Pace
• Heart Rate
• Power

Both “Mileage” and “Distance” are available keywords to describe the distance
travelled. This accommodates users in different environments who may not use
miles as their main distance metric i.e. they may prefer kilometers.

For the time elapsed metric, while Time Elapsed is the official metric, the key-
word “Time” is sufficient as a keyword.

Finally, the user may also use the keywords “Stop,” “Pause,” “Start,” “Resume,”
and “Play” to pause and resume their activities. “Stop” and “Pause” will pause
the Strava activity. “Start,” “Resume,” and “Play” will continue the activity.

5.2 Revisiting Requirements and Data Inventory

The first functionality requirement mentioned in M2 was that the interface must
be able to record GPS data. Since a smartphone is required for this idea, the first
requirement is met. The next M2 requirement was usability: the interface must
be able to convey information without unlocking the phone. Since this design

6
uses auditory cues and feedback, the intent is that no functionality is kept behind
the Lock Screen, fulfilling the second requirement.

Of the data inventory, the physical objects that a user needs did not include head-
phones or speakers. To receive auditory feedback, the user may prefer head-
phones or speakers to hear the feedback from their phone. The user may use the
native microphone and speaker in their mobile device but an external micro-
phone and headphones may provide a clearer experience for the user.

The data inventory indicated that the user needed information and data on their
activity. Overall, the prototype idea mostly supports the data inventory by
providing the information that they need audibly while meeting the design re-
quirements of being hands free. However, it may introduce additional physical
objects that the user needs that were not captured previously.

6 PROTOTYPE 3: WIZARD OF OZ PROTOTYPE OF IDEA 2.4.5

Idea 2.4.5 is the idea that a user can tap their phone externally twice to start and
stop their Strava activity. The phone does not need to be unlocked for the user to
start or stop their activity via external tapping.

6.1 The Prototype (Script and Questions)

Researcher: This interface works by tapping the back of the phone. So, say the
Strava activity has already begun. The phone is in your pocket. You can Tap the
back of it twice to pause tap twice again to start it again. When you make the
action, I will mirror it on the phone. It will vibrate twice if it is being paused or
three times if it is resumed. Let’s try it by staring a Strava activity.

Anticipated Command 1: Tap twice to stop.

Researcher: Since the activity is started, the two taps will cause it to pause. Your
phone would vibrate twice but instead I will say buzz-buzz. Try tapping twice
again when you want it to resume. Okay I will say buzz-buzz-buzz to mimic a
vibration that happens three times.

Anticipated Command 2: Tap twice to resume activity.

7
Researcher: Buzz-Buzz-Buzz. Alright your activity has resumed. You may try
pausing and restarting again if you’d like. But to finish the activity you will need
to take out your phone.

Questions for feedback:

• Would you use this more for running or for cycling activities? How much
more for either running or cycling
• Do you think it is confusing that the input to pause and to restart the activity
is both two taps? Would you prefer two taps or pause and three taps for start?

6.2 Revisiting Requirements and Data Inventory

The first functionality requirement from M2 is to record GPS data to meet the
user task of uploading a Strava activity as described in the data inventory. Since
this design interaction occurs on a smartphone, it meets this functionality re-
quirement. A smartphone is already a physical object needed in the data inven-
tory; the user is not required to carry any additional items.

The second requirement is usability and asks that information is conveyed with-
out needing to unlock the smartphone. This design meets this usability require-
ment by conveying data haptically so that no phone unlock is required.

The data inventory suggests that the user needs data or information about their
activity to meet their identified goals, such as health tracking. Although this de-
sign does not explicitly convey metric data such as mileage or pace, it allows the
user to stop and start the activity, affording them more control over the time
elapsed metric. It provides adequate feedback by vibrating when the activity is
stopped or resumed.

Moreover, the data inventory suggests that the user context causes the running
or cycling environment to compete with the user for attention. This design re-
duces the cognitive load on the user by providing alternative ways to stop and
start their activity than the traditional Strava app screen.

Overall, this design fits the requirements of Assignment M2 while also meshing
well with the audience as described in the data inventory of Assignment M2.

8
7 APPENDIX: BRAINSTORMING PEN AND PAPER RAW DATA

Below is an image of the raw pen and paper from the brainstorming session.