Closed xiongjaneg closed 5 months ago
Notes from quick convo @mmiddaugh and I had this week:
Updates from 16th minute discussion in scrum today:
- Short names proposal might not be best thing to broach with VBA national stakeholders immediately while reengaging them in project
@mmiddaugh reported that the first reengagement meeting with VBA stakeholders went really well, so maybe there's still a chance that we would have trust and buy in from them to work on this
- Need to find a time to talk about technical options with engineering. Can we use something for URL and Breadcrumbs while having something different for H1? What concerns does that raise?
From Steve - It is possible to have 2 fields on a node, and have those fields power different aspects of the iA (breadcrumb/URL) and another field that is the H1 (node title). If we are going to have 2 different strings, they should be 2 different fields, vs. trying to programmatically process a single field to get 2 different strings.
cc @jilladams for visibility
Noting that @thejordanwood created designs to account for complex VBA names: https://www.sketch.com/s/891d33ae-152d-471c-ab5d-9aedf89cf6ff
VBA naming proposal jan 17.xlsx Static copy of Sharepoint doc for ease of access
Other notes from Oct. 31 16th minute: Another aspect: distinction between H1 / breadcrumbs.
Can a short slug for URL / longer full title H1 be a thing?
IA governance would need to sign off BUT: a name is a name, so they can’t really speak to that. IA has supported shorter URLs if possible.
Technical problem re: whether / how we can pull off:
Full H1 Shorter URL Specified breadcrumb All breadcrumbs are in Drupal, so this is in Drupal camp to resolve.
Updated static copy of spreadsheet. Now with better colors and sorting! VBA naming proposal jan 18.xlsx
Imagine a future state in which a benefit location co-located within a medical facility or Vet Center could be listed as a service location within the service accordion on the VAMC or Vet Center page. Example: VA Regional Benefit Satellite Office (at Des Moines VA Medical Center) is listed as a service location for Returning service member care on Des Moines VA Medical Center. Is there anything we could/should do now from a content model/data structure perspective to set us up better for that future?
Imagine a future state in which a benefit location co-located within a medical facility or Vet Center could be listed as a service location within the service accordion on the VAMC or Vet Center page. Example: VA Regional Benefit Satellite Office (at Des Moines VA Medical Center) is listed as a service location for Returning service member care on Des Moines VA Medical Center. Is there anything we could/should do now from a content model/data structure perspective to set us up better for that future?
This is pretty much the opposite of how the content model is currently structured and there may be a point in the future where we basically need restructure everything to make Service Locations the focal point rather than Facilities. (I like to think about it like when you realize a sock is inside out and you need to pull it through itself to hide the seams. It still works as a sock either way, but one way is slightly more comfortable and stylish.)
Current
Right now Service Locations are Paragraph Types rather than Content Types. This means that a Service Location doesn't really exist on it's own independent of the Facility Service it is attached to. It makes is very hard for a Facility Service (Returning service member care at Des Moines VA Medical Center) to reference a Service Location attached to a different Facility Service at a different facility (Returning service member care at VA Regional Benefit Satellite Office at Des Moines VA Medical Center).
We do have a field on VBA Facilities for Shared VHA Location that could theoretically allow queries to go up, over, and down to pull this information from a Service Location. This is definitely something we want to preserve, but we aren't currently using it to power anything.
I do think that there is a future where we create a "Reusable Service Location" Content Type similar to how Public Websites has a distinction between Reusable Q&As (Content Type) and Page-specific Q&As (Paragraph Type).
Another possibility is that we update Service Location fields like hours and address to have "Choose a different facility to reference" instead of only referencing the facility that they are nested under.
Is there anything we could/should do now from a content model/data structure perspective to set us up better for that future?
@mmiddaugh I realize I just said a lot of words without actually answering your question😅 Here's a succinct actual response:
This future is exactly one of the reasons we are putting so much time and energy into having VAMCs and VBA both Service Location. By storing the most vital and reusable elements in the exact same format it will make cross-pollination possible. By contrast, Vet Centers don't currently use Service Locations on their Facility Services, so a future where a VBA Service Location is shown on a Vet Center Service is further off.
Dave has another ticket address the long names with "and" vs. "at." That ticket will follow this spike.
Yes, #11628
We need to make a decision on the exact way VBA Regional Offices and Satellite office will be named on the website & the technical implementations across all places the data is stored (Sandy's DB, Drupal, Lighthouse)
Are we keeping the word regional in the name of all satellite offices? Even though it it dilutes the distinction between regional and satellite offices?
Chatted with @mmiddaugh about proposing the official label of satellite offices
She will discuss with VBA stakeholders
VBA naming proposal has been updated with columns for URLs
End of sprint update - 5 points completed. 8 points remaining for next sprint. I will also need some of that capacity to come from Drupal & Front End. @xiongjaneg we can chat more in our sync tomorrow
Meeting to discuss initial draft of plan with engineers scheduled for 2/14
VBA naming proposal - feb 14 2024.xlsx Static copy of the sharepoint spreadsheet for convenience
Updated ACs in this ticket based on Dave's end of sprint 103 update. @davidmpickett I'd like to try to follow the UX paradigm we've used on other UX tickets, to spell out what we can commit to per sprint in terms of ACs / points. I think that'll help us get a grip on whether we're overplanning for you.
Based on conversations on 2/14 and subsequent discovery, I am proposing implementing Shared Location as the first thread of the renaming effort.
Non-VA location official name
, Shared VHA location
, and Official name
Non-VA location official name
and Shared VHA location
to match reality / official name
official name
unless it contains ontologically inaccurate information. This is primarily an additive audit, so we shouldn't be removing any information.
official name
official name
Non-VA location official name
, Shared VHA location
that is not reflected in official name = don't change official name
official name
, but it's not vital for the sake of this ticketShared VHA location
- get the title of the referenced node (will be a VAMC or Vet Center) = [shared location]We need to specify a geographic region prefix for Satellite Offices. The VBA naming proposal contains extrapolated Regions for all Satellite Offices.
@mmiddaugh based on our conversation today, I started a draft of an Analytics Request with URLs for the Regional Offices that are part of the MVP and have a name that won't change (all of them except Honolulu and Anchorage). That seems like a good batch to focus on for staging review and more analytic request can come later in the process.
@xiongjaneg or @jilladams, I could use some help with filling out the other aspects of that Analytics Request.
https://github.com/department-of-veterans-affairs/va.gov-team/issues/76780
I have a pull request for updating the naming schema documentation. https://github.com/department-of-veterans-affairs/va.gov-team/pull/76781
For the engineering conversation, there are four locations which have shared vha locations which are not reflected in the name
Current name | vha shared location id | vha shared location name |
---|---|---|
White River Junction VA Regional Benefit Office | vha_405 | White River Junction VA Medical Center |
Cheyenne VA Regional Benefit Office | vha_442 | Cheyenne VA Medical Center |
Muskogee VA Regional Benefit Office | vha_623 | Jack C. Montgomery Department of Veterans Affairs Medical Center |
San Diego VA Regional Benefit Office | vha_664BY | Kearny Mesa VA Clinic |
and a few examples with non-VA shared locations which are not reflected in the name (one is an MVP location) Current name | non-VA shared location name |
---|---|
Cleveland VA Regional Benefit Office | Patrick V. McNamara Federal Building |
Detroit VA Regional Benefit Office | Anthony J Celebrezze Federal Building |
St Paul VA Regional Benefit Office | Henry Whipple Federal Building |
Albuquerque VA Regional Benefit Office | Dennis Chavez Federal Building |
The rule about having either a shared non-VA location or a shared VA location but not both is not accurate: Manila VA Regional Benefit Office at U.S. Embassy in Manila is associated with a non-VA building (U.S. Embassy in Manila) as well as a shared VHA location (VA Manila Outpatient Clinic). Both are true: the Clinic is on the Embassy campus.
Questions
@jilladams @xiongjaneg Re the last AC
Submit Collab Cycle Analytics request per Collaboration Cycle for Sitewide Facilities VBA Regional Offices va.gov-team#46029
Closing based on notes in comments and the follow tickets that are created / queued. If anyone has concerns please feel free to flag.
Problem Statement
The official names of VBA facilities can be very lengthy. eg:
Previous conversation with CAIA led us to look at ways to shorten VBA facility names so we don't end up with incredibly long URLS / H1s / breadcrumbs for users.
We developed designs for splitting off Shared Location into text associated with the H1 so it wouldn't clog up the H1/URL/Breadcrumb.
VA Regional Benefit Offices
This approach will work very well for VA Regional Benefit Offices which almost always have a unique region as part of their official names.
VA Regional Benefit Satellite Offices
However, it won't work as well for VA Regional Benefit Satellite Offices, since they don't currently have any unique identifiers aside from their shared location:
We may need to specify a REGION prefix for Satellite Offices. The VBA naming proposal contains extrapolated Regions for all Satellite Offices
Edge Cases
Only distinguished by Shared Location
Even with the addition of a region prefix, there are some instances where that might not be enough to differentiate the urls for satellite offices
Do we keep these instances at the long URL of the current official name?
Do we put the shared location up first in the URL?
Though that then just begs the question why these aren't structured as sub facilities:
Shared Location is actually a Region
Region may need to include city and state/territory
Do we need style guidance for military bases?
Next steps
We need to make a decision on the exact way VBA Regional Offices and Satellite office will be named on the website & the technical implementations across all places the data is stored (Sandy's DB, Drupal, Lighthouse)
Documents
Acceptance Criteria - Sprint 103 (5 points)
Acceptance Criteria - Sprint 104 (8 points)
Submit Collab Cycle Analytics request per https://github.com/department-of-veterans-affairs/va.gov-team/issues/46029Max will finish VBA analytics ticket, add any comments to the collab cycle analytics request, and then tag Jane to submit the request.