Avotecado

CPSC 436I (2019)

An example image of the avotecado politician page

Summary

Avotecado is a webapp made to deal with municipal political data (votes, politicians, etc.) so regular folk like myself can read it. It is a full stack app based on Meteor.js, with a React front end.

Links

source
Currently not deployed.

My Roles

Tools

Lead Programmer, Prototyping, Team Manager.
I wore many hats during this project. Initially, I started as the programmer, and as time went on, I also became the team manager. As with any team-based project, there was a need for someone to manage the team, i.e. assign tasks in an efficient manner, make certain decisions, etc. I tried to do so in a way that was considerate of people's lives outside of the project.

Long Form Explanation

Background, Context

Avotecado is a web application that helps people keep track of municipal politics. Using Avotecado’s political aggregation toolkit, users can follow elected officials, track how they vote on issues, and uncover voting patterns that can get lost in the daily news cycle. Avotecado's goal is to foster engagement beyond election cycles by making political data accessible, easy to understand.

We chose municipal politics for 2 reasons:

  1. High degree of apathy; Municipal politics has some of the lowest percentages of political participation (vs. provincial or federal).
  2. Party Discipline; The parliamentary form of provincial and federal politics leads to politicians almost always voting along party lines. Municipal politics offers an opportunity to see what types of issues cause politicians to vote against party lines.

Goals of Avotecado

One goal was based in technology. This project was a process in learning to build a web app. We set out to learn relevant web technologies while making a prototype of something we felt could be useful.

The other goal was based in accessibility of knowledge. We wanted to try to make something that would help people understand local politics and be able to participate/be involved, even if only tangientally through being informed.

Tracking politicians is difficult once they get elected. Elected officials often do and say things that are not the same, and we want to help users track the day-to-day decisions politicians make and provide tools that allow users to see patterns in voting behaviour (if and when they exist).

Legislation/Votes are also difficult to track. It is difficult to parse through the legal language that comes with legislation and their pathways to becoming law are difficult to follow. We wanted to present these items to average voters in ways that are easily understood, both qualitatively and quantitatively.

Design Process

We took a problem-solving approach to this project. As previouly noted, in municipal politics, it is difficult to follow politicians/legislation and there is a higher degree of apathy. With that in mind, we set out to design a solution to fix this.

Throughout the initial ideation of avotecado, we initially came up with some feature and user flow ideas (Figure 1). We practiced an agile based design-iterate methodology. We would come up with some ideas, run them by each other, talk through it, and then discard/evolve the idea.

The various rough sketches pictured below were just quick run throughs of what could have been, and represent things we would try expand on.


Fig. 1. User flow diagram we made to help us design overall functionality/interactivity of the app, and think through conceptual models, as well as the data we might need.


Fig. 2.

Fig. 3.

Fig. 4.

Figures 2, 3 and 4 show the initial idea we had for the homepage. We wanted to have a landing page that asks the user for their location and then proceeds into a selection page (Fig. 5). The selection page would either be the most recent city votes, a politician selection page, or a party selection page. The default 'home' would have been settable by the user. This idea was scrapped due to time-constraints, we ended up focusing on Vancouver.

We wanted to keep the UI consistent through both mobile and desktop.

We discussed alternate ideas as a team and settled on something a bit different than the proposed sketches. We drilled down on the actual required functionality and deemed features like the city picker as unnecessary for the minimum viable product.


Fig. 5

Fig. 6

Fig. 7

Results

We were able to create an app that allows users to track municipal politicians and built a searchable record of all the votes the recently elected Vancouver City council made since November 2018 - with some added features (user profiles, voting records organized by party for instance).

The project established a useful base that can be expanded upon. We implemented functionality that addressed the problems in the goals section at a foundational level, but numbers and visualization are only part of the whole picture. There is a deeper level of analysis required.

Generating the political analysis from the data we aggregated turned out to be a significantly more complex problem than we would have been able to tackle with 1. our skill-set at the time, and 2. the amount of time we had.

Challenges, Lessons Learned

I dealt with quite a few challenges during this project.

  1. Our iterate-test-reiterate process was a difficult but rewarding experience; it cemented the need for throw-away prototypes.
  2. As project manager, I had to deal with unforseeable real life issues that popped up and pivot accordingly. I had to work around a personal issue that prevented a larger time commitment from one member. The way I did this was to give that member tasks they were super comfortable with and knew they could get done quickly for the initial data gathering phase of the project.

Many lessons were learned while doing this project.

  1. The number one lesson was to temper expectations. We wanted to do *too* much with too little time, ability, and data.