-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement expanded police contact information model in Drupal #16813
Comments
@davidmpickett I've been comparing Drupal with front end displays for non-clinical services in the wild. Can we use this opportunity to improve this experience? (If not in Drupal, perhaps FE) The When the editor has selected When the editor has selected |
I just tried replicating this and the Office Hours field wouldn't let me save a service with only an End time. It's possible that an early version of the module that powers this field didn't have this validation in place back when this particular service was last saved in 2022. So it seems like all new instances of this will validate correctly in Drupal. But could possibly add some defense against this on front end. |
So while this example definitely seems like a mistake, I don't know if we can say that having all days display Closed is always invalid. If a service is temporally unavailable (due to construction or staffing), this might be an effective way to communicate that. Also need to consider that the office hours field has to support data that migrates in from VAST, which may include facilities that are temporarily closed. The Office Hours module as is does not seem to have a validation option that checks to ensure at least one day has hours. We'd likely need to build some client-side validation similar to the alt text guidance if we wanted to prompt editors with a "are you sure this is always closed?" message. |
Definitely something we want to address on the Front End in Jordan's design. From a Drupal perspective we wouldn't want to make this field always required. In situations where there is only one Service Location having no 'Name of office or location' is perfectly fine. In theory we could look into having some kind of conditional validation in situations when there is more than one Service Location (approximately 1% of Services). Not sure how complicated that would be. I'll defer to @Becapa and @omahane on lift |
@thejordanwood FYA |
@davidmpickett I feel pretty strongly that we shouldn't be solving Drupal issues with visual design if Drupal is capable of additional guardrails that can be implemented with better UX strategy. I agree with your line of thinking of exploring conditional logic.
These additional use cases that are popping up are great at pushing us towards a better Veteran experience. |
It might be worth reframing this issue in a broader context. For instance, last year I closed this historical ticket after Jordan resolved this in the VBA design for Service Accordions. But the non-clinical services are a slightly different implementation, and the focus was adapting the FE to accommodate the existing Drupal model. Similarly, when @thejordanwood updated the design of the Drupal interface for Service Location, it was mostly in the context of adding new fields, rearranging existing ones, and improving help text. Investigating the full conditional logic of the content model wasn't really on the table. This might require a more expansive exploration than just being a part of one Police ticket. Some possible older tickets/epics to revisit: |
User Story or Problem Statement
Blocked by #16812
Description or Additional Context
Steps for Implementation
Step 1 - Add the term to the Service taxonomy
Step 2 - Create a new Display on a View
Here's an annotated screenshot of how the text fields in the Display will show up in the editorial experience
Step 3 - Update the Content Type
Acceptance Criteria
Team
Please check the team(s) that will do this work.
The text was updated successfully, but these errors were encountered: