Skip to content
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

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

Closed
srabraham opened this issue Dec 10, 2024 · 7 comments · Fixed by #1601
Closed

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

srabraham opened this issue Dec 10, 2024 · 7 comments · Fixed by #1601
Assignees

Comments

@srabraham
Copy link
Member

srabraham commented Dec 10, 2024

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
Copy link

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
Copy link

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
Copy link
Member Author

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

@srabraham
Copy link
Member Author

Actually, @kimballa, here's another suggestion.

I've been putting keyboard shortcuts throughout the system recently. What if we got rid of the auto-focus on the report entry box, but we made it so that you could press a button (e.g. "i" for insert) to jump down there for you?

@kimballa
Copy link

kimballa commented Jan 6, 2025

Maybe! Depends how "discoverable" the shortcuts are, I guess...?

Might be a good discussion item for tonight

@wsanchez
Copy link
Member

Yeah I was optimizing for adding more text, on the assumption that the metadata at the top was lower-priority stuff to fill in when convenient. Not married to it.

@srabraham
Copy link
Member Author

I've been pushing keyboard shortcuts more and more (indeed, there's even help modals for this now...just tap "?" on the incidents or incident page).

My inclination is to stop auto-focusing on the add entry box on page load, because it's quite annoying when it's not the user's intention to add more text. Instead, I could add a keyboard shortcut, like "i" for "insert", that would cause the window to focus down there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants