Fatality details page: create Victims card #1892

roseeichelmann · 2025-11-07T19:34:30Z

Associated issues

Closes cityofaustin/atd-data-tech#24973

Testing

URL to test:
Local

Steps to test:

Start up locally, apply migrations & metadata
Go to Fatalities tab, open up different fatality details pages and see the new Victim card.
Should only show victims that had fatal injuries for now
Restraint used should only be shown where applicable -- ie. not for peds or cyclists
Same for person type to the right of their name -- shouldnt be shown for cyclists or peds bc thats already specified by the Unit Type
Heres an example of a page with multiple Units and Victims http://localhost:3002/editor/fatalities/20732264
Use the unit types filter on the list page to check out the Victims card for different types of units (Vehicle, motorcycle, pedestrian, etc)

Ship list

Check migrations for any conflicts with latest migrations in main branch
Confirm Hasura role permissions for necessary access
Code reviewed
Product manager approved

roseeichelmann · 2025-11-10T18:30:12Z

editor/components/FatalityVictimsCard.tsx

+                          </span>
+                          {victim.prsn_type_id !== 3 && // pedalcyclist
+                            // Dont show person type for cyclists or pedestrians bc its redundant
+                            victim.prsn_type_id !== 4 && ( // pedestrian


hardcoding ids makes me nervous bc will CRIS ever change this? i think this is the best option though 🤷

Agreed that there's nothing we can do about future CRIS breaking changes. One thing that could help future devs is to isolate the magic numbers outside of the render code. E.g. in an isPedestrian() and isCar() function 🤷

roseeichelmann · 2025-11-10T18:30:27Z

editor/components/FatalityVictimsCard.tsx

+                          // Only show restraint field for cars
+                          unit.unit_desc_id === 1 && // motor vehicle
+                          unit.veh_body_styl_id !== 71 && // motorycle
+                          unit.veh_body_styl_id !== 90 && ( // police motorcycle


hardcoding IDs again

thanks for including the type in comments next to the hardcoded IDs.
tiny typo in motorcycle for id 71

johnclary

Rose, this is looking good. I am requesting changes for the person age/ethnicity/sex formatting.

johnclary · 2025-11-11T16:30:29Z

editor/components/FatalityVictimsCard.tsx

+                          </span>
+                          {victim.prsn_type_id !== 3 && // pedalcyclist
+                            // Dont show person type for cyclists or pedestrians bc its redundant
+                            victim.prsn_type_id !== 4 && ( // pedestrian


Agreed that there's nothing we can do about future CRIS breaking changes. One thing that could help future devs is to isolate the magic numbers outside of the render code. E.g. in an isPedestrian() and isCar() function 🤷

johnclary · 2025-11-11T16:42:59Z

editor/components/FatalityVictimsCard.tsx

+                      </div>
+                      <div className="mb-1 d-flex w-100 flex-column">
+                        <span className="mb-2">
+                          {victim.prsn_age} YEARS OLD -{" "}


Looks like we need some handling for when any of age/sex/ethnicity are missing. I think we can exclude any component when it is null, "UNKNOWN", or "AUTONOMOUS".

What do you think about this? 👇

Should be "HISPANIC MALE" . I'm not sure if we want to default to an UNKNOWN name in this case. I assume we will leave it up to VZ team to do so, but I'll check with them.

This should be "MALE", with "YEARS OLD - UNKNOWN" hidden

This should be "33 YEARS OLD - MALE"

Why exclude people categorized as "Other" ethnicities?

I guess I think "OTHER MALE" and "OTHER FEMALE" is an odd way to describe someone vs not mentioning their ethnicity at all.

Tbh, I think my preference would be that we only show victim age and not sex and ethnicity. The CRIS/EMS ethnicity disagree very, very often (esp hispanic/white/asian), and listing "male" and "female" reads as clinical and dehumanizing to me 😕

I like only showing age and not sex and ethnicity especially since I believe ethnicity is not self reported and is what the person filling out the form is saying.

I agree that OTHER FEMALE is odd, one way is to put commas between the identifiers, WHITE, MALE. I questioned ignoring OTHER because it's not that it's necessarily unknown (though I'd guess often it is) and it feels off to me to exclude mention of an ethnicity just because it doesn't fit into the arbitrary 4 main ones CRIS has chosen.

I agree w yall that the current formatting feels off for showing "Other" or "Unknown". I will say that while i get what john is saying about it being clinical, not including sex or ethnicity on the page at all feels like obfuscating information that we already show in other parts of the app and i think mary expects to see those fields here?

I think if we keep the sex/ethnicity identifiers we should maybe put them each on their own line or something and prepend w the label so like --

Ethnicity: Other Sex: Male Ethnicity: Unknown Sex: Unknown

I think w the above formatting we should still show Unknown and Other bc they still provide some info

Thanks for that feedback. I messaged Mary to see how she currently handles when these descriptors are unknown.

For now, let's just hide/exclude sex and ethnicity if they are other, unknown, or null.

I did quickly mock up breaking these into separate lines, and I don't like. We can revisit this for more polish later.

I dont mind the separate lines in ur lil mockup but im down to circle back for polishing later... im still of the mind that we should show as much information as possible, including "Other" for ethnicity

i'm way late here but i agree that separate lines might not be so bad, but I love that y'all are looking for feedback from Mary. I've really enjoyed y'all's discussion about being able to replace some of the prep work of the monthly reporting with this view. ❤️

johnclary · 2025-11-11T17:16:21Z

editor/types/peopleList.ts

  drvr_city_name: string;
-  drvr_ethncty: LookupTableOption;
-  prsn_ethnicity_id: number;
+  drvr_ethncty?: LookupTableOption;


Glad to see you catching this typeError waiting to happen!

I haven't written an issue for this, but I'd really like to go through all our types and make every property that comes from Hasura optional (?) 😅

chiaberry · 2025-11-11T20:15:54Z

editor/components/FatalityVictimsCard.tsx

+                          // Only show restraint field for cars
+                          unit.unit_desc_id === 1 && // motor vehicle
+                          unit.veh_body_styl_id !== 71 && // motorycle
+                          unit.veh_body_styl_id !== 90 && ( // police motorcycle


thanks for including the type in comments next to the hardcoded IDs.
tiny typo in motorcycle for id 71

chiaberry · 2025-11-11T20:20:41Z

editor/components/FatalityVictimsCard.tsx

+                      </div>
+                      <div className="mb-1 d-flex w-100 flex-column">
+                        <span className="mb-2">
+                          {victim.prsn_age} YEARS OLD -{" "}


Why exclude people categorized as "Other" ethnicities?

chiaberry · 2025-11-11T20:25:54Z

editor/components/FatalityVictimsCard.tsx

+                        {victim.injry_sev?.label && (
+                          <span
+                            className={`${getInjuryColorClass(victim.injry_sev.label)} d-inline-flex align-items-center justify-content-center px-2 py-1 rounded `}
+                            style={{ minWidth: "fit-content" }}
+                          >
+                            <small>{victim.injry_sev?.label}</small>
+                          </span>
+                        )}


will this card ever expand to include other injury severities? If not, wondering why include the severity label here

Yeah, theres a future enhancement to have an All people toggle or something like that, that will show all people that were in the crash

editor/components/FatalityVictimsCard.tsx

frankhereford

This is great Rose -- I have just two tiny layout observations, but otherwise, this implements the spec so well. Clean code, runs good! 🚢 🚢 🚢

editor/components/FatalityVictimsCard.tsx

frankhereford · 2025-11-24T16:46:08Z

editor/components/FatalityVictimsCard.tsx

+              const unitYearMakeModel =
+                `${unit.veh_mod_year || ""} ${unit.veh_make?.label || ""} ${unit.veh_mod?.label || ""}`.trim();
+              return (
+                <ListGroupItem key={unit.id}>


It's not this line of code in particular, but the content contained below this element -- I think the left alignment can be adjusted to line these up to match the spec. Maybe the middle line can be nudged up to be a little bit closer to the first line based on an eyeball of the image in the issue too. I know this isn't very clear - LMK if I can help explain myself better. Thank you!

BTW - if you look at the image in full rez, there is a little red ruler line to help illustrate what i'm trying to say.

Thanks, Frank, for giving this the mag treatment 🙏

Our current expectation (pending feedback from Mary) is that the name field never be null, or we establish a default text to place in its position, so at the moment it's ok that the DRIVER OF ... text is slightly indented by the margin of the empty victim name <span>.

Beyond that, I think we have a missing ListGroup wrapper for the victim names—I'll comment on that below. I'll double check for extra spacing sneaking in but that should make the indentation consistent with our design system.

I kind of like the way i have each victim indented to the right under the unit and did that on purpose bc i think it helps grok all the text, esp when theres multiple people and units. but i can add that missing ListGroup wrapper if you would prefer it to look like the mockup, now im not sure what i like more 🤔

editor/components/FatalityVictimsCard.tsx

frankhereford · 2025-11-24T16:53:12Z

editor/components/FatalityVictimsCard.tsx

Just stepping back to look at this file holistically, Rose -- it's just real fine. Super smart and reasonable component boundary, clean interface in terms of props and the typing, and your mastery over bootstrap styling and general coding legibility are really shining.

I have some comments below that feel very much little nit-picky things, and as I submit those to you, I wanted to also acknowledge that they are tiny nothings in the big picture of your work's very high quality.

editor/components/FatalityVictimsCard.tsx

johnclary · 2025-11-26T18:01:06Z

editor/components/FatalityVictimsCard.tsx

+                        <div className="d-flex align-items-center">
+                          <span className="fw-bold me-2">
+                            {victim.prsn_first_name} {victim.prsn_mid_name}{" "}
+                            {victim.prsn_last_name}


would you add some conditional formatting to make sure we don't have empty spaces filling if any of the name parts are missing? I dunno if it makes sense to reuse this formatter function.

do you mean if an empty string is saved in there? bc i tested w null name parts and it doesnt create empty spaces 🤷

johnclary · 2025-11-26T18:08:32Z

editor/components/FatalityVictimsCard.tsx

+              const unitYearMakeModel =
+                `${unit.veh_mod_year || ""} ${unit.veh_make?.label || ""} ${unit.veh_mod?.label || ""}`.trim();
+              return (
+                <ListGroupItem key={unit.id}>


Thanks, Frank, for giving this the mag treatment 🙏

Our current expectation (pending feedback from Mary) is that the name field never be null, or we establish a default text to place in its position, so at the moment it's ok that the DRIVER OF ... text is slightly indented by the margin of the empty victim name <span>.

Beyond that, I think we have a missing ListGroup wrapper for the victim names—I'll comment on that below. I'll double check for extra spacing sneaking in but that should make the indentation consistent with our design system.

johnclary · 2025-11-26T18:11:05Z

editor/components/FatalityVictimsCard.tsx

+                      </span>
+                    </div>
+                  </div>
+                  {unitVictims?.map((victim) => (


Since we're starting a new list here, I think we want to wrap the vicitm list items in a <ListGroup variant="flush">. I'm not seeing any noticeable visible change from it so it's just semantics.

mateoclarke

The example crash you linked with 5 fatalities so very depressing. But the purpose of this Victims view is to humanize these individuals. All the thoughtful convo about how to do that with limited and inaccurate data is refreshing. Thanks for leading this effort Rose!

mddilley

Tested locally, and everything looks as described in the test steps. This page is going to help the VZ team represent these people and their stories so much. ❤️

roseeichelmann added 12 commits November 6, 2025 15:34

add fatalities victim card component

46e07c9

add permissions to restraint col

ff6fe69

add relationship to rest lookup

a94c29f

add fatalityVictimsCard w prop

bc27e27

creating the fatalityVictinsCard

07c4266

add restraint to query and PeopleListRow type

14ab44d

only show person type when applicable

f7524b8

remove console log

0ee9434

add border

83f1d4e

soemtimes gender or ethnicity can be null

f511031

make typescript happy

66718e7

clarifying comments

85ec1cc

roseeichelmann commented Nov 10, 2025

View reviewed changes

roseeichelmann requested review from chiaberry, frankhereford, johnclary, mateoclarke, mddilley and tillyw November 10, 2025 18:30

johnclary requested changes Nov 11, 2025

View reviewed changes

chiaberry reviewed Nov 11, 2025

View reviewed changes

roseeichelmann changed the title ~~Fatality details page: create Victims card #24973~~ Fatality details page: create Victims card Nov 12, 2025

dont show age when null, fix typo

451b2b0

frankhereford approved these changes Nov 24, 2025

View reviewed changes

chiaberry reviewed Nov 25, 2025

View reviewed changes

editor/components/FatalityVictimsCard.tsx Show resolved Hide resolved

johnclary reviewed Nov 26, 2025

View reviewed changes

roseeichelmann requested review from chiaberry and johnclary December 1, 2025 21:12

check if valid label

56812f8

mateoclarke approved these changes Dec 13, 2025

View reviewed changes

mddilley approved these changes Dec 23, 2025

View reviewed changes

Fatality details page: create Victims card #1892

Are you sure you want to change the base?

Fatality details page: create Victims card #1892

Conversation

roseeichelmann commented Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Associated issues

Testing

Ship list

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johnclary left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johnclary Nov 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mddilley Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

frankhereford left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roseeichelmann Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

roseeichelmann commented Nov 7, 2025 •

edited

Loading

johnclary Nov 26, 2025 •

edited

Loading

mddilley Dec 23, 2025 •

edited

Loading

roseeichelmann Dec 1, 2025 •

edited

Loading