Building CampaignHawk: An Open-Source Election Canvassing App with Meteor and React (Part 1)

I’ve been asked by a to build an open-source election canvassing app to make it easier to run a campaign. Since it’s an open-source project and I’m using a relatively novel technology stack (Meteor and React), I figured I might as well document the process of building the app.

First a little background. There’s some really good software out there for big campaigns, such as Advantage Inc., Bridgetree, and a bunch of others. But these apps are pricey and are too heavyweight for smaller (i.e. “most”) campaigns. This app is going to be light and can be easily managed by someone running for anything from city council to a state-wide campaign.

Project Scope

The minimum viable product (MVP) is two-fold. It will need a web-view for campaign managers and a mobile-view for volunteers.

  1. Web interface for campaign managers

The specifications for the mobile app will be very different since it will be a different type of user.

  1. Mobile canvassing app for volunteers (primarily a map)

Bonus Scope

There are also a few additional features that would be fun to implement, but are not necessary for the MVP.

  1. Campaign autopilot that recommends actions

Step 1: Wireframing

I use Sketch for my wireframes and Invision for live prototypes. There are many different methodologies for wireframing. If you are not familiar with the process, I highly recommend this article by Tuts+. Since I’m building this app myself with no input from designers, I’m just going to go from sketch → code and skip all the intermediate steps.

I’m going to use as much from Material Design as possible because it goes well with this type of app. Also, since everything in this app can be managed through the main view using modals and popouts, I’m going to do away with the traditional navbar and add a set of tools in a sidenav on the left. The basic design will look something like the image below.

Ignore the icons. They’re just placeholders at the moment.

Now that we have the basic idea for the interface, let’s give some thought to functionality.

I always think of these things in terms of user interface, so we’re going to let the tools in our sidenav determine the functionality. I’m also going to add a map since the map is the core of the app.

Each icon has a tooltip describing the functionality of the tool.

Some of these features won’t be active in the MVP, so we won’t bother wireframing them at this point.

The Data Layers tool is the core functionality of this app. We want to make it easy for a campaign to see data relevant to the district they’re targeting. We’ll focus on three data layers: Republican-Democrat (R-D), Voted in the last two years (V2), Feelings on issue X (IX). These data layers will have different visual characteristics.

R-D will show the entire district divided into two colors: red and blue. These areas are aggregated and displayed in blocks.

V2 will color only the homes that have voted in the last two years. This is because public voting records are much more specific, providing names and addresses of people who have voted.

IX uses less precise data, so we’re going to use a heat map to make it clear that we’re giving more of a general sense of an area’s beliefs.

Special thanks to Sim City and my childhood for inspiring these data visualizations. I’m not going to feign accuracy or granularity in these wireframes. I’m just going to do the minimum to get the point across.

Republican-Democrat data layer.

For our “Voted in the last two years” data layer, we’ll darken the background to make the voters stick out more.

Voted in the last two years data layer.

And for “Issue X”, we’ll use a heat map to show where interest in a particular issue is focused.

Looks like the Republicans are really fired up about Issue X.

The next tool for the MVP is “Add a Volunteer”. There isn’t a lot of data that goes into this, so it should be pretty easy to do in a form on a modal.

Modal for adding a new volunteer.

We can always go back and change the input fields at a later point, but this template should suffice for now.

The second to last tool we’ll wireframe for the MVP is the user list. The campaign manager is going to use this as something of an address book for all the volunteers in his campaign, so we might as well use the same format. We can also do this in a modal since its functionality is not relevant to the map.

Modal for user list.

I didn’t bother filling in the user details because we all know what information goes into a user contact.

Now that the campaign manager can see lots of data and has a list of the volunteers in his campaign, he’s going to want an easy way to dispatch volunteers to canvas a particular area. I haven’t decided on the best way to implement this — Freehand draw? Dragging a circle? Make a rectangle? — so I’ll just make something basic.

I imagine you will first select an area.

The first step is to select an area.

Then, a modal pops up and we select someone from our contact list to dispatch to canvas the area. This might involve a date picker at some point, and maybe some information on how far away the volunteer is from the target location.

Amar has been selected to canvas that particular area.

Next steps

That should do it for wireframes. The next step is to start coding the app. We’re going to do the web app and the mobile app separately since their functionality is so different that they’re basically two separate apps that interact with the same database.

Software developer, founder, author - CarDash - Learn Phoenix -

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store