I have been going to meetups at Code for San Francisco since September. I found myself working with their UX Research group on a web app (tentatively called Project Match) that will help users find projects they are suited for based on their skill set and civic interests. This is something that our team hopes will be useful for every Code for America group because the challenge of new volunteers finding a good fit is a persistent issue in the civic/volunteer tech space.

When I first arrived, the app had the matching algorithm complete, and there was a very rough UI in place. However there were many proposed features of the app that were still in the early discussion phase of development. So it was a good time to get involved with the project! After some discussions with the lead developer it was decided that I would work on the messaging component.

The idea about the messaging component before I arrived was that it would imitate how craigslist handles exchanges between strangers with an intermediary email address that protects the privacy of both users. However when I looked into how we might implement that it didn’t look like something that would work for the team’s shoestring budget (with automated, bulk email services you get what you pay for).

Code for SF makes heavy use of Slack to enable collaboration among teams. I decided to leverage that by building a messaging system that relied on Slack’s Web API to facilitate communication. When new users find a project they are interested in they could fill out a text field, the server would process that message and make a Slack Web API call to have a bot send a direct message to the appropriate team lead. On the back-end there is also a messaging queue system implemented that serves two important functions. First, if a slackbot receives too many requests at once it can shutdown for a bit and some messages get lost in the ether. This is a good thing since it guards against spam communication. By sending individual messages at regular intervals, the messaging system avoids this possibility. The other point of the queue system is it acts as a check to confirm messages are sent. When the server receives the message from the client, it is recorded in the Project Match database, and it is stored there until it receives a message back from Slack’s API stating that the request is “OK” (i.e. the message was successfully sent). Once that is logged it is okay to delete the message, which it does on a weekly basis.

This seemed like an elegant solution to a pressing problem with the current Code for San Francisco design, which currently does not have a simple way to contact a project that looks interesting. As the app develops, the messaging component might also get utilized by the admin component to facilitate communication between different types of users that use the admin component. I am currently working on the admin component, so I will discuss that more in a future blog post.