On March 11, 2015, Blueprint launched its first large-scale test of its mobile application for local nonprofit Project Homeless Connect SF (PHC).
The team developed technology that would transform PHC’s data organization and resource management. Here’s what inspired the project — and a look into the process behind it!
I. The Story Behind PHC
In 2004, SF Mayor Gavin Newsom and the Department of Public Health created Project Homeless Connect SF. It was the beginning of a movement to effectively address homelessness in the city — and one that would focus the efforts of various organizations into one.
What is the problem?
The figures alone are appalling:
- An estimated 7,000 homeless live on the streets of San Francisco every night. This number doesn’t include the thousands of other residents who sleep in their cars or on borrowed couch space.
- Another 110,000 San Franciscans currently live below the poverty line ($11,700) and risk becoming homeless, due to rising housing prices and living costs.
Furthermore, support can be difficult to find. Gaining access to basic resources, such as housing and job assistance, mental health services and addiction recovery, means first passing waitlists and numerous forms.
What is PHC’s approach?
Five times a year, the nonprofit hosts “service days.”
These are massive events, which gather dozens of service-providing nonprofits and over 2000 clients together in 1 location. Individuals are provided the various services they need, ranging from eye care to free books and foot washing. Information about the clients also adds to a central database accessible by smaller nonprofits in the area.
Some victories:
- Over the past 10 years, 49,729 volunteers have provided services to 75,625 clients!
- The SF model has been replicated in over 260 cities across the United States, as well as Canada and Australia.
- Two years ago, Project Homeless Connect also launched a sister nonprofit, Everyday Connect, to connect people with resources on a daily basis (in between service events)
II. Blueprint’s Role
Our partnership with Project Homeless Connect
1. The Issue: Data Organization
PHC used paper forms for every transaction at its service events, which gave way to a number of problems.
During such events, thousands of sheets of paper holding names, social security numbers, and other sensitive information would be thrown into cardboard boxes and folders. For days following, data-entry volunteers would work on inputting this information into spreadsheets or online file. But inevitably, some data would get lost in the process.
Unfortunately, the information that was available had redundant accounts or inaccuracies tied to it, making the database difficult to manage or use.
2. The Solution: Going Paperless
Blueprint began to create an Android application to replace PHC’s inefficient and insecure paper filing systems.
The app would:
- digitize all event transactions, so the organization could save resources, improve data integrity, and make processes more streamlined and secure.
- record new kinds of information, so that event services could be measured and improved.
The team also began cleaning and reconfiguring parts of the database to provide better, more usable data to PHC.
To see the project code: https://github.com/calblueprint/PHC
III. A Breakdown of the Process
Ideas driving the team’s mobile application design
The Basic Framework
Choosing Android: Since Google donated 200 nexus tablets and phones to Project Homeless Connect last year, the team decided to create an Android application.
Trying Salesforce and Heroku: PHC had been using Salesforce to store their data since inception, but the Blueprint team discovered that the Salesforce API had a device limitation of 5 devices/account. Since PHC owned only 20 Salesforce accounts, it was effectively limited to 100 devices. The API also lacked a few important features, such as fuzzy searching.
Blueprint then tried using Heroku’s newly-built HerokuConnect service, which provides bidirectional syncing between Salesforce and Heroku. However, the nonprofit could not afford its $10,000 annual charge.
Switching to Rails: The team ultimately set up its own Rails server on Heroku to act as a middleman between the Android devices and the Salesforce database using a custom-made API.
Design Considerations
Individuals and issues influencing the application’s design
1. Users
The main users of the application would be volunteers (some of whom could have never used a tablet).
To accommodate to a broad range of technical backgrounds, the app incorporated:
- Large buttons and large texts
- Intuitive app flow
- In-app tutorial
- Comprehensive error messages
The team also underwent multiple rounds of user testing throughout the year.
2. Clients
Many clients do not provide reliable or consistent personal information (i.e. spell their name differently or forget their social security number). Because of this, the team could not rely on exact string searching to find clients in the database or prevent duplicate accounts.
To accommodate to these inaccuracies, the app used:
1. Fuzzy string matching of their names using the Ruby gem textacular
2. And showed results of many possible users, offering birthdates to distinguish between possible candidates
3. Data Integrity
Because critical client information would be lost if data was entered incorrectly, the team prioritized the prevention of such mistakes in the first place, making sure the app included:
1. App flow that prevents unintended actions
2. Validation and confirmation screens for all tasks
3. Feedback toasts for all tasks
4. Security
Another main concern was security. The app needed to safeguard the clients’ sensitive information and prevent identity theft.
To accommodate for potential security risks, the team
1. Set up lock screens on all the tablets
2. Required all requests to contain the correct authorization token. Should a tablet be stolen, the authorization token could be immediately changed
3. Hid social security numbers within the app
5. Internet
Since the app would be used mostly on service days, which take place inside the Bill Graham Civic Auditorium (a massive building with multiple sections and thick walls), internet speed was a concern.
To accommodate to slow internet speeds, the team set up unique settings.
· In the case of no internet:
The app would display an alert prompting users to connect to the internet.
· In the case of slow internet:
The app would display pop-ups with spinners in all parts of the app waiting for responses, so that users knew that their requests were sent.
This would also stop them from repeatedly resending the request or navigating to other parts of the app. Furthermore, all requests would stop after a designated time (i.e. 7 seconds) and ask the user to press “retry.”
The app would also prevent users from pressing the buttons until necessary information had been retrieved and loaded.
6. Time
Since Blueprint has only 1 year for each project with a nonprofit partner, the code we write must be robust enough to pass on and handle future events with minimal changes. This commitment to creating intuitive, well-documented, and flexible code laid a strong backbone for Blueprint’s work with PHC.
Thank you to Project Homeless Connect, and Kate, for your amazing work in the community. And thanks for reading!
Keep an eye out for Part 2, which will dive into the Blueprint POV (and share some of our project developers’ main takeaways!)
