Support Drupal editors in specifying lat/long using a pin/map UI element

[kevwalsh]

Update from 2024

• During Q3 quarterly planning we discussed that exploring this pattern will be valuable, but we're not quite at the point where we're ready to act.
• The lat/long feature would be useful to both the Events product and Facilities products. While this Epic was originally written with Events as the use case, this could also be piloted in the context of Vet Center CAPs, VAMC Mobile Clinics, or another product where Drupal is a source of truth for location data.
• Whatever product gets gets to a point where this feature makes sense as the next enhancement, this can be picked up and applied in that context.

What's not included in this epic (yet, but it could be)

• Discovery (with Dave) re: permutations for Events location info
• Editor research
• CMS design collab cycle re: CMS presentation, including a UI for non-admin CMS editors to override the location of the event (that would be handled by #9448
• Front-end design for single event pages, location presentation (if any changes)
• Front-end design of Veteran-facing tools for filtering events

  Background

User Story or Problem Statement

As a Veteran, I want to be able to filter by events by location (including online and in-person) so that I can find events I can attend and meet my goals for engaging with the VA.

As an event Editor, I want to accurately capture all the locations from which a Veteran can participate in an event (including online and in-person) so that Veteran-facing products can enable the Veteran experience based on locations.

Affected users and stakeholders

• CMS editors of Events
• Developers of Facilities, Public Websites

Hypothesis

We believe that the current Event location editorial experience has several limitations that will prevent Editors from providing optimal location information for Events.

• Hybrid Online/in-person events aren't possible – radio button UI.
• Editors who select VAMC facilities for an event (eg the Boston car show) know that this isn't specific enough, but their clarifying entries into the "building/room/etc" field require knowledge of the campus (eg "behind Bldg 4") and are not geo-locateable.

Assumptions

• Per VEO, some events will have multiple locations (eg, a townhall with multiple in-person viewing locations plus online)
• Accurate data is necessary to create an Events Near Me product iteration

(How will these assumptions be validated?)

Acceptance Criteria

• [ ] All existing non-virtual events have lat/long based on their editor-specified address OR the address of the facility that is specified by the editor.
• [ ] All future events get geodata upon node save
• [ ] Editors don't see the lat/long, but admins do.
• [ ] Multiple locations can be saved for an event, across online and in-person options
• [ ] Events with an online component/option provide clear information about how to attend virtually, and how to register if necessary

Change management triage

The change represented by this user story will:

• [ ] Be a site-wide change to appearance or key functionality (such as log-in process)
• [ ] Be a specific change that requires more than 30 minutes of work by a user to meet a publishing requirement
• [ ] Remove a piece of functionality (such as restricting editing functions, or “hardening”)
• [ ] Require action by some or all users by a specific deadline
• [x] Change the front end and be highly visible to the public
• [ ] Noticeable performance improvements (publishing speed, predictability)

If you selected an item above, open a new issue using the change management template.

If you did not select an item above, update issues/PRs in GitHub but don’t plan for change management.

Design principles

Veteran-centered

• [x] Single source of truth: Increase reliability and consistency of content on VA.gov by providing a single source of truth.
• [ ] Accessible, plain language: Provide guardrails and guidelines to ensure content quality.
• [ ] Purposely structured content: Ensure Content API can deliver content whose meaning matches its structure.
• [ ] Content lifecycle governance: Produce tools, processes and policies to maintain content quality throughout its lifecycle.

Editor-centered

• [ ] Purpose-driven: Create an opportunity to involve the editor community in VA’s mission and content strategy goals.
• [ ] Efficient: Remove distractions and create clear, straightforward paths to get the job done.
• [ ] Approachable: Offer friendly guidance over authoritative instruction.
• [ ] Consistent: Reduce user’s mental load by allowing them to fall back on pattern recognition to complete tasks.
• [ ] Empowering: Provide clear information to help editors make decisions about their work.

[jilladams]

@omahane are you working on this epic? Events are technically in Public Websites purview, so @wesrowe will be pushing along the product end of this, and our designer @fmccaf1 is working on UI /UX related things. Wondering if you have technical work in flight already, and if so, if we need to hand that off or if you have capacity to keep going with it.

[JQuaggles]

@wesrowe / @jilladams / @EWashb What team owns this Epic? While I understand all teams are impacted/may be involved, does PW own this or does Sitewide CMS own this now?

[wesrowe]

Our UX researcher/designer Florence worked on it a bit before PTEMS. Recently I brought it up with Dave C and I believe he said it should go to Sitewide CMS – it seemed a little arbitrary but also it needs CMS-side design, ie Blake Organ, who sits with SW-CMS.

[jilladams]

This did come up in the Q1 goals conversation and Dave said: maybe PW / maybe Sitewide CMS. Seems like Erika / Wes / Dave should get together and work out who should own.

[EWashb]

I just saw this...yes, it was said that the CMS team should look into this as a very low priority Q1 initiative @JQuaggles

[EWashb]

This was determined to not be a priority for the CMS team during Q1 2023

[aklausmeier]

@EWashb @mmiddaugh FYA Public Websites has decided to pull this in as a UX priority.

[davidmpickett]

@Agile6MSkinner I'm replying to your question about closing a specific ticket with a comment on the parent epic.

I just added a brief update to the top of the epic and retitled it to reflect our most recent conversation about it at the onsite in June. I think that in the interest of cleaning up the board, this epic and the remaining tickets under it could be closed. Given that this work didn't make the cut for Q3 priorities, I don't think this idea will see action for a few months minimum.

If anything, some of the context about this concept could be moved into product documentation about possible future features. Possibly in the mapbox folder under Facilities? I leave it to you, @FranECross and @mmiddaugh to decide how best to leave a breadcrumb trail back to this.

[aklausmeier]

Another alternative to consider is to leave this on the CMS board since the functionality could be across multiple CMS products.