Today, I'll be concluding my description of one area of assumptions in our Election Night Reporting System project -- our assumptions about software. In my last post, I said that our assumptions about software were based on two things: our assumptions about election results data (which I described previously), and the results of the previous, design-centric phase of our ENRS work. Those results consist of two seemingly disparate parts:

1. the UX design itself, that enables people to ask ENRS questions, and
2. a web service interface definition, that enable to software to ask ENRS questions.

In case (1), the answer is web pages delivered by a web app. In case (2) the answers are data delivered via an application programming interface (API). 

Exhibit A is our ENRS design website http://design.enrs.trustthevote.org which shows a preliminary UX design for a map-based visualization and navigation of the election results data for the November 2010 election in Travis County, Texas. The basic idea was to present a modest but useful variety way to slice and dice the data, that would be meaningful to ordinary voters and observers of elections. The options include slicing the data at the county level, or the individual precinct level, or in-between, and to filter by one of various different kinds of election results or contests or referenda. Though preliminary, the UX design well received, and it's the basis for current work to do a more complete UX that also provides features for power users (data-heads) without impacting the view of ordinary observers. 

Exhibit B is the application programming interface (API), or for now just one example of it:

http://design.enrs.trustthevote.org/resources/precincts/precinct324/contests/governor

That does not look like a very exciting web page (click it now if you don't believe me!), and a full answer of "what's an API" can wait for another day.

But the point here is that the URL is a way for software to request a very specific slice through a large set of data, and get it in a software-centric digestable way. The URL (which you can see above in the address bar) is the question, and the answer is what you above as the page view. Now, imagine something like your favorite NBA or NFL scoreboard app for your phone, periodically getting updates on how your favorite candidate is doing, and alerting you in a similar way that you get alerts about your favorite sports team. That app asks questions of ENRS, and gets answers, in exactly the way you see above, but of course it is all "under the hood" of the app's user interface.

So, finally, we can re-state the software assumption of our ENRS project:

• if one can get sufficiently rich election data, unlocked from the source, in a standard format,
• then one can feasibly develop a lightweight modern cloud-oriented web app, including a web service, that enables election officials to both:
  • help ordinary people understand complex election results data, and
  • help independent software navigate that data, and present it to the public in many ways, far beyond the responsibilities of election officials.

We're trying to prove that assumption, by developing the software -- in our usual open source methodology of course -- in a way that (we hope) provides a model for any tech organization to similarly leverage the same data formats and APIs.

-- EJS