Audit Events Not Visible By Default #205
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Website users may not know to check audit events for problems when they submit. I think that having audit events and comments both be visible instead of as tabs would make more sense. Collapse the audit events to a scrollable frame that is pre-scrolled to the most recent audit event at the bottom, and put the comments below or to the side.
Alternatively, include an icon indicating that there are new audit events.
Disagree, the audit history doesn’t need to be on display all the time. I assume you’re requesting this because the log is the only way to get validator information. My plan for that was when in certain states display the audit text at the top of the page as a banner for the most recent relevant event.
Can default to the audit tab if there are no comments as well.
Great, that completely addresses my concern with the audit event information being hidden.
How about the page remembers what tab the user was on and have every new page opened automatically have that tab selected?
I don't think that's enough since it doesn't guarantee that the important information is displayed by default. itzaname's suggestion of a banner for statuses requiring submitter action addresses the issue fully imo.
I implemented my idea into
2e98c5f5fbat the same time you commented that lol, but it can easily be removed when needed. I'll leave it be.Agree with @Quaternions comments.
Tabs are typically used for quick navigation between different views, and I’d expect users to switch between them frequently rather than settle on just one. Remembering the last selected tab across pages could introduce inconsistency in the user experience, especially in workflows where users expect a consistent starting point.
For example, imagine reviewing multiple submissions: you load one, check the comments, then the audit events. You open another submission, and it defaults to the audit events because that was your last selected tab. This can feel disorienting. As you continue reviewing, the tab order flips back and forth, adding variability without much value.
Remembering user preferences is definitely useful in some cases, like filters, sort orders, page size, or whether UI elements like sidebars are collapsed. But I’m not convinced tabs fall into that category here.
@Quaternions thoughts overall on remembering last tab?
@itzaname I agree with your above reasoning. Switch frequently, so no persistent tab.
@Quaternions Which event types should be highlighted for the user? I assume if status is in "changes requested" by the validator some validator event should surface. I don't know the submission flow well enough to know what needs attention.
I would say only two states:
My plan was to surface the validator errors like "CheckList: Model name must have snake_case: expected: bhop_glue, observed: bhop_Glue" on some element at the top of the page. What you wrote is much easier unless you wanna go with what I just mentioned.
Seems like a teach a man to fish moment. Teach them to review the log instead of bringing the relevant log to them.