SoftwareDevelopmentFolder
NiteLite: Safety Information Along Walking Routes Application
- Project Status Sheets
- 1 Preliminary Project Proposal Document
- 2 Proposal Document and Presentation Slides
- 4 Software Development Plan
- 5 Requirements Specification
- 6 Architectural Design Document
- 7 Detailed Design Specification
View our bi-weekly status updates here.
NiteLite will be a mobile application built using React Native to be compatible with multiple mobile OS’. NiteLite aims to provide vulnerable users with the safest route from point A to point B. This is similar to existing mapping applications, but this app will focus on routing users to the “safest routes.” Safe routes are defined by a number of factors such as foot traffic, crime rate, light, open establishments, and more. The use of existing mapping APIs and crime rate data will be implemented to find the safest routes. The end users will be anyone who travels by foot in an unknown or unsafe location. More specifically, this app will be designed for vulnerable groups such as women and children.
This project is a good fit for our team since members have prior knowledge in API integration, backend development, and React Native. All the members do not know React and not all of us have in-depth knowledge of the backend of large scale applications, so we will be able to learn from one another throughout this process. We have many ideas for additional features, so we will aim for a Minimum Viable Product and if time permits, we will implement additional features. Currently, ideas for other features include the ability to call the police or an emergency contact if the user feels unsafe, allow the user to report safe or unsafe paths (similar to Waze, where users can alert other users of suspicious activity in real time), and other resources to help users feel safe on their way to their destination. There are many APIs where we will be able to access global maps with street view and we are currently researching APIs that will indicate lighting or foot traffic during times where people feel most unsafe - at night. The ability to find a nearby gas station or police station should be fairly simple through integrating the Google Maps API. We find this project to be essential since we are all college-age women and have all experienced the dangers of walking home in either an unfamiliar neighborhood or at night. This app is especially useful to users who may be new to certain cities and do not have the prior knowledge of safe walking routes. After a brief period of market research, we discovered that this concept has been explored in projects prior, but there is no existing solution for the public to download. In addition, Google has also mentioned that they are looking into providing safer routes with Google Maps, thus proving the demand for this product.
View the proposal document here.
View the presentation slides here.
The NiteLite mobile application is a React Native based phone app, consisting of a map interaction and routing instructions which will provide users with information to make them feel safer while traveling their chosen routes. To do so, we will need to build a mobile application using React Native, store user data in Firebase, integrate the Google Maps API to provide a map interface and walking directions, and gather crime and walkability information to calculate the safest route for users. In addition, we will need to design a safety preference form for users creating NiteLite accounts to specify what they look for on a safe route. We will also allow users to store emergency contact information directly in the app.
| Task | Completion Date |
|---|---|
| Front-end design and React setup | Week 6 |
| App Skeleton | Week 7 |
| Integrate Google Maps API | Week 8 |
| Gather safety information from Crime-o-Meter and Walk Score APIs | Week 8 |
| Modify routes with safety information | Week 9 |
| Enable Firebase | Week 10 |
| Create safety preference form | Week 11 |
| Store user preferences in Firebase | Week 12 |
| Enable calling from app | Week 13 |
| Share route via Message | Week 14 |
| Testing | Week 14 |
| Deliverable to Customer | Date |
|---|---|
| Map Interface | Week 8 |
| Map Interface with Aggregated Data | Week 8 |
| User Sign-on with Preferences | Week 12 |
| Store Call Emergency Contacts | Week 13 |
| Share Route via Message | Week 14 |
- Development: MacBook 2.5 GHz Intel Core i5, Intel Iris Graphics 6100 1536 MB. Windows devices with Windows version: 10.0.16299.0
- Execution: smartphone running Android or iOS
- VSCode Live Share, GitHub, Zenhub, React Native, Postman, Figma, Adobe XD, Redux, Google Drive, Mocha/Jest, GitHub Wiki Pages
Talia: Front End Development and Design and Databases. Talia will be in charge of doing all of the designs for the mobile application interface. She has the most experience in the group doing design as well as front-end development. She will also help out with full-stack development and integration with the front end with the back end.
Lauren: Scrum Master and Backend Development: Lauren will take in Shanaya’s expertise with feature timelines and what features we need to build, and allocate the tasks using ZenHub to the four group members based on each member's expertise area. As Scrum Master, Lauren will also facilitate the weekly check-ins for the development process. Lauren has experience working in backend development.
Shanaya: Product Manager and Full Stack Development. Shanaya has leadership experience and intricately understands user journeys, pain points, and experience and will ensure that the code created will satisfy our ideal user groups. Shanaya will add a high-level user needs lens to the feature implementation. Shanaya also has experience with full-stack development.
Maya: Back End Development and Databases. She will be in charge of enabling Firebase and storing user data in a secure manner. She will also aid in incorporating the Google Maps API and modifying routes based on safety information. Maya has experience in developing with React and can offer expertise with building the mobile application.
| Task | Resources |
|---|---|
| Map Interface | React app skeleton, request and track user current location, integration of Google Maps API, provide route from origin to destination |
| Map Interface with Aggregated Data | Integrate Crime-o-Meter and Walk Score APIs, given a destination modify route based on gathered data, provide warnings for unsafe spots on route, indicate safe spots, provide final route |
| User Sign-on with Preferences | Incorporate sign-in feature with email address, create safety preference questionnaire, enable Firebase, store user profiles in Firebase, test that routes are created according to individual preferences |
| Store Call Emergency Contacts | Create emergency contact field in profile, enable calling from app, add emergency call button on map navigation page |
| Share Route via Message | Create message template for sharing routes, create link for google maps route, integrate with iMessage/SMS |
The NiteLite mobile application is a React Native based phone app, consisting of a map interaction and routing instructions which will be displayed. NiteLite aims to provide users with information to make them feel safer while traveling their chosen routes. The use of React Native provides cross-platform functionality. The application consists of a firebase backend, utilizing Redux to manage application state and external APIs to track current location and route users to their final destination. Users will enter their desired destination through the home page, and upon pressing enter will be provided with at least one route with additional safety predictions about it. Route data consists of information like street level of lighting, open businesses along the route, any crime reportings that occurred recently near or on the route, all based on a user's indicated safety preferences. In addition, there is the option to update your safety preferences to include specific locations users want to include such as a friend or family member's address, and users will be prompted to update their safety preferences when traveling to new locations.
This document is organized as follows. Section 1 contains the Preliminary Project Proposal Document, which details our overall intent for the project. Section 2 contains the Proposal Document and Presentation Slides, which is another, slightly more detailed version of a project proposal. Section 4 contains the Software Development Plan, which details deliverables and team roles. Section 5 contains the Requirements Specification, which lists the requirements of the product being built, divided up by sub-system. Section 6 contains the Architectural Design Document, which discusses interface design, and relevant hardware and software. Section 7 contains the Detailed Design Specification, which covers CSCs and CSUs. Section 10 details Testing as it relates to our application. Section 11 is a reflective section on Lessons Learned. Section 12 describes the Document History throughout the development lifecycle of NiteLite. Section 13 includes the Reviewer and Auditor comments as necessary. Finally, Section 14 includes any relevant notes to the rest of the document. The following table defines the language used in specifying requirements in this document. There are three levels of specification, only one of which constitutes and indicates an actual contractual, verifiable requirement.
Document Definitions
| Type | Definition |
|---|---|
| Shall | Expresses a mandatory provision. Any deviations from these contractually imposed mandatory requirements require the approval of the NiteLite team (Maya Pegler-Gordon, Talia Bahar, Lauren Lindsey, Shanaya Nagendran) |
| Should | Expresses non-mandatory provision. Unless required by other contract provisions, noncompliance with this requirement does not require NiteLite team approval and does not require documented technical substantiation. |
| Will | Declaration of purpose such as a design goal. Unless required by other contract provisions, noncompliance with this requirement does not require NiteLite team approval and does not require documented technical substantiation. |
- 5.2.1.1 Launch Screen
- 5.2.1.2 Log In Form
- 5.2.1.3 Sign Up Form - gathers email, name, and safety preferences
- 5.2.1.4 Home Page - interactive map interface with the ability to start navigation
- 5.2.1.5 Home Page Map
- 5.2.1.6 Home Page Menu(s)
- 5.2.1.7 Home Page Search Bar
- 5.2.1.8 Account Preference Page - shows all account details and provides the option to modify
- 5.2.1.9 Routing Page - starts navigation and capability to view step-by-step directions, end navigation, and call an emergency contact
- 5.2.1.10 Routing Page Route Input Form - users can enter point A and B from which they want directions from/to
- 5.2.1.11 Routing Page Safety Metrics - displays how many safe points, open businesses, etc. lie on the suggested route
- 5.2.1.12 Routing Page Map - displays icons of crowded areas, well-lit streets, and open establishments on or near a users route
- 5.2.1.13 Navigation Page - starts navigation and capability to view step-by-step directions, end navigation, and call an emergency contact
- 5.2.1.14 Navigation Page Map - displays icons of crowded areas, well-lit streets, and open establishments on or near a users route
- 5.2.2.1 User Module - stores basic information about a user
- 5.2.2.2 Emergency Contacts - stores a users emergency contact information
- 5.2.2.3 Account Preference - stores a user's viewing preferences
- 5.2.2.4 My Addresses - A place where users can store addresses that they feel safe at this can be a friend's house or any other location. This data can be shown as an icon along with the route map if they are walking near or by any of their addresses.
- 5.2.3.1 Google Maps API - General map information. Customizable to the theme of our application
- 5.2.3.2 Current Location Module - Updates constantly with a users current location and sends information to the front end for display
- 5.2.3.3 Walk Score and Crime o meter API - These APIs will be called when a user inputs their destination route to display how safe an area is and how much crime there is
- 5.2.3.4 Emergency Call Module - This module will pull the number from the database and integrate with the user's Phone app to call a number of their choice if they feel unsafe
- 5.2.3.5 Places Module - This module takes information from the Google Places API and stores them so that they can “pop up” along a users route in case they have a specific location they want to stop at
- 5.2.3.6 Emergency Call Module - This module will pull the number from the database and integrate with the user's Phone app to call a number of their choice if they feel unsafe
- 5.3.1.1 The User Interface shall be displayed on mobile applications running on iOS or Android.
- 5.3.1.2 The User Interface shall ask a user for their desired phone number to contact in case of emergency.
- 5.3.1.3 The User Interface shall present the user with a quiz upon registering to indicate whether or not they want to see data on police stations, open businesses, and crime rates, and addresses of safe locations along their route.
- 5.3.1.4 The User Interface shall display a map from the Google Maps API to indicate a route from a user's current location to their destination.
- 5.3.1.5 The User Interface shall provide information along the route about safety variables that allow the user to have more knowledge about their route.
- 5.3.1.6 The User Interface shall give direction information at the top of the screen, indicating where a user needs to turn next to get to their destination.
- 5.3.1.7 The User Interface shall display an overview screen after the user inputs a destination, where they can see a map of their walking path, large gatherings of people, and the level of crime along the path.
- 5.3.1.8 The User Interface shall be coded in JavaScript, using React Native.
- 5.3.1.9 The User Interface shall indicate user-defined safe spots on the map as markers to supply users with quick redirection.
- 5.3.2.1 The Database subsystem shall be stored in Google Firebase.
- 5.3.2.2 The Database subsystem shall use JavaScript.
- 5.3.2.3 The Database subsystem shall store the data indicated from the user sign up quiz in the fire store.
- 5.3.2.4 The Database subsystem shall utilize Redux to store the current state of the application and application UI.
- 5.3.2.5 The Database subsystem shall store user-specified safe spots upon account creation (gathered through account setup form).
- 5.3.2.6 The Database subsystem shall store the unsafe locations detected through API responses.
- 5.3.2.7 The Database subsystem shall store user's current location when using the app.
- 5.3.3.1 The Server subsystem shall call on the Google Map API.
- 5.3.3.2 The Server subsystem shall call on the Crime-o-meter API.
- 5.3.3.3 The Server subsystem shall call on the Walk Score API.
- 5.3.3.4 The Server subsystem shall use Google Maps API to render a mapping of a user's surroundings, including nearby streets and walking paths.
- 5.3.3.5 The Server subsystem shall use the Google Maps API to gather information about “places” (restaurants, gas stations, bars) that lie along a user's route.
- 5.3.3.6 The Server subsystem shall use the Google Maps API to allow a user to pick their preference of map view from Default, Satellite, or Terrain.
- 5.3.3.7 The Server subsystem shall use the Google Maps Distance Matrix API to get data of the possible routes from a user's current location to their destination.
- 5.3.3.8 The Server subsystem shall use the Crime-o-meter API when a user is initially inputting their destination and is used to dictate whether there is a low/medium/high crime rate along the route.
- 5.3.3.9 The Server subsystem shall use the Walk Score API to take in a user's current address, or location in longitude and latitude, to output a Walk Score and description of the area.
- 5.3.3.10 The Server subsystem shall use the information from both the Crime-o-meter API and the Walk Score API. It will be combined and prioritized such that it can be presented to the user in a succinct and clear manner.
Maximum open application load time should be no more than 10 seconds
When a user calls their emergency number, it should take no longer than 5 seconds to begin the dialing process
The safest route should be displayed in under 1 minute after a user enters their query
A users location on the application should be updated every 3 seconds
The application should provide redirection directions if a user turns down a wrong road within 100 feet of making the mistake
Pulling user data from Firebase should take no longer than 2 seconds
The general safety rating of a path should be displayed no more than 1 second after the initial route loads
The “icons” of safe locations, well-lit areas, and highly populated areas should be displayed when a user is within 0.25 miles of the longitude and latitude
When a user comes within radius to a safe location, the icon should display within 5 seconds
The load time of the preferences page should take no more than 5 seconds
- Processor: 2.5 GHz Intel Core i5
- Hard Drive Space: 10MB
- RAM: 8GB
- Display: 800x800
- Operating System: MacOS or Windows
- Compiler: JavaScript and other programming languages
- Graphics: Sketch, Invision, Redux
- Application: React, Expo
This document provides the architectural set up for the software in the NiteLite app. The app provides information about safe walking routes for vulnerable groups through an interactive map. Users will have the capability to provide preferences for the routes generated and customize their routes by navigating to safe places nearby.
The application consists of a Firebase backend, utilizing Redux to manage application state and external APIs to track current location and route users to their final destination. Firebase will also store a user's safety preferences including addresses and types of locations that make them feel safe. These preferences will be used when returning route data which consists of information like a street's lighting level, open businesses along the route, and any crime reports that occurred recently near or on the route.
6.1.2.1 Smartphone with Android or iOS operating system
6.1.2.2 Resistive touch screen
6.1.2.3 Wireless Networking with access to cellular data or wireless internet
6.1.2.4 Location-dependent software with capacity to be live updated
6.1.2.5 React Native mobile user interface with modular components
6.1.2.6 Expo app installed on mobile device to run application
Use Case 1: User wants to update their safety preferences.
- So they navigate to the User preferences page and make the needed additions and removals which would then be reflected in Firebase.
Use Case 2: User feels unsafe along their route and no safe spots are nearby or open businesses are nearby.
- So they call their emergency contact quickly through the app.
Use Case 3: User wants to find the most-lit and populated path from point A to B.
- They input their desired travel locations or select one of their saved routes triggering the Google Maps API to take in the location information along with the user's preferences to generate a "safe" route.
| Log In Screen | Sign Up Screen | Home/Map Screen | Generated Route Screen | Route Guidance Screen | User Settings Screen | Firebase |
|---|---|---|---|---|---|---|
| Verifies if user exists in firebase upon form completion. | Creates a new user in firebase and sets up safety preferences for future Google Maps API usage upon form completion. | Users can use the search bar to look up their walking destination or choose from one of their saved routes within the swipe-up menu. | Presents user with their requested route. Displays crime, lighting levels, and open businesses along suggested route. Route guidance begins once user presses button to confirm route. | Uses user's geolocation to track route progress. Displays user-defined"Safe Spots" on map as well as open businesses in case users need to divert from route to a safer location. Displays emergency button that would dial a user's emergency contact when pressed. Users can also end their route manually from this screen, else upon reaching their destination the route will auto terminate taking users back to the home screen. | User can update their safety preferences here which would trigger firebase to also update. | Stores users log-in information for verification and safety preferences for Google Maps API use. |
Once new users complete the sign-up form and set up their safety preferences their data will be stored in our firebase database. This data will be utilized to customize a user's generated route when users request a route after inputting their current location and walking destination.
Returning users will use the log-in form which will pull up the user's profile in firebase granting them access to the app.
Users can edit their safety preferences in the User Settings page which would trigger the information in firebase to update as well.
When users search for a route their current location, walking destination, and safety preferences will be sent to the Google Maps API which will generate a route for the users to take. Route guidance will commence once the user confirms the route. The user's geolocation will track their route progress and upon reaching their destination the guidance will terminate.
To install the software, clone the React app Github repository on your computer. Install the Expo app on your mobile device.
To start the software, navigate to the folder where the Github repository has been cloned. Run npm start or expo start. Expo will open up a tab in an internet browser window with a QR Code. Scan the QR code with your mobile device. The Expo app will open with the most recent version of the application.
To stop the software, simply close the app. This navigation application will not run in the background on your mobile device like Google or Apple Maps do.
If you are a new user, you will select a username for your profile, and your profile is connected to an email and secured by a password. When you sign up for the first time, you will receive an email confirmation of your profile. After, you will be given the chance to indicate your safety preferences.
If you are a returning user, you will log in with your username and password.
Setting your preferences allows the application to tailor your safest route based off of your preferences. The "What makes you feel safe when walking?" question will allow the app to prioritize routes with the most of what you have selected from "Open Businesses, Police Stations, Busy Sidewalks". We understand different users have different definitions of safety, and we hope to solve this problem by setting user preferences. The next question allows you to enter the addresses of places you define as safe zones. This can be a friend's house, your college campus, or a gas station or late night diner that you are familiar with. When you select these addresses and you are walking on a route near those destinations, they will be highlighted on the map. The final question allows you to set up emergency contacts that can be called if you indicate you feel you are in danger while on your way to your destination. This can be 911, or a trusted friend or family member.
To map to a destination, click on the search bar and begin typing in a destination. This can be the name of a place or an address. You can see the route and click "Start" to start receiving directions.
When you first input a destination, you will see a low/medium/high score of how safe a route is. This is an aggregate score based on crime rates in that area. While on the way to your destination, there will be many icons that pop up along the route for additional information. An icon of a police officer indicates a police station. An icon of a business building indicates an open business. An icon of many people indicates there is a busy street. If you see a light bulb, it means that that area is well lit with streetlights. The directions at the top of the screen will show you where to go, which are synced with the map, which is constantly updated with your current location.
To update your preferences, click on the menu bar and "User Settings". Here you can update the settings you have set prior, they will be automatically saved.
To change your destination, click the "X" button on the lower corner of the screen while the directions are active. You will receive a confirmation to end current routing and you will then be able to input a new destination to route to.
To "uninstall the software" you can remove the Github folder from your computer, or delete the Expo app.
Select the "Help" button at the bottom of the login page. You will be prompted to enter your email used to create the account. You will receive an email to that account with your username and a link to reset your password.
Click on the menu bar and select "user preferences". These are automatically saved and can be updated at any time.
If you are in the process of going to your destination and you feel unsafe for any reason to the point where you would like to call your emergency contact, click on the phone icon in the lower area of the screen. This will present you with a confirmation of making a phone call and your phone will make a call to your emergency contact.
If you're still having trouble with using our app, feel free to contact a member of our development team: Talia Bahar, Lauren Lindsey, Shanaya Nagendran, and Maya Pegler-Gordon
NiteLite will use Firebase to store user account information and safety preferences. When a user creates a NiteLite account, their information will be passed to Firebase where it will be able to be changed by the user at any time. The database used for the safety aspects of the application includes crime, streetlight location, and construction zone data. Given a user's origin and destination locations, the database will be queried in order to provide information for NiteLite users about the safety of their route. This information will then be displayed on the map navigation page when a user selects a route.
Firebase will be accessed using Redux, the popular state-management library, incorporated into our React Native application. Using authentication, when a user creates a NiteLite account, their information and safety preferences will be stored in Firebase and if a user modifies their information, this database will be updated in real-time. The information contained in our Firebase store will connect to the client-side Redux central store accessible by the necessary UI components.
The redux action, reducer, store pattern will be leveraged to maintain and update the redux client-side data store, consequently updating our Firebase store. As a high-level overview, our React Native UI component can reach out and subscribe to the data store receiving the relevant data needed as props. If the users want to update the data stored for their account, the component will dispatch an action (such as ADD_EMERGENCY_CONTACT or EDIT_SAFE_SPOT). These actions are passed to what is called a redux reducer, the gatekeeper to the central data store, which updates the store as needed. The pattern is outlined in the following diagram, sourced from the Complete React Tutorial (and Redux) on youtube available at https://www.youtube.com/watch?v=OxIDLw0M-m0&list=PL4cUxeGkcC9ij8CfkAY2RAGb-tmkNwQHG&index=1:
The safety database will be accessed by using MongoDB in conjunction with Redux to be used by our React app. When a user's origin and destination are selected, our server will query the database for crime, streetlight, and construction zone data along the calculated route. MongoDB's Realm database system will work with our Redux data store to provide this information.
Firebase has many security measures already incorporated to protect sensitive user information and block individuals from being able to access another user's data. By using this established database service, we will not have to take any further measures to protect this information.
The safety database will be protected from tampering and will not be modifiable by any users. The information provided is already publicly accessible, so there are no concerns about displaying crime, streetlights, or construction data to NiteLite users.
This document provides detailed descriptions of each software component developed for the NiteLite mobile application. For each of our CSCs (React Front-End, Database, Server), details of their design and module structure will be described.
The following sections contain the descriptions of the details of the design of the NiteLite CSCI. The design is systematically described in terms of the CSCs for the project and the CSUs for each CSC.
The React front-end will consist of an account setup flow, a map view home page that allows users to get directions, a navigation module that visually displays step-by-step directions, and an account-preferences page to modify preferences. The information gathered during the account setup process will be modifiable by users on the account-preferences page at any point after their initial account setup.
When a user inputs an origin and destination, this information will be used to display the safest walking directions in the navigation module.
This module will be displayed when a user first uses the application. It will prompt the user for information such as phone number, safety preferences, emergency contacts, and safe spot addresses. Emergency contacts and safe spots will then be saved as they are entered.
This 'Map' module will display an interactive map interface centered at the user's current location using the Google Maps API. An overlayed 'MapModal' component will prompt the user for origin and destination locations using the 'ModalSearchBar' component. When the directions are returned from the Google Maps Directions API, a birds-eye-view route will be overlayed on top of the map.
The 'MapDirections' component will provide a list of step-by-step directions to route the user from their inputted origin to their destination. By utilizing the react-native-maps package and MapBox, a visual route will be produced. The map will also contain markers for a user's inputted safe spots, open businesses along their route, and the walk score of streets around them.
The account preferences module is populated with the phone number associated with the user's NiteLite account, emergency contacts, safe spot addresses, and safety preferences gathered during account setup. Each of these fields are modifiable by the user on the account-preferences page and changes made will be reflected in the Firebase server.
The directions module will make a call to the Google Maps Directions API given a user inputted origin and destination. The list of routes returned along with walk score data about the route will be used to return the safest walking route. A list of step-by-step directions will then be returned by this module to be displayed to the user.
This module will query the Walk Score API given latitude and longitude coordinates. A score from 0-100 will be returned to indicate the walkability and safety of the specified location.
This module will enable the NiteLite application to place calls to user-specified emergency contacts or emergency services. It will utilize the user's mobile phone calling capabilities to make calls directly from our map interface.