Design: Events: Editors adding email instead of URL in "Call to Action", causing broken link alerts

[stefaniefgray]

Describe the defect

As an editor on https://prod.cms.va.gov/ creating a new Event, I would like attendees to RSVP by emailing an address such as VANJHCSCommsTeam [at] va.gov.

Unfortunately, if an email address is added as the "Call to Action" URL without the mailto: prefix, it saves as /VANJHCSCommsTeam%40va.gov

Note: The help text for adding an Event "Call to Action" URL does not advise editors to add mailto: before email addresses.

This issue is inconvenient for site visitors who may wish to click the link to RSVP.

This issue also creates broken link alerts that are reported every 30-60 minutes in #content-broken-links until they are resolved by the editor or by a member of the VA Drupal CMS Help Desk team.

Sample broken link alert created by this issue provided in screenshot below.

To Reproduce

Steps to reproduce the behavior:

1. Create a new Event
2. From the "Call to Action" dropdown menu, select "Register"
3. Add an email address to the URL field
4. Click "Save"
5. Call to Action URL will save with improper formatting.

Expected behavior

Email addresses stay true to original formatting when added as an Event "Call to Action" URL without the mailto: prefix.

Screenshots

Real life example:
From https://prod.cms.va.gov/new-jersey-health-care/events/55340

From #content-broken-links:
Broken link report: https://dsva.slack.com/archives/C030F5WV2TF/p1681777264243279

Additional context

If this issue is declined, the help text for Event "Call to Action" URLs should be updated to reflect that email addresses require the mailto: prefix.

Suggested ACs from Help Desk

• Linkit instances enable option (in comments) to recognize email addresses and automatically add mailto:
• Add validation if possible
• (optional) Help text utilizes patch (in comments) to clarify this possibility to Editors

Design

Design file in Figma

Design Acceptance Criteria

• In Figma, Proposed a near-term fix across help text, validation and error messaging, and any other Drupal UI enhancements to either 1) prevent emails from being used at all or 2) ensure that the UI consistently delivers email addresses as a working Veteran experience.
• Met with PM and PO to solidify and ticket next steps

[swirtSJW]

Is there a reason this is facilities specific? This seems like a PW thing.

[stefaniefgray]

@swirtSJW Only because it's an Event, otherwise please feel free to pass to PW @jilladams

[swirtSJW]

Product ownership iis spec'ed out here.
I think it is our source of truth. https://app.mural.co/t/departmentofveteransaffairs9999/m/vagov6717/1653588059793/7a260edabca9535d25d71fac1035c979261c223c?sender=u18053dffba72153d0f939228

[kmariepat-cityfriends]

A note was made in scrum that this card may be for PW instead

[jilladams]

Confirmed - @wesrowe FYI

[wesrowe]

@swirtSJW, has the cause been identified or was this the first time you heard of such an issue?

@stefaniefgray, this seems like it has probably been causing broken links for a while – is the behavior of adding an email as a CTA not very common?

[stefaniefgray]

@wesrowe This has definitely been an issue for a while and comes up every few weeks or so

[wesrowe]

@dsasser, I assigned to you for pre-refinement since it seems like drupal is doing the bad handling here.

[dsasser]

This isn't specific to the Event content type. Anywhere the linkit field widget is in use for a link field, we will experience the same result. I don't have a list on hand presently, but last count we had about 23 instances of this field widget spread across the CMS.

The Linkit module contains an "email" matcher that when used will auto-populate the "mailto:" prefix for an email address. See screenshots below.

The email matcher isn't in use today, but can easily be added to the default 'profile' here.

Additionally, the help text can be enhanced to conditionally show the mailto option by applying the patch from here.

One decision point that we need to address: do we want ALL instances of the linkit field to behave the same way? If so, we can apply the email matcher to the existing 'default' linkit profile. Otherwise, we will need to create/clone the existing default profile and add the email matcher there. And finally we would need to set the new profile on any fields we want email matching on. Depending on our response here, will not greatly affect the overall estimate, which I would guess is about a 3.

[jilladams]

Paging @timcosgrove and/or @ndouglas from a CMS Collab POV as FYI / in case you have opinions here.

[ndouglas]

I can't think of any reason we'd want to treat some field instances differently, but I might have a blind spot in my reasoning 🙂 IMHO add the matcher to the default profile as you suggested, @dsasser.

[wesrowe]

Thanks for this analysis @dsasser. So right now, anywhere an Editor adds an email address as an "external link" in Linkit, across all these 20+ instances, they create a broken experience for a Veteran. Is that right? If so, I don't see how it would do any harm to make it a proper, not-broken mailto link. So my answer to your first decision point is: Let's apply it to every Linkit instance.

I think improving the help text sounds like a good idea also. I'll update the ACs and we can review with Dave in a refinement or planning meeting.

[dsasser]

So right now, anywhere an Editor adds an email address as an "external link" in Linkit, across all these 20+ instances, they create a broken experience for a Veteran. Is that right?

I can't say this with 100% certainty because I haven't made connections from the linkit fields to the requisite frontend templates, but it is very likely. Fortunately it is easier to apply the change to all linkit fields globally than to create one-off profiles.

[jilladams]

From sprint 89 planning:

• DaveC question: should we allow email addresses in this field? Probably not. Instead: disallow in this field, and provide an alternate mechanism for managing Registrations that are not an email address.
• Refinement things to do:
  • Figure out with @stefaniefgray and @TroyA6 how we can assess how common this workflow is.
  • Think about what the editor workaround is for managing non-URL registration flows.
  • New paradigms may mean: CMS Collab Cycle

[wesrowe]

@stefaniefgray, we refined this with the UX team. A couple questions:

You said above this happens every couple weeks

1. What do you do when you see a broken link caused by an email address in CTA?
2. If you're asking Editors to correct, do they typically know how they would request RSVPs (or whatever action) using a proper url?
3. Is the link corrected quickly, before it impacts Veterans?

cc @aklausmeier @thejordanwood @cindymerrill

[stefaniefgray]

Hi @wesrowe -- thanks for refining it!

Question 1: What do you do when you see a broken link caused by an email address in CTA?

• I go in and edit the node, and add the 'mailto:' prefix.

Question 2: If you're asking Editors to correct, do they typically know how they would request RSVPs (or whatever action) using a proper url?

• After manually correcting the link, we typically reach out to them via Jira Service Desk and let them know "Hey, you've got to add the 'mailto:' prefix before email addresses."

Question 3: Is the link corrected quickly, before it impacts Veterans?

• Yes, if it's coming up on #content-broken-links then our team is aware and can fix it post-haste

[wesrowe]

Thanks @stefaniefgray – one of the options for improving this situation is to only allow URLs, per the intended design. I.e., add validation to reject email addresses. More questions!

1. Which CTA option(s) do Editors typically select when they use an email address as the URL? (register, apply, rsvp, more details)
2. Do you know what method you would recommend to an Editor for using the URL field for the use case(s)?

[wesrowe]

@stefaniefgray, just pinging you again on this.

@thejordanwood, is there anything else you need to know before starting on this?

cc @aklausmeier

[thejordanwood]

@wesrowe Nothing else from me. I'm ready to start this!

[stefaniefgray]

Wow, I'm sorry @wesrowe -- I typed this and never clicked "Comment" 🤦‍♀️

1. "Which CTA option(s) do Editors typically select when they use an email address as the URL? (register, apply, rsvp, more details)"
   Typically, Register or RSVP (but honestly, e-mail addresses ought to work for all selections, just in case)

2. Do you know what method you would recommend to an Editor for using the URL field for the use case(s)?
   At this time, I'd just recommend the "mailto:" workaround. It might help to maybe break it out into two separate fields, one where an email address could be used and one where a regular URL could be used?

[thejordanwood]

@wesrowe The design is ready for your review. The mockups can be viewed in the Call to Action tab of this Figma file.

@aklausmeier and @laflannery have approved this design.

I have a couple of notes on this and what's changing:

1. New experience: After the Call to Action dropdown, a new dropdown will appear that asks editors if they want to use a URL or an email address. The one they select determines which field appears after that. This will be the same experience if they select Register, Apply, RSVP, or More Details.
2. From Laura: We will want to make sure the focus follows the appropriate tab order when the new field is displayed.
3. Help text changes: This section was called “Register”, but I changed the name to “How to join” to make it more general, since the call to action dropdown also includes Apply, RSVP, or More Details. I changed some field labels and help text to reflect this.
4. I think we may need to change the wording on the "Registration is required for this event" checkbox to make it more general as well. However, I'm having a hard time actually seeing what this checkbox does. I don't notice any changes on the FE and can't tell if it's specifically tied to the Register CTA or all of the CTAs. Not sure if I'm just missing something here, or if an engineer would need to look into this more.

[wesrowe]

A gap in our understanding that need FE dev input:

We need to know how/if the "registration required" checkbox in the Event UI is used by the FE template.

Example:

• https://www.va.gov/outreach-and-events/events/61560/
• https://www.va.gov/outreach-and-events/events/61560/

The Event Editor checked the box for required, but I don't see anything in the FE that indicates that:

@chriskim2311 or @randimays, is it a pre-refinement (low-lift) activity to see whether the field from Drupal is being used in the template? If so, please check it out and comment here. Thanks!

[thejordanwood]

Closing this ticket. A new ticket has been made to find our if the "registration required" checkbox is being used anywhere.

[wesrowe]

Aaaand note: the question I asked FE engineers in the comment above is one of the ACs in the new ticket.