Tagged reporting

Election Results Reporting – Assumptions About Software

Today I’m continuing with the second of a 3-part series about what we at the TrustTheVote Project are hoping to prove in our Election Night Reporting System project.  As I wrote earlier, we have assumptions in three areas, one of which is software. I’ll try to put into a nutshell a question that we’re working on an answer to:

If you were able to get the raw election results data available in a wonderful format, what types of useful Apps and services could you develop?

OK, that was not exactly the shortest question, and in order to understand what “wonderful format” means, you’d have to read my previous post on Assumptions About Data. But instead, maybe you’d like to take a minute to look at some of the work from our previous phase of ENRS work, where we focused on two seemingly unrelated aspects of ENRS technology:

  1. The user experience (UX) of a Web application that local election officials could provide to help ordinary folks visualize and navigate complex election results information.
  2. A web services API that would enable other folk’s systems (not elections officials) to receive and use the data in a manner that’s sufficiently flexible for a variety other services ranging from professional data mining to handy mobile apps.

They’re related because the end results embodied a set of assumptions about available data.

Now we’re seeing that this type of data is available, and we’re trying to prove with software prototyping that many people (not just elections organizations, and not just the TrustTheVote Project) could do cool things with that data.

There’s a bit more to say — or rather, to show and tell — that should fit in one post, so I’ll conclude next time.


PS: Oh there is one more small thing: we’ve had a bit of an “Ah-ha” here in the Core Team, prodded by our peeps on the Project Outreach team.  This data and the apps and services that can leverage that data for all kinds of purposes has use far beyond the night of an election.  And we mentioned that once before, but the ah-ha is that what we’re working on is not just about election night results… its about all kinds of election results reporting, any time, any where.  And that means ENRS is really not that good of a code name or acronym.  Watch as “ENRS” morphs into “E2RP” for our internal project name — Election Results Reporting Platform.

Election Results Reporting – Assumptions about Data

In a previous post I said that our ENRS project is basically an effort to investigate a set of assumptions about how the reporting of election results can be transformed with innovations right at the source — in the hands of the local election officials who manage the elections that create the data.

One of those assumptions is that we — and I am talking about election technologists in a broad community, not only the TrustTheVote Project — can make election data standards that are important in five ways:

  1. Flexible to encompass data coming from a variety of elections organizations nationwide.
  2. Structured to accommodate the raw source data from a variety of legacy and/or proprietary systems, feasibly translated or converted into a standard, common data format.
  3. Able to simply express the most basic results data: how many votes each candidate received.
  4. Able to express more than just winners and losers data, but nearly all of the relevant information that election officials currently have but don’t widely publish (i.e., data on participation and performance).
  5. Flexible to express detailed breakdowns of raw data, into precinct-level data views, including all the relevant information beyond winners and losers.

Hmm. It took a bunch of words to spell that out, and for everyone but election geeks it may look daunting.  To simplify, here are three important things we’re doing to prove out those assumptions to some extent.

  1. We’re collecting real election results data from a single election (November, 2012) from a number of different jurisdictions across the country, together with supporting information about election jurisdictions’ structure, geospatial data, registration, participation, and more.
  2. We’re learning about the underlying structure of this data in its native form, by collaborating with the local elections organizations that know it best.
  3. We’re normalizing the data, rendering it in a standard data format, and using software to crunch that data, in order to present it in a digestible way to regular folks who aren’t “data geeks.”

And all of that comprises one set of assumptions we’re working on; that is, we’re assuming all of these activities are feasible and can bear fruit in an exploratory project.  Steady as she goes; so far, so good.