Understand and develop a GovDelivery sign-up interaction that integrates with the principles and patterns of FEC.gov

[jenniferthibault]

So that users don't need to leave their path to sign up for updates from the FEC, use the GovDelivery API to integrate the sign-up experience directly on pages of the site:

🎨 Sign up interactions & styled designs in https://github.com/18F/fec-cms/issues/1044#issue

• [x] Meet with GovDelivery
• [x] Figure out if/how we can create signups that are conditional based on a URL string in the place in the template where we'd like to serve it.
• [ ] Work content into template (conditional based on whether the GovDelivery designers want to issue a PR into our repo instead, we're waiting on that answer as of 10/31).
• [ ] Review and test GovDelivery signup solution

(cc @jameshupp )

[noahmanger]

Ok an update after some reconnaissance in the GovDeliver API docs:

• First, we'll need to get account credentials to use the API. @patphongs can you help with this?
• It's totally possible to post from a signup from hosted on fec.gov to the GovDelivery API and have an email account sing up for a topic or set of topics
• Managing the subscription, if I'm reading the designs correctly, looks like it's happening in the GovDelivery UI, right? I think if we can not worry about that it'll be better
• Because there's so many places to sign up for topics, we may want to break the implementation up into smaller chunks. But I need to understand better about what's wanted at each sign up location.

Maybe we could chat about this at design pairing on Friday and flesh this issue out then?

[jenniferthibault]

@noahmanger definitely good to talk through Friday, it's a very web-like issue.

We also have a call set up at 2 (right after design pairing) with the GovDelivery folks to understand more, and @jameshupp is starting a list of questions to ask. If your schedule is clear and you are able to join, that sounds like a good thing!

@jameshupp has also delved into the API docs extensively so may have some info to fill in some of your questions. The only one I see that's not in line with how I thought things would work is that I thought managing the subscription was going to happen on the site via the API, instead of the GovDelivery UI. @jameshupp what direction were you thinking?

[noahmanger]

Great. Yeah I can join.

Re: managing subscriptions on the site, I'd really advise against this (for now). Doing so would mean having to set up username / password logins and a whole new UI for the stuff.

[jameshupp]

Are we using "managing" to mean two different things?

• Adding someone to a topic in the first place (which our designs have happening on FEC.gov via the API, and which I think probably should for a handful of reasons).
• Letting someone interact with their chosen subscriptions, adding themselves to additional, etc (which I think we haven't designed for and which should happen on the GovDelivery domain for simplicity's sake).

I can see some complication in the first one (for example, needing to select the right topic when adding a signup form to a page). But I think the reason to do it is pretty compelling. It's a stronger general web usage pattern, for one thing. And for another, while we can set a defined post-subscription landing page if someone goes through the GovD-hosted version, I believe (we'll have to check) it won't bring them back to the content they were looking at. This could be a problem, since FEC content and data both tend to be pretty specialized. Our IA is good but not infallible, and it's really frustrating to have to relocate something. There's more than this that justifies it, but these seem like the most immediate.

[jameshupp]

Oh, and to the password issue: it's not required when signing up. We can skip that unless there's a specific security concern around this. That's a question we can ask Friday, though: how much is that feature implicated by users' experiences. The only insecurity of not requiring a password is that someone who knows your address can add/subtract subscriptions. They can't really change anything else or access other information about you, as far as I know.

[noahmanger]

Oh! Good clarification. I was referring to the second one. The first one, entering your email address and choosing which topics to subscribe to shouldn't be a problem. It's the part where you can login and edit your existing subscriptions that seems extra hard and not quite worth it.

So we're in agreement as far as I can tell.

[jenniferthibault]

Great! I was just the one confused, I had initially thought we were trying to do it all on fec.gov, including letting people interact with their chosen subscriptions, but looks like that's not the case 😅

[jameshupp]

I've updated the checklist to reflect current state more clearly. We have the broad outlines of designs for a persistent signup in the footer, as well as a page-specific signup for latest updates. (We'll figure out other page templates later, but we know how this one ought to work and what the list structure is.) There's a question about whether we can serve a different target for the form based on the string in the URL that determines which type of update.

For example: on the Press release page — URL is https://www.fec.gov/updates/?update_type=press-release — can we serve a press release-specific signup form, and then serve an FEC Record-specific signup form on https://www.fec.gov/updates/?update_type=fec-record?

I'd love it if @johnnyporkchops or @xtine can help us figure out teh answer to this.

We'll also need to work the signups into the template once we have final code for it. The GovDelivery solution is to drop something in with in-line styling, and we don't want to do that. I'm sure I can do it properly with just a bit of introduction to where and how our styles live.

[xtine]

@jameshupp: we can already figure out what kind of page it is from the back-end side (ex: if it were a press page or record page), but if we are going to drill down from what type of update it is on the updates page, we additionally have the front-end advantage of being able to grab the variable (press-release and fec-record) from the URL query string itself. Then it's just matter of logic in the footer template to figure out which form to serve.

Basically so technical garble aside, the answer to your question is yes.

[jameshupp]

@xtine Rereading your comment, I just want to clarify: there's a persistent footer signup that wouldn't change from update to update. There's a second signup that's within the accordion content that would change from update to update. Seems like this wouldn't change anything in the functionality of what you're describing, but it'd be adding the logic to the accordion template rather than the footer template.

[jenniferthibault]

@jameshupp this came up in sprint planning today, could you give an update on the status and needs to move this forward?

[jameshupp]

Sorry I was late. We are getting revised designs back today. The things we need to move this forward:

• Where are do the templates live so GD could issue their own PR if that is appropriate?
• Alternatively, if we have the front-end capacity to do it, can we incorporate it into the templates ourselves?

We'll be able to see the code when we get the revised designs, and as written I know it's not how we would implement it. If we want GD to issue their own PR, we'll need to give them a bit of instruction so things start the right way. (For example, they'll probably need us to tell them "Don't write the styling with in-line declarations. Write the style into the CSS file and then call that style class.") I imagine in reviewing their PRs we'll have to make some tweaks so the rendering matches FEC style more closely. But if this might save us developer time I still think it's the right way to start.

The short version of all this is: implementing the signup is actually concomitant with developing the signup. They are finishing their design today, and then we need to figure out whether to implement ourselves or point them toward the right PR.

[xtine]

• Templates

  • The footer is not defined in just one template, unfortunately as it's separated from the /data/* pages and the rest of the site:
  • Data: https://github.com/18F/fec-cms/blob/develop/fec/data/templates/layouts/main.jinja
  • Everywhere else: https://github.com/18F/fec-cms/blob/develop/fec/fec/templates/base.html
  • However, we can define a template partial for GD and include it in both templates so we only edit GD from one place.

• Capacity

  • Front-end capacity for FEC is quite low, and we want to focus on getting current WIP features and bugs to be done before assigning new things to folks. However, this is something I may have time for if I can get the code in the next couple of weeks.

[jenniferthibault]

My $0.02 — let's take advantage of Christine's availability (and familiarity with the codebase, speed, and general awesomeness) to knock this out and get it off of our collective plates.

[jameshupp]

I am inclined to agree. I have a meeting with them tomorrow AM. We'll figure out which way to go.

[jwchumley]

James will close and open a new narrower issue.

[jameshupp]

Closing in favor of implementation issues #1669 and #1670.

[johnnyporkchops]

Here are a rough screenshots of the conditional accordion for the updates page:

[AmyKort]

Thanks @johnnyporkchops This is great.

[jenniferthibault]

Hey @jameshupp and @johnnyporkchops — I'm seeing the updates here and from https://github.com/18F/fec-cms/issues/1670, and I'd like to understand where the logic for conditionally changing the accordion came from better, as it diverges from the designs in https://github.com/18F/fec-cms/issues/1044#issuecomment-321915091 I thought we were working toward.

This interaction feels a little clunky to me because the way we've designed the publication type filter interaction. Currently, you change the filter and everything below the filter position in the feed responds to that change. Making a conditional change above the filer position creates two areas of change (above and below the core control), and breaks the existing model of where people should expect to change.

Let's chat about this at the design sync today? But if there's background on the conditional logic change you want to add here beforehand, that would be great!

[johnnyporkchops]

@jenniferthibault , I believe this was just a test to confirm that we can conditionally change the signup options based on the content chosen on the updates page, I think that was one of the current task for this issue so that Amy could report on its viability to info, although I may have misunderstood the scope of what was supposed to be done. Looking forward to learning more in design sync.

[AmyKort]

Thanks @johnnyporkchops !