CA Alerts (https://alerts-ca.herokuapp.com), submitted by Very Little Gravitas LLC for the California Department of Technology Digital Services Agile Development Prequalified Vendor Pool Refresh for CDT RFI # CDT-ADPQ-0117.
CA Alerts is a faster, clearer, simpler way for California residents and visitors to be notified of emergencies affecting them and for State emergency workers to assess and inform the public about emergencies.
Ths prototype is based on our experience delivering digital services that meet user needs and are simple and intuitive enough so users succeed first time.
A screenshot walkthrough shows the flow of the production application on our wiki.
Where appropriate, we've applied the plays from the US Digital Services Playbook.
The Product Manager, Dan Hon, also served as Product Owner in the agile delivery process. We assigned him the leader of the project, with full responsibility and authority to build the prototype. He had full accountability for the quality of the prototype.
We assembled our multidisciplinary team based on our experience and GSA 18F Agile Labor Categories:
A photograph of our team doing a remote standup in Sprint 2:
The agile delivery process used at Very Little Gravitas is based on the open standards Scrum framework, with input and iterative feedback from user-centered design techniques.
Our wiki documents our full agile delivery process.
For this RFI, we implemented a simplified process, appropriate to scope and available time. The following describes the work delivered in each of the four 1 week sprints completed in building the prototype.
We used these user-centered design techniques:
CA Alerts is a Python 3 web application built using the Flask micro web framework. Users use the application via a web front-end that uses the U.S. Web Design Standards pattern library.
On the CA Alerts homepage, users can:
The application router __init__.py defines the addresses/routes and HTTP methods implementing the application's functionality. HTTP methods (GETs, POSTs etc) on routes result in running the appropriate code. Routes are rendered in HTML by the Jinja templating engine. The Python module Psycopg is used to connect to the application database. The application database is a PostgreSQL database with the PostGIS extension for geolocation support.
Following the separation of concerns pattern, certain application functionality imported through Python modules in the application's data directory:
Public users register by entering a phone number and a zipcode in an HTML form. The zipcode is entered manually or retrieved using the HTML geolocation API.
Submitting the form as an HTTP POST to the application web server calls the appropriate route to
The user enters their confirmation code at a unique confirmation URL to verify their phone number.
Verified public users (who have entered the correct PIN code) may edit their profile and add an email address. If they choose to receive notifications by email, the Mailgun API is used to deliver email notifications.
Public user login is two-factor authentication. Users log in by supplying something they know (a confirmation code sent by email or SMS) and something they have (access to a phone number or email address).
Admin users manually publish notifications using an HTML form. An emergency notification HTML form is HTTP POSTed to the appropriate route creating a notification object, calling the required functions to send notifications using the appropriate APIs and logs the notification in the application database.
Emergency and related data is displayed using a Leaflet.js map interface on the CA Alerts homepage and in the Admin interface. The application uses a Python object representing emergency data, generated from emergency data stored in the application database. The object is serialized to JSON and delivered inline in the HTML response by the application server when a browser requests a page containing the map template.
On the backend, a scheduled task provided by our PaaS (Heroku) runs a collection script (collect.py) every hour to
The RFI explicitly identifies 20 requirements (a-t) for the prototype submission. Without duplicating the headings, we provide evidence below of how we have met each criteria:
a. We appointed Dan Hon as both Product Manager and leader of the project. He helped the team understand the requirements, was responsible for prioritizing work, and is ultimately accountable for the quality of the submitted prototype
b. Section 2 (above) identifies each member of our multidisciplinary team and their labor category.
c. We surveyed over 30 potential users of the service, and conducted detailed interviews with a number of individuals. Insights from these exercises were used directly in design exploration and reflected in the implementation of requirements. See our research journal.
d. We used 4 user-centered design techniques in Section 4 (above).
e. The project commit history is in Github.
f. Swagger documentation for our RESTful API.
g. Commit history shows how user-facing templates were implemented using standards compliant, accessible, semantic HTML using Progressive Enhancement. The U.S. Web Design Standards were used, which are fully compliant with ADA and WCAG 2.0
h. We used the U.S. Web Design Standards as style guide and/or pattern library. Pull Request 13 shows implementation.
i. Our research journal documents usability testing videos and notes from interviews.
j. The lightweight scrum process we used provided a review point at the end of each sprint, enabling us to reflect users' feedback in the planning session of the next sprint. We iteratively produced features reflecting real users' requirements. See Section 3 (above) for further detail.
k. Using the U.S. Web Design Standards with no custom HTML or CSS ensures a responsive design on multiple devices.
l. We are using the following modern, open-source technologies:
m. The production application is deployed on the Heroku PaaS. Issue 3 shows setup of the Heroku deployment pipeline. The master branch is automatically deployed to https://alerts-ca.herokuapp.com.
n. We have a master list of unit tests, automated tests are run by Travis CI, build and test results are public
o. Travis CI provides continuous integration, automatically and continuously deploying the master branch to https://alerts-ca.herokuapp.com. Issue 3 documents initial setup.
p. Configuration management is implemented in an env-vars file that is used in production on Heroku, in development and for running the Docker image
q. CA Alerts is continuously monitored using Pingdom with a public uptime report.
r. CA Alerts has been built with Docker: a single Docker image includes PostgreSQL, the CA Alerts web application and required dependencies. The production application is deployed on the Heroku PaaS. Learn how to use the Docker image.
s. Learn how to install and run the prototype.
t. Our work and code for this prototype is licensed under the MIT License.