Skip to content
This repository has been archived by the owner on Dec 23, 2017. It is now read-only.

So that users understand how totals and sub-totals are generated, provide consistent and accurate linking to source data #873

Closed
2 tasks
noahmanger opened this issue Oct 21, 2015 · 0 comments

Comments

@noahmanger
Copy link
Contributor

Background

FEC data includes two types of similar but almost-always-unequal data points (here's my attempt to label them as clearly as possible): Totals data and Itemized data. In turn, we display each of these types in two different ways each:

1. Totals data

A. Reported totals: These include things like "Total Receipts" and "Total Disbursements" for a particular reporting period (e.g. Q1 2015). These numbers are taken directly from a Form 3 and displayed on the site in the details panel for filings:
image

B. Combined totals:
We can also add together these totals for multiple reports in a broader period, such as all reports filed in 2015 - 2016. These totals are displayed places like the financial summary tab:
image

The candidate page:
image

And the top part of the elections pages:
image

2. Itemized data

A. Itemized transactions: At the same time, committees report itemized transactions via Schedule A and B forms. So (and this is a little oversimplified) a committee will report "Total receipts" as a single number in one place on the form, and then on the attached Schedules will report the itemized transactions that should in theory add up to that total. The thing is, they rarely do, for various reasons. We display these itemized transactions on the /receipts and /disbursements pages.

B. Aggregated itemized transactions: Just as we can add up the top level totals, we also run our own math on these itemized transactions to create what we call aggregates or sub-totals, such as total raised from individual states, different occupations, etc. These are visible on the sub-tabs on the committee page:

image

And at the bottom of the elections page:
image

The problem

The fact that Totals Data and Itemized Data seem like they should be equal but fundamentally aren't poses a challenge. How can we build an interface where we have consistent behavior when linking to the raw data that underlies a number we show when in that underlying data is going to be different for similar looking numbers: for Totals (Reported or Combined) the source data is necessarily the Filings that the numbers were reported on; for Itemized data, the source data is the Receipts or Disbursements we're adding up in different ways to generate an aggregate.

If this sounds complicated and annoying, it's because it is :)

Proposed rule

So here's me trying to distill what we just talked about into as concise a rule as possible:

  1. Totals data: If we cannot show a list of itemized transactions — such as when dealing with top-level totals like Total Receipts or Total Disbursements — do not make the number a link, but instead include a link nearby that says something along the lines of "View source forms".
  2. Aggregated itemized transactions: If we can generate a list of itemized transactions (receipts or disbursements) that constitute a sub-total / aggregate (e.g. all contributions from California; all contributions between $500 and $999), make number a link with a title attribute that says "View itemized transactions" on hover.

Specific follow-up:

On the top comparison table on elections pages:

  • Remove links from the "total receipts" and "total disbursements" columns as these should not link to itemized data
  • Replace the "Most recent report" column with a "Source forms" column (not sure what the label should be) that links to /filings filtered down to the reports that make up that Combined Total.
jmcarp added a commit to jmcarp/openFEC-web-app that referenced this issue Oct 21, 2015
* Remove total receipts and disbursements links.
* Add links to source filings.

[Resolves fecgov#873]
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants