Wireframe election summary race pages

[jenniferthibault]

What we’re after:

As part of the larger effort to incorporate election summary data for all federal elections, we are focusing on the most valuable data to our users today, which is also the data that is (mostly) already available in the API: race-level data. These pages already exist in the new FEC.gov site, but currently provide a minimal amount of information. The wireframes we will work through in this issue will incorporate new, and relevant information important to our users, such as information previously hosted by the compliance map. These changes will serve as the foundation, one in which we will later build on to create the state- and nationwide summary views. Following an agile approach, we’ll iterate to improve these race pages before adding additional views in later sprints.

In this issue, we need to nail down the data we need to provide and ensure that the logic employed can support that need, and vice versa. We also need to incorporate feedback and initial ideas discussed during a first introduction with the broader team at design sync.

For more information on the rationale behind this decision to focus on race-level data and the takeaways mentioned from design sync, please see #1531.

Current state of wireframes:

View of all race-related date on one-page.

Alternative option. If we do not pursue a one-page view for all race-related data, this option provides for a separate "About this election" page, with additional content.

Completion criteria:

This issue will be ready to close when we:

• have a complete recommendation for what data we will show on this page template (informed by user needs and API requirements)
• can outline changes needed to the API to support the above
• can define with more certainty the interactions used in the template for big screens. (Will conduct testing to validate design decisions then design for small screens.)

We expect that this will take the form of a medium-fidelity wireframe or prototype that demonstrates what data is available on these pages, how users navigate to and between these pages in the current architecture (from flows defined in #1531). Styling should not be a concern in this issue, and can be completed in a follow-up issue.

Content needs and sources

DATA:

• Identify which elements of existing race page content will be integrated into new page: i.e. candidate financial totals, individual contributions, and/or spending by others to support/oppose
• Refine specific outline of data and content to be presented in these pages. Support decisions with user-informed rationale and logic
• Confirm that the data services logic currently in place can support proposed designs
• Make all design changes to wireframe based on data logic discussion

COMPLIANCE:

• In order to understand the value and structure of compliance data/information, talk to Content team about compliance (dates & deadlines) content
• Integrate changes based on content discussion

REFINE DESIGNS:

• Finalize which visual interface components and interactions will be used
• Move to implementation issues:
• New issue for integrating pattern library styles and components to wireframes for large and small screens (this gives us a chance to make/apply the more exact interface styles)
• New issues for any changes to the API to create supporting data for the templates (TBD)

[dorothyyeager]

For Jonella - this issue at https://github.com/18F/fec-cms/issues/1133 was originally to start looking at bringing over compliance deadline info for states and reports. So it might be helpful. Kathy Carothers in Info would be a good person to chat with. The page linked in that issue is now redirecting, but the pages for each state are hidden behind https://transition.fec.gov/info/ElectionDate/.

[JonellaCulmer]

@patphongs I'm trying to determine whether users are viewing the "individual contributions" or "spending by others to support/oppose" on election pages. When reviewing the analytics, it seems like we can't dig any deeper then the main election page. /data/elections/, when I'd like to look at /data/elections/senate/AL/2018/?tab=contributions and
/data/elections/senate/AL/2018/?tab=spending-by-others.

Do you know how we can drill down to this information?

[fec-jli]

I quickly look at the endpoints "election-dates" and "reporting-dates under /dates/
I think we can get some data from thoes two endpoints.
but, I am not sure do we need these date to display such as pre_primary_48h_19, pre_primary_48h_2 ?
here are some formulas in java code:

to_char(To_Date(ELECTION_DATE,'Month DD, YYYY')-19,'Month DD, YYYY') as pre_primary_48h_19, 
to_char(To_Date(ELECTION_DATE,'Month DD, YYYY')-3,'Month DD, YYYY') as pre_primary_48h_2, 
	
to_char(To_Date(ELECTION_DATE,'Month DD, YYYY')-19,'Month DD, YYYY') as pre_runoff_48h_19, 
to_char(To_Date(ELECTION_DATE,'Month DD, YYYY')-3,'Month DD, YYYY') as pre_runoff_48h_2, 

to_char(To_Date(ELECTION_DATE,'Month DD, YYYY')-19,'Month DD, YYYY') as pre_general_48h_19, 
to_char(To_Date(ELECTION_DATE,'Month DD, YYYY')-3,'Month DD, YYYY') as pre_general_48h_2, 

to_char(To_Date(ELECTION_DATE,'Month DD, YYYY')+20,'Month DD, YYYY') as close_of_books_postG, 
to_char(To_Date(ELECTION_DATE,'Month DD, YYYY')+30,'Month DD, YYYY') as mailing_date_postG, 
to_char(To_Date(ELECTION_DATE,'Month DD, YYYY')+30,'Month DD, YYYY') as filing_date_postG 

---

[JonellaCulmer]

@LindsayYoung Do you mind taking a look at this issue briefly? Specifically, @fec-jli's note. Want to make sure we can pull the necessary information for this page design with existing API endpoints, or determine whether we need to create a new endpoint for reporting dates and deadlines. (Please see the bottom of the first wireframe for more information, or ask me any necessary questions.)

[LindsayYoung]

The design is great. Here is my long answer about some of the data constraints with some context.

Election information

I love having the state election office info with the race info! Do we have that information in a table by state somewhere @jwchumley @PaulClark2? If so, adding this as an endpoint should be easy.

Contributions

First thing that I think has been addressed in red, is that we don't have a good way of doing the donor aggregations. So, we can show things like the record with the most money per record, but don't have a reliable way of doing donor aggregations. The committees are responsible for normalizing their own data- so the consistency can very committee to committee.

There isn't a good way for us to CRP and others do extensive research to figure out donor information, it can be complex to do correctly because the same person can use nicknames, can have multiple addresses, explain their occupation in multiple ways and conversely, different people can have the same name, share an address etc. For example a record for Bob Lannon and Bob Lannon Jr. could be the same person or different people.

We once looked into using the committee's cycle to date records as reported by the committee but if I remember correctly @PaulClark2 and @jwchumley said those were not amended reliably dependable enough to publish.

Dates

We have two sources for dates. The calendar dates that you can see on the website or API /calendar-dates endpoint These dates are the best vetted but they do not include machine readable information on the districts or states so we can't use them for particular elections. So we can't link from he /election-dates or /reporting-dates to the /calendar-dates

Flagging this for @AmyKort that we still do have some of the fecapp table data that is in the election search, but we are using a much smaller subset of the dates- I think it is general and special generals I can confirm if you need an exact answer.

Random election page for reference:
https://www.fec.gov/data/elections/?cycle=2018&state=CA

My understanding is that the reporting dates and election dates for the fecapp tables are not produced in a way that makes them easy to vet, check or edit the data. Additionally, incorrect dates can have significant legal implications- like people saying they did not file because the date on the calendar was wrong.

The to implement the dates and deadlines we would want to implement a new system that uses the wagtail admin to create, edit and publish the dates in a structure that can fulfill all the things we need and is easy to check and edit. This has been something we have wanted to for a while. I am happy to give people specifics on the schema we would need and how to implement it but I think that is too much for my already too-long ticket.

[AmyKort]

Awesome! Could we make some time to talk about the Wagtail admin option for reporting dates? I'd really like to understand that better.

[JonellaCulmer]

Thanks so much for that feedback, @LindsayYoung. As for the dates section of your comment, it was my understanding from the content folks that the data pulled into the compliance map (from a database) has been pretty solid and accurate. (@fec-jli) Do you imagine that that would be used as part of the new system you mentioned?

[JonellaCulmer]

Updated wireframes can be found in the below prototype link. Please let me know if you cannot view. I made the prototype link to make it easier to view and compare the different options we have at this point. Each page is labeled (with red text) to explain what each options provides.

PROTOTYPE: (Will need to zoom in, and arrow through the screens)
https://xd.adobe.com/view/2f23dfba-ec75-4885-b3ac-98f47b986bf9?hints=off

WHAT'S BEEN LEARNED:
Based on a few different discussions some changes have been made to these updated wireframes from the original:

1. After data services discussion (and additional feedback from Lindsay), it was determined that there is no aggregated data based on contributor name. Data services and salient can clean up the data a little bit (compare names by name, address, occupation and employer) but it's not as reliable as it would be for "Top contributor" feature at this time. If, after testing, we discover that this information is valuable to our users we can explore again. But at this time, it's been removed.
2. Data currently live on the fec.gov election pages is not being utilized. However, based on analytics alone, we cannot determine whether this information is simply being overlooked or if users are not interested in this content. After speaking with the Press office some of that information would be valuable closer to elections (contributions by dollar amount), but again, testing would be needed to rule it out. Therefore it is my recommendation that we continue to provide this information until we have enough information to remove.

Of the 4 versions presented, I'm leaning towards Version 4. This version groups data sets and compliance information, uses the horizontal toggle in a new way (similar to the vertical toggle used for IEs) that would allow users to switch between data sets and minimizes the amount of scrolling required by users to get to valuable information.

NEXT STEPS:

1. Pending some additional feedback on the dates information, from Lindsay, we need to agree on which direction we'd like to pursue, specifically which layout. This would merely provide a direction to test. @PaulClark2 @patphongs @LindsayYoung
2. @AmyKort Can someone from the content team take a look at the language used for the sections below:
   First, to describe how only the next two reports would be displayed and that additional reports can be found on Dates and deadlines. I have draft language included for review or replacement.
   
   Second, to describe that FEC doesn't handle everything and that state offices need to be contacted for additional information outside of FEC's jurisdiction.
   

[AmyKort]

@JonellaCulmer . How about:

State laws and procedures govern elections for state or local offices as well as how candidates come to appear on election ballots. Contact the appropriate state election office for more information.

AND

This list only includes the next two reports that are due. For the complete list, please see All filing deadlines.

[JonellaCulmer]

@AmyKort Thanks so much, Amy. It looks great!

[JonellaCulmer]

After a number of discussions, below are the updated wireframes. We will use these version to test at the DC Conference for a user-informed validation of our design decisions or to make any improvements.

Designs

VERSION 1

VERSION 2

ABOUT THIS ELECTION PAGE

NEXT STEPS:

• Conduct user testing to validate data, content and design decisions (https://github.com/18F/fec-testing/issues/106)
• Finalize which visual interface components and interactions will be used on large and small screens
• outline changes needed to the API/ or whether the development of a new tool is necessary to implement
• Move to implementation issues:
  -- New issue for integrating pattern library styles and components to wireframes for large and small screens (this gives us a chance to make/apply the more exact interface styles)
  -- New issues for any changes to the API to create supporting data for the templates (TBD)

[JonellaCulmer]

Closing in favor of testing issue: https://github.com/18F/fec-testing/issues/106