Author Archives: joseph so

In developing our medium fidelity prototype, we divided the functionality of the application into two parts to support the two phases in our experiment: buddy matching and walking.

 

How much horizontal and vertical coverage?

In terms of horizontal and vertical coverage of the application, we will have a vertical coverage for the selection of SafeBuddy and both horizontal and vertical for the trip. The user will be able to look at all the SafeBuddy profiles and inform the experimenters of their top 3 choices. The graphical user interface (GUI) of the matching section will have clickable relative links that will bring someone from a screen to another, cover flow, and have a realistic look to the envisioned system. However, it will not display other possible features of the application such as creating or cancelling a trip. The map will be both horizontal and vertical, including the map, timer, and the emergency button. The GUI of the real-time trip part will be fully realistic with regards to user interface (UI).

 

Simulation of Behavioiur

In terms of simulated functionality, we must be able to go through the flow of the system until we select a buddy, and from there, we must be able to pull up an application that will show a realtime map, with an emergency button. In terms of creating profiles, we will be manually simulating social media parsing. We will be manually pairing the participants based the results of the users’ top 3 choices instead of a matching algorithm. The functionality of the realtime part of the application is more fully featured, and will be able to do realtime location tracking based on an android application template, and will have a emergency button to simulate the emergency response design, that will contact one of the experiment staff.

 

Appearance

In terms of appearance, we will place greater emphasis on modelling how the application will work than on the actual outer design for this prototype. Hence, we will be using template UI elements, as to look like a standard mobile application, whereas a final implementation of the application might use custom UI elements.

Non Graphical Elements

Our interface includes non-graphical elements in the sense that matching algorithms, and geofiltering/fencing must be completed. We plan to get around these by limiting the choices to be made in the interface and by hardcoding some features in the mockup.

 

Prototyping Tools

We plan to implement our medium fidelity prototype in two parts. The real-time mobile app will be completed with a Google Android Studio map activity template, with an emergency button element. This will allow us to leverage data available during the trip. The matching section will be implemented as a Microsoft Powerpoint presentation with clickable relative links to ensure the flow is followed. In addition, Powerpoint is a platform that allows us to easily add slides like profiles, without having to use code. These choices were made because of the familiarity of our team with these tools, which reduced the length of time it took to create the prototypes.

 

 

Demonstration

A link to download the interactive buddy matching prototype is available here.

It is preferable to use Powerpoint 2016. Captions are available on each slide explaining functionality, and in presentation mode, the system is interactive in terms of navigation. Clicking on the appropriate buttons will show appropriate flow and functionality at each screen

 

 

Experiment Goals

From Blog #3:

1. To find out what aspects about a buddy would make people feel safer and more willing to choose them over others
2. To find out how people perceive safety when walking in a group or by themselves, and how this perception manifests physically (eg. in the form of shortened walking time when walking alone)
3. To consider limitations of the Safewalk service and the feasibility of extending its functionality

Revised Goals:

1. To find out what aspects about a buddy would make users pick them over other choices
2. To find out the differences in how people perceive their level of safety when walking with a SafeBuddy or by themselves
3. To find out whether the users’ expectations based on the SafeBuddy profile aligned with their actual experience during the trip

The major focus of our previous experiment goals from the Blog Update #3 was not on the SafeBuddy application, but rather a more general experience of commuting and using SafeWalk . We revised the experiment goals to cover the cases that are directly related to the users and the application of our design. In order to do so, we have revised our goals to narrow the scope by solely focusing on the experiences of the SafeBuddy. Specifically, our goal is to evaluate the effectiveness of our design in increasing the perception of safety while commuting.

 

Experiment method:

Participants

We plan to recruit a total of 5 new participants for this experiment, primarily through convenience sampling via direct face-to-face or online conversations. These participants will all be current students at UBC who are familiar with smartphones.  In addition to these participants, each team member who does not personally know the participant in the study will also be a part for the buddy matching, and also for the field experiment if the member is chosen during the buddy matching. This design was chosen as it allows a greater selection and variety of buddies for the participants to choose from.

 

Conditions

We plan to compare two main conditions in this experiment within subject: how the measures of feeling safe differs when one walks with someone else, versus when they are walking alone. By doing so, we aim to discover the extent of the impact of providing users who currently travel alone with a SafeBuddy. In order to do this, we will ask participants to go on two separate walks that are similar in lighting and distance. However, one walk will be of them walking by themselves, while the other will be walking with a buddy that they chose during the buddy matching phase.

 

Tasks

The following are the different tasks that participants are expected to complete in our experiment:

1. Given a selection of different profiles of SafeBuddies, rank the top three.
   1. Participants will be given profile cards with a picture, name, number of mutual friends, and a short two sentence self description of each buddy (that we will have participants provide).  See Appendix 1.2. for example of a profile.
2. Given a set path, walk alone from a designated starting point to the destination
   1. Participants will be told to keep the SafeBuddy application on them, with a map implemented to show and track their location and route in real time.
3. Give a rating of perception of safety from 1-5
   1. Participants will be given a simple paper survey to rate accordingly. See Appendix 1.1.
4. Given another set path, walk with your chosen safety buddy from a designated starting point to destination.
   1. This path will be different that the one in Task 2, but will be similar in other factors as discussed below.
5. Give a rating of perception of safety from 1-5
   1. Again, see Appendix 1.1.
6. Final interview with the experimenters

Note that both set paths provided will be very similar in lighting, distance, and number of people walking around. We plan to organize our walks around 6-7pm, by which the sun will have set and thus natural lighting will be relatively dimmer. Both routes will be set on the UBC campus and will have fewer people walking on it in an attempt to simulate a more authentic “late night” feeling. Also, the order of tasks 2 and 4 will vary for each participant to control for any participant bias for walking first alone and then with a buddy, or vice versa.

 

Design

The experimental design will be 2-condition, within subjects to identify how the subjects’ perception of safety change based on the use of the SafeBuddy application. The independent variable we will be modifying is the presence of a SafeBuddy. The results will not be significant when accomplished using a between-subject experimental design since we want to discover how individuals’ feelings change when walking alone versus walking with a SafeBuddy, not how the perception of safety might vary between different types of users. Additionally, individual differences such as individual preference and prior experience walking through the route in our subjects might change their perception of safety between the two walks. A within-subject experiment would allow us to better identify and analyze these cases.

 

Procedure

The overall procedure is designed to be completed within two 30 minute sessions for each participant, for a total maximum of one hour per participant. We will run the experiment over two different days for each participant. On the first day, the participants will be asked to rate their top 3 SafeBuddies based on the SafeBuddy profiles provided. Once all the participants complete choosing their top 3 SafeBuddies, the experimenters will pair users that included each other as the top 3. In the second session, these users will complete the remainder of the experiment by walking a route alone, walking with their paired SafeBuddy, and the post-experiment interview. We will provide a short questionnaire containing the Likert scale questions to the participant after each walk for them to evaluate their perception of safety. After both the walks are completed, we will interview the participant for further information to answer our experiment goals.

Apparatus

Matching Part

The participants will be placed in a room with the experimenters and the interface prototype, along with appropriate note-taking materials (Appendix 1.4) which will be used to record the participant’s answers regarding their process of evaluating the best prospective SafeBuddies.

 

Walking Part

The participants will walk two different predetermined routes on the UBC Campus around 7pm. There will be a experimenter at the destination point and an experimenter at the source point of the routes. The experimenter at the destination will have the questionnaire on a sheet of paper and a writing utensil. These routes will take around 10 minutes each.

 

Independent and dependent variables

• Dependent Variables
  • Perception of safety based on 5 pt scale
  • Satisfaction with buddy selection after trip (likert scale i.e. disagree -> agree)
  • Time of travel (given by phone)
  • Choice of SafeBuddy

• Independent Variables
  • Walking with a buddy versus walking alone
  • Route
  • Time of day
  • Pool of SafeBuddies that can be chosen

 

Hypotheses

H0: SafeBuddy application decreases or has no effect in the perception of safety

H1: SafeBuddy application increases the perception of safety when walking with a SafeBuddy

H2: SafeBuddy application increases the perception of safety when walking alone

H3: SafeBuddy application increases the perception of safety when walking with a SafeBuddy and when walking alone

 

Planned statistical analyses

T-test for:

• Perception of safety
• Travel time

Mean/Median/IQR for:

• Satisfaction rating of SafeBuddy choice

 

Expected limitations of the planned experiment

    The major concern for this experiment is that the experiment must be safe for the participants but also needs to recreate any natural unease and fear that the participant would normally feel when commuting. Since the experiment is designed to be safe by having multiple experimenters watch over the participants and takes place when it is relatively early and there may still be a degree of sunlight, the participants could feel disproportionately safe during their walk. To control the experiment, the same routes will be chosen for all participants. Although this attempts to limit undesired variations created when some participants walk in a route that is “scarier” than other participants, it will not eliminate variations caused by the individual differences between participants. Some participants may be more familiar with the route than other participants, altering their perception of safety. Another individual difference that cannot be accounted for is the participants’ personalities. The two participants’ comfort levels with each other could negatively affect their experience of walking with a SafeBuddy even if the participant normally enjoys walking with a companion more than walking alone.

 

Supplemental experiment materials:

1. Interview Questions (1.3)
2. Observation Sheet for Matching portion (1.4)
3. Questionnaire for rating (Can be part of interview) (see appendix 1.1)
4. User Profiles of each participant and group member

 

Appendices:

 

1.1.

Perception of safety survey given to participants at the end of their routes.

https://drive.google.com/open?id=1xF_1JSKeSRQ_4OQsjYS9ZqJmoL3R903ZZZktZWJpczY

1.2. Example of a buddy profile template

https://drive.google.com/open?id=0B0o8btIcsGf6dFhCaWhxdVlPaDQ

1.3: Interview Questions

1. What affected your choice of the SafeBuddy?
2. Do you think the SafeBuddy profile gave you a realistic expectation of your SafeBuddy? Why or why not?
3. What information on the SafeBuddy profile was not helpful in choosing a SafeBuddy?
4. What information was missing that would have aided you further in choosing a SafeBuddy?
5. Do you think walking with a SafeBuddy helped you feel safer? Why or why not?
6. Do you think the SafeBuddy application, or something similar is something you would use in the future regularly?
7. How did you interact with the SafeBuddy application during the walk?
8. Did you feel safe walking alone? Why or why not?

 

1.4. Observation Sheet for Buddy Matching

 

Profile	Number of Times Looked At	Patterns in viewing Buddy profiles	Notes
1
2
3
4
5
6
7
8
9
10
Total time taken to choose a buddy
Final Rank of Buddies (1, 2, 3)

 

1.5. SafeBuddy satisfaction survey given to participants at the end of their routes.

https://drive.google.com/open?id=0B0o8btIcsGf6V3hYcGc0MlBFS0U

Updated Task Examples

Our tasks examples 1 and 3 have not changed since the first milestone, which can be found here: https://blogs.ubc.ca/cs444safebuddies/2017/01/23/ms1-blog-update-due-tues-jan-24/

We are modifying task example 2 as follows:
Martin is currently a UBC student who lives on campus and stays out late to study most nights. As he usually heads home around 1am, he feels unsafe walking back to his residence by himself, and so has been using his phone to call UBC Safewalk to have people accompany him home. However, at such a late hour Martin is usually quite tired, and he dislikes having to wait at least 10 minutes (and often longer) for people from Safewalk to arrive. He also feels guilty for making people from Safewalk come to him as he knows that they are often going out of their way for him when they walk him home. Martin wishes that there were a system he could access on his phone that would help him connect with others who are close in proximity and are heading the same way as him as he heads home.

 

Low-Fidelity Prototypes Demonstration:

We have developed two separate prototypes, and have video walkthroughs for both.
Prototype 1: https://drive.google.com/open?id=0B8aGBg4UG1fLbm9NaUphRmtwM28
Prototype 2: https://drive.google.com/open?id=0ByPAcqv1hgMlVC1zRm1ZOE1OVFU

 

Walkthrough Report

We performed a cognitive walkthrough of our initial low-fidelity prototype (prototype 1) with two different people; for the purposes of this post, they will be referred to as user A and user B. The most common sources of confusion for both users were the lack of system status indicators, lack of instructions, and lack of feedback, especially in the sections where the user specifies the trip parameters such as start time and trip start radius. User B pointed out that using only Facebook to sign into the app could exclude some users from the application but considering our target users, this isn’t too big of a concern. User B sometimes missed the “next” buttons on the start and destination parts, which may have been a product of how difficult it was to differentiate the button from the background on a low-fidelity prototype. The messaging function was well understood and performed by both users, but user B had difficulty figuring out how to request a trip from the messaging interface and critiqued the lack of a profile picture in the messaging interface. User A expressed that they would have liked to see an “Uber-style display” of possible buddies, but this brought up the privacy and security issue of displaying users’ locations to strangers with unknown intentions in the interface. Both users seemed to like the idea of the emergency button, but there was some ambiguity as to its actual function.

In its current iteration, our prototype would likely fail to support all of the task examples as some users would be unable to figure out what our interface was meant to do and how to even set up a trip in the first place due to the overarching lack of instructions, feedback, and system status indicators. Ignoring those, task example 1 still would not have been completely fulfilled, as the user may have trouble figuring out how to request a trip with a buddy they’d decided to travel with. Our prototype interface allows the user to search for and contact other users heading in the same direction as her, but only falls flat in the aforementioned circumstances. Ignoring the issues above, our revised task example would have been fulfilled. The interface is designed for a mobile device, which allows the user to access the application “on-the-go”. It does not involve other volunteers or staff and only recruits buddies traveling in a similar direction, which addresses the user’s concerns about making others spend extra time to accompany him.

 

Proposed Goals of Experiment

Our experiment goals, ranked by order of importance and ability to test them, are as follows:

1. To find out what aspects about a buddy would make people feel safer and more willing to choose them over others
2. To find out how people perceive safety when walking in a group or by themselves, and how this perception manifests physically (eg. in the form of shortened walking time when walking alone)
3. To consider limitations of the Safewalk service and the feasibility of extending its functionality

               

To address these goals, we have developed two interface prototypes, which we aim to evaluate against each other. The main purpose of this would be to determine which interface is the most effective at helping us to accomplish our goals, and which aspects are more helpful than others in terms of user engagement. We plan to address goal 1 through our in lab experiment where we will show various participants pictures of potential Safety Buddies, and observe which ones they would rather pick. Goal 2 will be slightly harder to address in our experiment due to safety concerns of setting up an experiment at night, and so we plan to modify our experiment slightly and perhaps ask people through interviews about differences in their behavior when walking in a group or by themselves. The third goal we will address through direct observation of the Safewalk service, and comparing its functionality to our own prototypes.