-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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." |
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:
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 Two possible UI improvements that would make this current behavior even more acceptable / less controversial:
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. |
That's useful feedback about the scrolling feature. Thank you, Aaron! I'll ponder those suggested changes too! |
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? |
Maybe! Depends how "discoverable" the shortcuts are, I guess...? Might be a good discussion item for tonight |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: