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
We have 2 prototypes, both geared towards supporting task examples 1 and 2.
The first prototype was meant to support long trips via transit, primarily for people who are anticipating a trip later within the day. The decision to schedule a meeting was thought out to provide anonymity for users. Under this prototype, we realized that two people may not start at the exact same location, and go to the exact end location, so we introduced a radius selection that could allow users to gauge approximate direction of travel. We had made the decision to primarily focus on public transit length trips, because we feel like that is a gap that isn’t covered by existing services. One priority we had was the control of geographic information. Although buddies would be displayed based on a filtering criteria, we did not want the exact location of the source and destination points shared, given that people may put in home addresses, and inadvertently expose private information about themselves. We noticed that this design has limitations in terms of availability, in that you can’t schedule legs of the trip to travel with different people, and for a trip to be successful, a single person has to be found that will go the majority of the trip. This design decision was made because we felt it would be safest to know that you have a buddy until you are near your destination. In addition, the atomic characteristics of each trip and each buddy would allow ratings to accurately reflect trips. The trip mode of the application, once a trip has started, has support for emergency functions, and basic pathfinding.
The second prototype was meant to support a more spontaneous approach, and possibly allow group travel in addition to individual travel. This prototype does not have scheduling capability, but uses a combination of cached GIS data, and a provided destination to determine if people around you are travelling in the same direction. These design decisions were made to support multi-leg trips, where buddies may drop off the trip at some point, and to provide more support for an individual user who is not able to find a buddy on their trip. As a result of these decisions, a trip with a buddy isn’t as atomic as it would be in the first prototype, which may dilute the buddy rating system, as there is no guarantee they’ve made a whole trip with someone. A key decision we have made is that the exact destination and location of a potential buddy, as per the first prototype, will never be displayed, however, a chat utility will be available to locate your buddy once you are there.
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:
- To find out what aspects about a buddy would make people feel safer and more willing to choose them over others
- 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)
- 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.