Figure out if the incident page's jump-to-incident-details feature is useful

[srabraham]

The incident page employs a ".focus()" call on page initialization that jumps the user down to the "Additional report text..." textarea. I wonder how often this behavior is desirable versus undesirable. Much of the time, I imagine that a user is just trying to view the top part of the page, and so it's weird for it to immediately scroll way down to the bottom. This is really a question for other Operators. See in this example video how on page load, we're taken down to the textarea.

Screen.Recording.2024-12-10.at.13.46.16.mov

[kimballa]

good question. Let me check with the others and report back. My own sense is torn between "fine as it is" and "actually, more annoying than not."

[kimballa]

tl;dr: I think it's OK to leave this as-is for now.

My own sense is torn between "fine as it is" and "actually, more annoying than not." I kind of feel like "fast updates to the faceted data" (summary / rangers / location / etc) mostly arrive at the beginning of the incident lifetime. The operator recording the incident is likely to have that tab continuously held open and scrolled to wherever is most convenient for them.

If an incident isn't really moving for a while and you want to declutter your workspace, you'll then maybe close the tab. Then you would re-open the incident under two conditions:

• Some additional "general info" about the incident arrives. You want to log that as a comment. Auto-scrolling to the bottom and focusing the comment box is actually a helpful shortcut.
• A "progress update" about the incident arrives. You want to advance the status through the state machine of open->dispatched->on scene->closed/hold. That dropdown box is at the top of the incident faceted data section. Auto-scrolling to the bottom is fighting you.

I can't really say for sure whether these are 50/50 likely, or whether "opening a dormant issue to do one of the above" leans more frequently to one side or the other. That said, after a quick check w/ the others, we think that if you're moving the state machine along, that's not as time sensitive and it's ok to hit home to scroll back up. Whereas if new info is coming in that requires free-text logging, starting with the textbox focused is helpful.

Two possible UI improvements that would make this current behavior even more acceptable / less controversial:

1. pin a <div> encompassing the faceted metadata section of the incident detail page (everything from the IMS # / state / priority line to the bottom of the Location box) with the position: fixed CSS modifier so that as you scroll down through the history log, the faceted metadata remains on screen at all times. Then you get the best of both worlds. "Attached field reports" probably doesn't need to be in the pinned section taking up space, since managing field reports is never time sensitive. If you're under pressure, that task always waits til later.

2. Allow state to be advanced directly from the dispatch queue -- possibly in bulk. (e.g., activate a checkbox next to one or more rows of the incident dispatch queue and use a dropdown menu button named "Set state to..." to select one of { open, dispatched, on scene, on hold, closed }.

If one or either of those were in place, this current behavior would definitely be just fine. (I realize this is easier said than done.) But even as-is, I don't think there's sufficient evidence to say we want to undo this current behavior.

[srabraham]

That's useful feedback about the scrolling feature. Thank you, Aaron! I'll ponder those suggested changes too!