Understanding the Effect of “Safety” on the Ambiance of McKeldin MallSubjective Safety and Objective Safety Team Ambiance: Patrick Carroll, Jr., Michael Gubbels, Priya ShetyeHuman-Computer Interaction Design MethodsUniversity of Maryland, College Park

DescriptionThe McKeldin Mall is a nine-acre space on the University of Maryland, College Park (UMD) campus

valued by students, faculty, staff, administrators, visitors, and others as a space for personal, recreational, institutional, and other activities. McKeldin Mall is both a public space iconic of the University of Maryland and a place of personal meaning that develops through experiences within the space. Users of McKeldin Mall understand it as a sacred space, “green” and natural, to be preserved through the stewardship of its community, as well as a democratic and free space with loosely-specified regulations and a strong sense of community. In this paper, we describe our project understanding how technology can enhance the ambiance of the Mall by making its users feel safe. “Safety” is a critical aspect of the Mall’s ambiance that profoundly affects many of its users understanding and use of the space. One of the major findings of our previous research was a divergence between subjective (or perceived) safety as reported by individuals on McKeldin Mall and objective safety measured using statistical dispatch data provided by the University of Maryland Police Department (UMDPD). Users of the Mall consider it a “safe space” by day, but feel unsafe at night due to the nighttime Mall’s “spooky” ambiance. The potential for spontaneous social interactions that occur during the day are understood as potential for being harmed and cause Mall users to feel unsafe—more unsafe than our metric for objective safety suggests. We present a prototype and evaluation of a smartphone application designed to make users feel safer while using McKeldin Mall, especially at night. We have chosen this from previous designs exploring intelligent lighting and wearable safety as alternative technologies to enhance the perceived safety of McKeldin Mall.

Requirements SummaryOne of the major findings of our research was a divergence between subjective feelings of safety as

reported by individuals on McKeldin Mall and their objective safety as suggested by dispatch statistics provided by the University of Maryland Police Department (UMDPD). This means that users of McKeldin Mall don’t feel as safe as they likely should feel. This may mean that users of the Mall may not benefit as fully from the space as they would if they felt safer. Because of this disparity between subjective and objective safety, our project has focused on increasing individuals’ perceived safety to reduce the disparity between perceived safety and actual safety. We have derived the following design requirements through a series of interviews, discussions, and evaluations of a paper prototype with current and prospective users of McKeldin Mall as well as some

1

individuals outside of the University of Maryland community.

● Increase perceived safety. Our system must increase individuals’ (virtual) perception of safety, while providing a mechanism to obtain immediate (physical) emergency assistance, when utilizing the McKeldin Mall during all hours of the day.

● Integrate with existing, familiar, trusted safety systems. The technology shall interface with existing emergency management systems (i.e., Public Emergency Response Terminals (PERTs), University of Maryland Police Department (UMDPD), UMD Auxiliary Police Units, Closed Caption Monitoring System, and Escort Program).

● Offer reliability to gain trust of users that our system can help them when they feel unsafe or situations when they may be harmed. The technology, while interfacing with other UMD safety systems, shall have a 99.999% reliability and availability rate (“Five nines” is associated with a systems design approach of high availability that is widely utilized and understood in telecommunications and computing sciences disciplines that ensures a prearranged level of operational performance standards1). The application must maintain this rate of reliability and availability for it to be effective as a security technology.

● Design a simple, intuitive interface. Because users are concerned with safety, our design should require minimal effort and provide a pleasant, comforting experience that enhances perceived safety.

● Design for efficient interaction and interface design. The technology shall have an efficient and effective user interface to ensure minimal user workload in the procedure to invoke the emergency assistance functionality of the application. The task sequence to transmit an emergency assistance signal shall take no more than three human interaction steps to be performed in less than four seconds.

● Design a pleasant visual interface to improve feelings of safety. We must design a visual interface conducive to feelings of safety and security.

● Support quick access to relevant emergency systems to enhance feeling of safety. The technology shall transmit an emergency signal to existing UMD emergency management systems within three seconds after invoking the procedure to obtain emergency assistance. The response time of emergency assistance shall utilize current response rates by the UMDPD and local emergency responders.

The technical requirements will be described in more detail within the included wireframes, mockups,

and prototype.

Prototype

OverviewmPERT is a smartphone application designed to enhance perceived safety while offering mechanisms

to call for assistance in emergency or potential emergency situations (e.g., theft, physical harm, etc.). We designed mPERT to serve as as a “comfort object” based on our findings that simply having a cell phone can bring some people an enhanced sense of safety and that talking to a friend, family member, or other trusted individual can make one feel safer. We designed mPERT to be easily navigable so users can quickly obtain emergency assistance (such as from UMDPD or other local law enforcement) or share contextual information

1 J. Gray, “High-Availability computer systems,” IEEE Xplore Digital Library (September 1991): Volume 24, Issue 9, pg 39-48.

2

with trusted individuals (such as a friend or family member) for additional security. We designed mPERT to be simple. Once the application is opened two options are features as large buttons designed to be easily and accurately activated when walking, running, and struggling. The two buttons are HELP and SCARED. The HELP button makes a direct call to the University of Maryland Police Department making obtaining emergency assistance simple for the user, as they only need to press a single button vice having to run to a PERT located within the Mall. The SCARED button sends geo-location information, a text message, and email notifications to individuals configured by the user.

Detailed Prototype Description

Paper Prototype

The following sketches were utilized for initial concept development. We used this paper prototype to gather preliminary feedback from users for use in designing a high-fidelity prototype (discussed in the next section). This paper prototype served as the basis for changes in both requirement and interface in the high-fidelity prototype. These also visually represent the progression of our design process from our initial sketches to the current prototype.

3

Figure 1. Low-tech prototype of mPERT application. (Top left) Photo shown on a smartphone screen prior to unlocking it. (Top right) Unlocking interface. (Bottom left) One configuration of the Mobile PERT application

interface. (Bottom right) Prototypical layout of applications on smartphone.

4

Figure 2. (Continued) Low-tech prototype of mPERT application. (Top left) Options shown under menu interface. (Top right) Profile of smartphone owner to be used by the application during emergency situations.

(Bottom left) “Emergency Profile” settings specified by smartphone owner about emergency contact destinations. (Bottom right) “Track Me Profile” settings for specifying individuals who can track the smartphone.

5

Figure 3. (Continued) Low-tech prototype of mPERT application. (Top left) Configurable alert settings. (Top right) Configurable weather settings. (Bottom left) Placeholder

interface for monitoring nearby traffic conditions (e.g., map). (Bottom right) Interface for selecting feeds from cameras placed on McKeldin Mall (e.g., on the traditional, stationary

6

PERTs).Figure 4. (Continued) Low-tech prototype of mPERT application. Shortcuts to specific maps of interest to individuals that use McKeldin Mall, such as maps of the Mall, parking lots, as well as a campus map.

Prototype

We built a high-fidelity prototype using the Justinmind Prototyper Free2 software based on our paper prototype and the feedback we collected for using the paper prototype. This high-fidelity prototype incorporates the requirements described in the Requirements Summary section into the visual design (beyond layout as was the extent of consideration for the wireframing in the paper prototype), tuned based on feedback. Figure 4 shows prototypical “locked” and “application” UIs for the iPhone.

2 http://www.justinmind.com

7

Figure 4. Prototypical iPhone “locked” (left) and “application” (right) interfaces.

Upon opening mPERT, the user is presented with the interface shown in Figure 6.

8

Figure 6. The mPERT main (left) and HELP (right) interfaces. The HELP interface (right) is shown after pressing the HELP button in the main UI (left).

This interface features two large buttons, HELP and SCARED, that provide users access to the functionality of mPERT. There is also a “MENU” button that enables the user to make configurations.

Help Button

The purpose of the HELP button is to connect a user who feels unsafe to an emergency service such as the campus police that can reliably respond to a serious emergency situation. It covers slightly more than half of the total screen area to make it easily accessible while quickly walking, running, or struggling—activities that might happen during emergency situations. When pressed, this button causes the interface to show two sources of help, EMERGENCY and FRIEND. EMERGENCY connects to a dispatcher at the UMDPD Emergency Management System (i.e., 911). This button is located at the top of the screen so a user can double-tap to reach the UMDPD quickly. Requiring users to double-tap also reduces the likelihood that they will accidentally call an emergency response dispatcher. This functionality is equivalent to that offered by the traditional blue PERT stations located across the UMD campus, but is available at all times from any location within service range of a smartphone running mPERT. The FRIEND button connects to a specified “emergency contact” that should be a trusted friend, family member, or other relative that can likely provide help at any time.

When either of the EMERGENCY or FRIEND buttons are clicked, mPERT connects to the corresponding source of assistance—an emergency response dispatcher for the HELP → EMERGENCY

9

interaction sequence (i.e., double-tap on HELP) and trusted individuals when for the HELP → FRIEND sequence. These interaction sequences will lead to one of the following screens.

Figure 7.

Scared Button

The purpose of SCARED mode is to provide an experience that can enhance one’s sense of safety. We designed this mode based the findings that simply having a cell phone can bring people an enhanced sense of safety and that being in contact with a friend, family member, or other trusted individual—such as by telephone call or text messaging—can make one feel safer. We designed on the conceptual basis that cellular phones can be “comfort objects”. Considering these findings on this basis suggested a number of design possibilities to enhance subjective safety that we built into our design of SCARED mode.

We designed the mode to instill within scared users a sense of connection to trusted individuals. We did this by displaying the relative location of individuals in one’s social network of trusted peers that have been added to mPERT. Individuals are visualized on the map as avatars that they select Figure 8. Simply knowing that others are aware of one’s location seemed to reassure interviewees of their safety. We believe that seeing one’s friends and their relative locations may enhance perception of safety because it situates the scared individual within a social context in which others are aware of their location. If individuals are outside of

10

the visible region of a map, their avatar is shown next to an arrow indicating their direction with respect to the scared individual.

Figure 8.

We also designed to decrease feelings of aloneness by designing the SCARED mode by showing users that trusted people are aware of one’s situation.

We also designed the SCARED mode to allow scared individuals to reflect on their perceived safety. In the scared users interface, users can specify the degree to which they feel safe using an interactive slider bar Figure 8 (left). The level of fear corresponds to a color value that ranges from shades of green (feel safe) to shades of yellow (feel a little to moderately scared) to shades of red (feel scared to extremely scared). This information is visualized to both the scared individual and their friends as a colored circle at the point corresponding to the scared individual’s location (tracked using GPS). Small circles are periodically drawn on the path that the scared individual has travelled to indicate how scared they were at previous locations and times. These may help scared individuals and their friends to reflect on the situation by relating perceived safety to time and place—by situating perception within their actual environment.

The map of the space shows the scared individual’s starting point, destination point, current location annotated by a color corresponding to perceived safety, and directional information. This map is viewable to both the person feeling unsafe as well as their network of friends Figure 8 (left and right). Individual’s in

11

one’s network of friends that confirm that they have received the request to connect are shown on the map or indicated on the sides of the map, indicating their direction (and distance). We believe this can increase perceived safety in a number of ways:

1. Scared individuals can see and follow a representation of their chosen path to their destination. Because the scared individual’s friends can also see this information, which may provide them with additional comfort that others know their whereabouts.

2. Users may feel less alone because they are aware that trusted people are aware of their situation, including their original location, destination, feelings of safety along the way (and breadcrumbs indicating perceived safety over time), and the direction being faced.

3. The knowledge that others are aware of one’s current whereabouts, destination, and planned path to the destination may give a sense that friends can react to an unexpected situation, such as deviating greatly from the selected path to the destination.

4. Having a phone can increase perceived safety. This suggests that having an “outlet” where one can express feelings of unsafety might bring increased feelings of safety. We expanded upon this idea, in SCARED mode by allowing users to easily specify how scared they are using a slider, positioned on top of a map.

Menu

The MENU option provides the user configuration options for the application such as predefined individuals to be notified when using the SCARED mode, configuring the device’s screensaver and power settings. When a user selects the MENU button they will receive the interface shown in Figure 9 (left), which will enable them to make changes to the mPERT configuration.

Figure 9. The UI for user-specific configuration options initiated by pressing the MENU button on mPERT’s main interface.

12

Menu: Update Profile

When the user selects Update Profile the following sub-menu will request that the user enter in their name, emergency contact information and telephone number. This information will be utilized to send text messages and GEO-location information when the ‘Scared!’ capability is selected. Three additional contacts can be added for a total of four emergency contacts that will receive text and GEO-location information. When a user taps any of the text areas to add in information, the below sub-menu will appear. Once completed the Edit button will change to Done and return the user back to the Profile sub-menu.

Menu: Emergency Profile

When the user selects the Emergency Profile the following sub menu will appear. The user may enter in the contact number to the local Emergency Management System. The default will be 911. When the user wants to enter information, as like the screen for Update Profile, the keyboard will appear.

When using the Send User Safe Arrival Text Msg feature the smartphone text message application will be invoked to send the message.

Menu: Emergency Contact ProfileWhen an emergency contact receives a text message notifying them that a person has invoked the

SCARED capability of mPERT, they will click the link contained within the text message and they will be presented with the below screen showing the exact location and movement.

User ScenarioThe following user scenario details how an individual would utilize mPERT smartphone application

while traversing the McKeldin Mall. The story is presented in prose with a timeline of its most critical moments with respect to mPERT.

Overview. Ms. Testudo, a Human Computer Interaction student of the University of Maryland, College Park, is soliciting feedback for a prototype that she has developed from students within the McKeldin library. The best time for obtaining this feedback is in the late evening hours as most classes are completed and a large volume of students are busy studying in the library.

After obtaining the feedback needed she must walk across the entire McKeldin Mall to the Main Administration Building where she will wait for a fellow Terrapin, Mr. Diamondback, to find dinner at a restaurant along US Route 1. There has not been any major criminal offenses reported that has caused personal injury in a few years; however, Ms. Testudo is still nervous of making this journey through this very dark passageway.

10:36 p.m. Ms. Testudo stops in the lobby of the McKeldin Library, finishes putting on her scarf and buttoning up her winter jacket, and observes that the Mall is only modestly lit. She immediately decides to use the mPERT application that she downloaded on her smartphone device. She takes her smartphone out of her pocket, enters her security code, and then selects the Mobile PERT application.

(NOTE: Ms. Testudo performed the procedure noted above as she made the decision to use and ready the application prior to making the journey; however, she does have the option to start the application from her home, locked screen if necessary.)

The application opens, displaying two large buttons on the interface of the smartphone. Prior to her walk across the Mall she notifies her friend, Mr. Byrd that she will be making this journey and asks him to

13

monitor her on his Mobile PERT map. This will receive geo-location information during her entire journey. She then walks out of the library and walks a route that is directly down the axis of the Mall.

10:41 p.m. Ms. Testudo notices two individuals located near outer edge trees who she believed is watching her movements.

Scenario 1. She immediately becomes frightened and believes she needs emergency assistance. Instead of running to a PERT system that is located approximately forty yards away, she immediately presses the very large “HELP” button on her mPERT smartphone application. The mPERT is still immediately available, because Ms. Testudo has configured the smartphone for when the mPERT application is running the screen saver and power saver is disabled. She immediately is connected with the UMDPD, who dispatch a patrol officer to her location. UMDPD’s response time is within 5 minutes of a call on average. Help is on the way.

During the placement of the emergency call a text message is immediately transmitted to Mr. Byrd, along with the most up to date geo-location information to notify him that Ms. Testudo is in need of assistance.

Scenario 2. She immediately becomes scared, but not necessarily to the point where she believes she needs emergency assistance. At this time she presses the “SCARED” button on the Mobile PERT application. This immediately sends a text message, and up to date geo-location information to Mr. Byrd who also has a mPERT application. Mr. Byrd receives the text and selects the link contained within, which immediately takes provides him with the exact location of his friend Ms. Testudo. He can track her whereabouts during the rest of her journey, talking to her until she meets her friend.

While the application is in “SCARED” mode, it presents the same interface—the two large buttons. However, at this time if any button is pressed she is immediately connected with the UMDPD.

10:46 p.m. Ms. Testudo meets up with her friend at the administration building for dinner without encountering any trouble. She passes to her friend that she noticed two individuals behind trees as she was walking, but she felt confident enough to cross the Mall because she used the Mobile PERT application to enhance her security. She passes to Mr. Byrd that she arrived safely to her destination and opens up the MENU selection to send a notification text message to Mr. Byrd of her safe arrival. She closes the mPERT application.

Rationale

To assist in promoting safety within the McKeldin Mall and the University of Maryland, College Park campus the concept of a mobile Public Emergency Response Telephone (PERT) application was developed based upon interviews with the campus community. Currently, an individual in an emergency situation would have to choose one of the two PERTs located in the outer parameter of the mall and then immediately transverse to it to obtain emergency assistance. These two locations are distant enough from a given location on the Mall that individuals are unlikely to utilize the emergency systems in a timely manner, even if running, in an emergency situation.

Research conducted during the previous phase of the McKeldin Mall project recognized the sparse placement of PERTs on the Mall, and interviewees suggested placing PERTs along the sidewalks within McKeldin Mall, rather than just along those on its perimeter. One interviewee even suggested that the PERTs could be made mobile. These interviews inspired the concept for a mobile PERT (mPERT)—a PERT that can be placed into a person’s pocket via a smartphone application, accessible at all times to users owning a smartphone.

Several other technology concepts were developed during the research that included newly enhanced safety lighting systems, and emerging safety clothing apparel. Due to concerns about introducing technology onto the Mall and current technological constraints, or making significant changes to the landscape of the Mall,

14

we chose to develop a our “mobile PERT” concept, which lead to a mobile application for smartphones.We have identified several advantages and disadvantages of the mPERT application for enhancing

perceived safety on McKeldin Mall. These list and describe each of these below.

Advantages

● Increased perception of safety. Our initial research suggests that users of mPERT will feel safer on McKeldin Mall at night than those without it, especially when they are alone.

● Mobility. During the research phase of this project the majority users of the McKeldin Mall, along with the stakeholders utilizes and are familiar with smartphone technologies and applications. This provides the users a common baseline of familiarization with the application technology, which provides the advantage of greater usability.

● Interfaces. There are already established, tested, and implemented emergency management systems that this applications will interface with, so there is no need to establish another EMS system. This greatly reduces development costs.

● Usability. The design of the application utilized the principle of simplicity. Early mockup and features contained various other applications, such as weather and traffic congestion features; however, this was a distraction to the overall concept of the applications. With a feature set designed to call for emergency assistance, this applications has a low education effort to learn how to use this application.

● Cost. As the majority users already have a smartphone device and an interface to download applications, the costs of purchase is FREE. This is a great advantage over other design technologies considered for this project.

● Development. This application is easy to mockup and prototype to solicit immediate feedback by potential users. This feedback will be reviewed for risk assessments and potentially incorporated into updated prototypes. Prototyping software for smartphone applications is currently available at a low cost making the design and user feedback phase easy and efficient.

Disadvantages

● Potential for fostering a false sense of safety. Users of mPERT may feel a false sense of safety.● Interfaces. Although this is listed as an advantage it is also a disadvantage. Obtaining the appropriate

interfacing protocols and interaction with established EMS systems may pose difficulty.● Telecommunication systems. High availability is only as good as the local providers service. If there

is a local area service disruption, the application is rendered useless.● Smartphone User Configuration. If the user has configured their smartphone device in conflict with

the mPERT configuration there is a great chance that the application will not work as designed. The greatest example is the emergency screen lock. Having to implement the user PIN to access the initial interface, then select the mPERT application, and then select for emergency assistant takes valuable time. Another example is the screen saver. If the user configures their device to bypass the configuration of this applications recommendation the application may not be accessible during time of need.

● Smartphone memory. With many physical computing technology devices when memory consumption is a premium the device may not function as designed when there is limited memory on the device. This may have a direct and critical impact on the mPERT device.

Initial Evaluation

15

Evaluation Techniques and ProceduresWe asked current and prospective users of McKeldin Mall to use our high-fidelity mPERT prototype

on an iPhone and discuss how mPERT affects their feeling of safety on the Mall at night. We focused our evaluation on three dimensions.

1. Perception of safety. Does using mPERT heighten the perception of safety?2. Usability. Ease of use, navigation, and layout.3. Technical testing efficiency. Timing of certain procedures to reduce the time it takes to obtain

emergency assistance.These evaluation areas were selected based upon the current phase of the development lifecycle, and

what is currently available. The human centered design is most critical to this application, so technical testing will take place later once a more advanced prototype is developed and will included unit, string, integration and operational testing. Each of the evaluation criteria areas are described below.

Effect on perception of safety. The team asked 16 members of the UMD community to briefly interact with the mPERT prototype, imagine using it on McKeldin Mall at night, and discuss how it might affect their perception of safety. We asked the following questions to guide discussions with participants:

● Would you feel safer if someone knows where you are while in the Mall?● Do you feel safe on the mall with the current security systems in place like the University PERT

system?● Would having this application make you feel safer as you are in the McKeldin Mall?

Usability. In addition to our evaluation of the high-fidelity prototype, we conducted further evaluation of the paper prototype to about 50 individuals outside of the UMD community to gain some understanding of the mPERT within a broader context3. The user held the cards as they would their smartphone and selected each feature and provided comments, feedback, and an overall rating.

Technical testing efficiency. Fifty individuals were asked to perform the login and start procedures to begin running the mPERT application. The users were presented this test in the day and during times where there was no sunlight available. Our goal was to get this procedure under 3 seconds.

Initial ResultsThe following evaluation results were obtained from users in the three evaluation areas.

Perception of Safety

We asked sixteen current or prospective users of McKeldin Mall to use mPERT and consider how it might affect their feelings of safety while using McKeldin Mall. In addition, we asked them to answer the following questions.

● Would you feel safer if someone knows where you are while in the Mall?● Do you feel safe on the mall with the current security systems in place like the University PERT

system?● Would having this application make you feel safer as you are in the McKelin Mall?

3 These individuals were passengers on an international flight from a Middle Eastern country to the United States. This additional testing was done due to the opportunity to collect feedback from a large group of individuals outside of the University of Maryland.

16

Results

The following results are the data collected from asking these questions.

Usability

Fifty users were presented an actual size representation of the mPERT application. The representation was in the form of index cards the size of a current smartphone device. Each card had the screens that they would view if it were a real application, and the user had to perform the following actions:

● Touch each button and view the screen that would appear in the representation of an index card. Provide feedback and ratings for the following areas:

○ Navigation ease○ Screen layout○ Does the application, in concept, deliver the produce of obtaining timely emergency assistance.

● Provide recommendations and criticisms of the applications in its current state.

Results

The following results are based upon a rating system with a scale of 1 to 10, where 10 is the highest score that the application can receive.

17

Figure 12. Analysis

The initial feedback was dismal. The initial reaction to the application was that although it had a simplistic home screen, the MENU was complex with many options that had no relevance to the actual outcome of obtaining security. User Feedback

1. Difficult to navigate due to the volume of configuration options;2. Do not wish to provide the personal identifiable information requested from the initial screens;3. Needs more user tips to guide users through the configuration of the application;4. Need to provide a mechanism to protect unintentional taps to place a call to the EMS dispatcher.

Several changes were made to include to the application and is show below in the Prototype Changes

section and presented back to the users for continual feedback. The changes include:

1. Negate unneeded MENU options2. Negate MENU options that require personal identifiable information such as blood type;3. Must tap twice to place an EMS call to obtain emergency assistance.

Results after Changes

18

Figure 13.

Technical Testing

Users were timed to obtain how long it takes them to login to their phone, and start up an application. This provides an assessment of how long it may take a user to place the emergency call if under distress. The user was timed during three different scenarios:

1. When provided a comfortable and safe environment, such as prior to actually needing to use the application;

2. In darkness and in the cold in an environment that may be perceived as unsafe;3. In light in an environment that may be perceived as unsafe.

Results

19

Figure 14.

Changes Based on Feedback

We improved the visual design, navigation extensively, as seen in Figures 6 and 8, particularly in SCARED mode. Navigation changes with updated user information to be utilized to make a better user experience for both scared users and their network of trusted individuals.

We also removed extraneous options from MENU. The following changes were made based upon initial user feedback and suggestions from the initial sketches and wireframes. Much of the wireframes in the previous section were negated as they had little to do with the core concept of obtaining immediate emergency assistance.

As shown below the user community via their feedback made the interface less complex and utilized less screens and unwanted features. The most significant changes are show below.

20

Figure 15. Original MENU features.

Figure 16. Current MENU features.

Figure 17. Original Emergency Profile UI.

21

Figure 18. Current Emergency Profile.

Future Changes Based on Feedback

There will be several changes during the rest of the development lifecycle, and as the application enters production. These changes include:

● Improved visual design. Cosmetic changes that offer the user better usability, such as colors and UMD icons.

● Improved navigation. Navigation changes with updated user information to be utilized to make a better user experience

● Improved sense of connection to social network. The use of maps● Personalization of maps. A better user experience for those receiving Scared! information● Integration into social networks.● Custom annotations of space. In our interviews with users of McKeldin Mall, we found that they hold

different perceptions of the Mall during the day and during the night. During the day, students feel safe, while at night they feel relatively unsafe. This was also a reported finding of one of the collaborating anthropology students’ groups. More generally, students understanding and perception of the space can be influenced by their experiences within the space. For example, students who practice Quiddich on the Mall identify a certain, relatively large, area of the Mall as the area where they practice the sport.

22