Add Coverage end date to Source reports column on election pages

[JonellaCulmer]

What we're after:
When viewing election tables listing candidates associated with a given election, press contacts have expressed some frustration because they cannot easily determine whether the numbers reflected on these tables contain the latest information. Incorporating the coverage end date into the existing table under Source reports, will help users to more accurately compare candidates across the same time periods.

Design:

Completion criteria:

• Add the coverage end date into the Source reports column with the text reading: "Coverage ending MM/DD/YYYY"
• Change link text from "View" to "View all". Same destination, just a modified link. In the cell, "View all" should be below the coverage end date.

History: https://github.com/18F/fec-cms/issues/1372

[JonellaCulmer]

After having a conversation with Christian in press about a somewhat relevant topic, I realized that the proposed solution does not account for all candidates - those who have not filed reports, those who don't intend to, or those who have yet to.

Some candidates choose to register with the FEC but do not intend on raising money. For those individuals, there would be no 'coverage ending' date because no report has been filed.

When considering a solution to this issue, we also have an opportunity to better inform our data users about what it means when a candidate is listed with $0.00 raised and $0.00 spent. That they've likely only filed their form 2 and nothing else.

[lbeaufort]

@JonellaCulmer @johnnyporkchops here's the PR on the API change: https://github.com/18F/openFEC/pull/2898

[PaulClark2]

We need to make sure it’s clear to users the coverage end date applies to the financial data displayed but not necessarily to the most recent report received by the Commission.

[JonellaCulmer]

Copied over from #1735

---

@PaulClark2 For clarity, at what point are the figures on the district profile page table updated to reflect what's submitted in reports (i.e. the Total receipts and Total disbursement columns)?
Is it once reports are processed?

I was looking back through #1372, the research/design discussion, so as not to discount the motivation for #1470. We still need an at-a-glance way to explain which reports contribute to the figures listed on the table, but also to account for filings submitted after the 7:30 cutoff. So a slight modification to the language, as well as the redirect to committee filing pages, may be sufficient in the interim.

Also, we need a null state for committees whose numbers say $0.00. My understanding is that it would say $0.00 if they have filed $0.00, have yet to submit any reports, or if their information hasn't been processed yet. If I'm mistaken, or forgot any other situations, please let me know.

First stab: cc: @AmyKort

• Processed data through 09/30/2017 | View all
• Processed through: October Quarterly | View all

$0.00 state:

• No processed data

[AmyKort]

My 2 cents: I think it's more helpful to give the date of the close of books for the report than the name of the report since it's not clear from the name that the October Quarterly report doesn't cover any activity in October. $0 state looks great to me. But, I'm going to defer to @llienfec on this because she's super smart.

[llienfec]

"No processed data" for $0.00 makes sense. If we have room, "no processed data this period" would be great for committees that were active and do have data for past cycles, but may not have data for the selected period. I know it's long though.

For processed data - this one is really tricky. I'm leaning toward using the report name. Using the report name is nice and clean, but I agree that report names can be misleading.

Right now, I'm finding using the ending coverage date along with the term "processed through" to be really confusing. I read the bullet as "the data that is included is data that has been processed through 9/30/17" and then thought "how is the Q3 included in the list?" Also, referencing the ending coverage date together with the processed through date may confuse what information is actually included in the list. For example, if a committee files amendments to prior reports, those transactions are before the ending coverage date. Users would think that the updated information is in the source reports. However, they actually can't tell if the amended information is included or not because we can't tell if those amendments have been processed or not. By using the ending coverage date to describe the processed data without referring to it as a coverage date, we're giving an incomplete, and sometimes inaccurate, picture of the data.

This is why I'm leaning toward the report name language. It's pretty accurate and clearly gives the warning that we're after - that only reports through the one listed are included. Maybe we could find a way to link some content resources or glossary definitions that explain reporting coverage dates.

I have definite Monday brain, so if any of this is unclear, or why it matters is unclear, let me know and I'm happy to give explaining another go.

[AmyKort]

Works for me. Thanks @llienfec !

[johnnyporkchops]

Can someone summarize what the decision was for adding language and data to the source reports column. I am having trouble synthesizing the conversation above and in the related issue

[JonellaCulmer]

In looking back at the issue, I'm not certain we came to a final decision. Since the API work that was completed points to the coverage end date, I'm no longer confident we can use the language "Processed by" as those are two different things. Please correct me if I'm wrong on the API work that's been completed, @lbeaufort.

[lbeaufort]

@JonellaCulmer @johnnyporkchops the API work has been done and merged into develop branch on 2/1: https://github.com/18F/openFEC/pull/2898

Example: https://fec-dev-api.app.cloud.gov/v1/elections/?page=1&office=house&sort=-total_receipts&state=VA&district=01&per_page=20&cycle=2018

[llienfec]

I think that we were going to use one of @JonellaCulmer's language options that references coverage date or the report:

• Coverage ending MM/DD/YYYY
• Processed through: October Quarterly

@PaulClark2 requested a that the label is a clear explanation of processed vs raw, but we don't have enough room to make that distinction in this field. We probably need to check with him to see if we should add language elsewhere on the page that talks about the difference since we can't fit it into the label.

Maybe we can add the language we used for the election summary page testing design and put it somewhere around the data table?

Candidate financial totals come from processed data that has been categorized by the FEC. It may not include the most recently submitted electronic filings. Raw data may show more recent filings.

^^This can be done with tooltips if you want (wrote @jcarroll)

[JonellaCulmer]

Thanks for linking the API stuff, @lbeaufort!

@PaulClark2 @llienfec I think because the back-end is already complete and "Coverage ending XX/XX/XXXX supports that completed work, that we stick with that language.

As part of #1735, we can explore new language, particularly if we get feedback that "Coverage ending" is confusing. Especially since #1735 is based on one individual's experience.

Also, I agree that we need to change the copy that explains what data is included in the table. I'm all for using that draft language we currently have in the election summary mock-ups. Perhaps that can wait until after the conference and see if what we have drafted causes any pain. When we make design alterations, based on the testing we do, I can incorporate that copy change into the completion criteria.

[llienfec]

That all makes sense to me. No need to rush to include additional language now. Thanks!

[AmyKort]

Thanks, everybody!

[patphongs]

This code for this has been merged. Closing this ticket.