Bernal Heights App

Bernal Heights App

Spring 2016
CS169 Software Engineering

Check out the project Github repo Pivotal Tracker

bhnc app homepage

Overview

I worked on a team of five computer science/EECS students during the Spring 2016 semester to create a web application promoting community engagement and safety in Bernal Heights, San Francisco. Our client was the Bernal Heights Neighborhood Center (BHNC), a small non-profit that provides social programs for seniors and youth, and fosters neighborhood activism to solve local problems. We made this as part of CS169, Software Engineering as a Service.

Based on client conversations, we developed three main functionalities for this app:

  • Gather, manage and share hotspot form information
  • Provide a centralized calendar for BHNC and resident-created events
  • Share useful resources with residents in one accessible location

Involvement

Everyone on the team contributed to both design and implementation, which was a really great experience after group projects with mostly distributed roles. As one of the two team members with some prior Rails experience, I was heavily involved in implementation and learning how to manage testing and deployment.

  • Full-stack, agile, TDD and BDD development on Ruby on Rails, following MVC and RESTful practices
  • Design and implementation of the admin-side workflow for staff accounts, hotspots and events
  • Managed Git repo, continuous integration and deployment
  • Low-fi mockups, including the hotspot form experience on mobile devices
  • In-person interviews and persona generation

Tools

Design: Pencil and paper, whiteboard, POP, Adobe Illustrator, browser prototyping

Development: Ruby on Rails, Haml, Sass, Javascript, Pivotal Tracker, Travis CI, CodeClimate, Cucumber, Rspec, Heroku

Process

Team Workflow

This project was very much about learning by doing — not only Rails and its various gems, but also the agile workflow. We had daily standups in Slack, wrote, pointed and assigned user stories and features in Pivotal Tracker, and practiced test-driven development with continuous integration and deployment.

  • Week one: Client meeting, create user stories/mockups for the features this iteration, write Cucumber/Rspec tests, meet with instructors for mini-review
  • Week two: Work on our stories until all tests pass green, deploy for user testing

I was in charge of managing our repo, as well as continuous integration and deployment. We also had a PM who looked after Pivotal Tracker and made sure our standups got done, and a point person for contacting our client and submitting progress reports to our instructors.

Customer Needs

We worked with Ailed and Esme, BHNC chairs of community engagement and public safety, for the majority of the project.

One of the most successful programs Ailed and Esme manage at BHNC is the hotspot walk. Residents submit hotspot forms about problems in the neighborhood that affect public safety, and BHNC staff aggregate the information. Then, they invite the police and relevant city departments to walk with BHNC staff and neighbors around the neighborhood to see the problems in person. This is often a more effective way of getting problems fixed than relying on individual requests from residents.

sample hotspot form

Example of submitted hotspot form, contact information redacted

Up until now, staff had to process over 200 of these forms per walk. One dedicated neighbor was inputting all the information by hand into Google Maps in order to get a visualization of problem spots.

Ailed also wanted to get residents more involved in resolving their own problems. Besides hotspot walks, there were also community meetings, park cleanups, and other events that Ailed wanted to easily share with residents. She had tried using Nextdoor but found it too broad for her needs.

Design Process

admin flow

We started out with a broad brainstorming session for how the app would be put together. Each iteration, if needed, we would sketch out how the new features would fit into the current plan and run those by Ailed and Esme. Within our team, we often tried to do group design on the whiteboard, and shared our sketches over Slack when meeting up wasn’t possible.

For most of our big questions, we made low-fi prototypes in POP and travelled in person to SF to have Ailed, Esme and Bernal residents do some user testing. I was in charge of making a wizard version of the hotspot form to compare against the single-page version.

Design Decisions

We made a few significant changes to our designs based on the feedback we got from user testing.

Location Search

Testers assumed that the first step to submitting a hotspot form was specifying a location. Many attempted to “drop a pin” on to the map. We initially had location come after specifying the type of issue being reported. Seeing testers’ reactions, however, we went back to the drawing board. Although dropping a pin was a natural reaction for users, we felt that in reality being able to do that accurately, especially if on a mobile browser, would be difficult. Instead, we added a search bar to the map; searching for a location would drop a pin and pop up a link to fill out the rest of the hotspot form.

hotspot location

Hotspot with location search

Sign-in

Initially, we planned to use sign-in and 3rd party authentication to eliminate the need for filling in name and contact information on every submitted form. This seemed like a time-saving feature that would encourage more people to submit. After user testing, however, we eliminated sign-in for residents. Testers said requiring a user name and password made the application feel unwelcoming; the sign-in page was more of a barrier to them than filling out their information.

Hotspot Form Wizard

We ended up implementing a wizard to walk through the required information for hotspot forms, since most testers reported feeling more overwhelmed by the single-page prototype, and visibily enjoyed using the wizard version more.

Admin Workflow

admin homepage

Final admin homepage

Since I ended up taking on many of the admin-side user stories, I thought a lot about Ailed’s personality and the contexts in which she’d be using this app. Working in a small non-profit already meant being strapped for time and resources; in addition, Ailed was a new mother. I decided to create a homepage that would prompt Ailed if anything needed her attention — for example, if any new events had been submitted and needed approval — and would provide immediate access to her most common tasks.

Some other small details worked in by the last iteration: if signed in, the admin doesn’t need to fill out name, contact info or organization name on any of the forms. The events calendar has a reminder about the number of unapproved events. Clicking on a pin in the admin hotspot map will show a link to the entire form submission; earlier iterations, the only way to view that information was going through the list of hotspots below the map.

bhnc calendar

Admin hotspots page

Final Thoughts

me at bhnc

At in-person meeting with Ailed and Esme

It was extremely rewarding working with a non-profit for the semester, especially because I know firsthand how difficult it is to get projects like these off the ground without outside help.

Outside of software development, we learned a lot about how to communicate effectively. While Ailed had a general idea of what she wanted, she didn’t have a clear picture of the possibilities or limitations of a web application. We found that having visual representations ready while discussing features was the best way to elicit useful feedback, absent opportunities to speak face to face. We did manage to make two trips to BHNC in person, and those meetings were the most fruitful. Not only did we clarify many questions, but we also got a feel for the characteristics of Bernal Heights, BHNC, and some of its residents.

Agile development was a first for most of us, and the test-driven process was especially taxing at first. In addition, we had to keep on revising our back-end relationship models as user stories and features were added or discarded. At the same time, our workflow had everyone involved in discussing both UX and implementation, and I enjoyed that immensely. I also liked learning how to test with Cucumber, which made it easier to focus discussion about app features on user needs instead of specific technologies or implementation.

I couldn’t have asked for a better group of people to work with during the semester. I’ll miss getting their Slack notifications :)

team picture


Updated