This application is located here: des-alertsystem.appspot.com
Note: Due to a lack of funding to sponsor Twilio requests, this application has been suspended.
The UW Alert system is not very good. Like most university alert systems, it depends on a group of people to decide whether an event is important enough to alert students about. Also, the outgoing system they use isn’t very reliable (see The Crossroads incident)
I want to provide a better way to handle the UW Alert system. This would be an opt-in service (not related to the university, unless they want to take it off my hands) that would notify users through SMS or some sort of UI when there is immediate danger in the university district. This tool will support anyone interested in danger in the U District which includes but is not limited to the following groups:
- Faculty, Staff, and Students at the University of Washington
- Those who live in the U District
- The developers of the current UW Alert System (my program could be a better implementation as it reduces/removes the need for a committee)
Users will interact with the application via SMS and a web interface. I have chosen these two methods of access as SMS is (almost) universally accessible while a GUI on the web will be much easier to use to setup accounts/desired “emergency level”.
Data Sources, Libraries, and Planned Processing
Aggregates data from users and “official sources” to provide up to date information
- Earthquakes (USGS) and AccuWeather (Official Source)
- Seattle Emergency Response and Alert Data (Official Source)
- Twitter – Collects data from users to keep the event up to date
- Club Texting (SMS) – sends out and collects data from users
Possible Additions (if time permits)
The “official sources” Earthquakes, AccuWeather, and Seattle ERAD will provide the backbone of information for this application. I will process this data and categorize it based on the national “clery” definitions here: www.pdx.edu/cpso/clery-definitions and the FBI’s categorizations here: www2.fbi.gov/ucr/handbook/ucrhandbook04.pdf (See Ch.1 – Hierarchy rule).
Depending on which category a user signs up for, they will be alerted when an event occurs within that category. The goal of this is to be as transparent as possible with how the data is handled and sent out. I want this application to notify people when things relevant to them occur to prevent potentially dangerous situations. I do not want it to bother them with crimes/reports that they don’t care about.
Twitter and responses to the SMSs can let users add to the crime data. I will process hashtags and monitor certain twitter feeds (like that of the Seattle Police Department) to keep users up to date as events are unfolding. This allows for input from users alongside the data from law enforcement (e.g., if someone witnesses happening during a crime and texts it in or puts it on twitter, this app should update the data about the event automatically. If that new data falls under a certain category level, it gets sent out just like an official source).
If time permits, I hope to add routing functionality. I plan to use social media check-in data to categorize which locations nearby to the crime is safe for people to go (be it a home or public location). I could use some sort of turn-by-turn direction service (like google maps) to give users instructions on how to get to that safe location. Also, a dedicated smartphone application that sends messages via push (or toast) notifications could be a better implantation as many users find texts annoying and (sometimes) unintelligible.
Tentative Development Plan
1. Write a Python application for Google App Engine that will retrieve data from the “official sources”.
2. Process the feeds and categorize them according to “emergency level” (or whatever name works)
3. Figure out how to send out certain data (based on a predetermined “emergency level”) through SMS
4. Create a way to sign up through SMS (or web interface, whichever is easier)
5. Make sure signup works correctly
6. Update data retrieval to include Twitter and SMS feedback (could be hard, might have to do this part earlier or make it a stretch goal)
If Time Permits
7. Find safe locations using social media check-ins
8. Direct users to a safe location using Google Maps
9. Create a better UI for Web and/or build a smartphone app