Alerts are often noisy and plentiful. Sorting columns by descending and ascending values in one click provides responders a simple way to find the newest or most severe alerts quickly.
This work supports the direction of the Alert Management product category.
Proposal
Utilize column sorting for the alerts page:
Here's a prototype showing how the column sort would work.
Ideally, all columns on the list view would be sortable. We can have one column be sorted by default, perhaps either start time or severity. The column that is sorted by default would show the sort arrow. The rest of the arrows would be visible on hover. Only one column could be sorted at a time.
Permissions and Security
Documentation
Documentation required, please add details to the new Alert Management docs.
Availability & Testing
What does success look like, and how can we measure that?
@sarahwaldner - I've updated this issue to reflect the decision to pursue column sorting. But, which column do we want to sort on by default? I was originally thinking start time, so the most recently started alert would show first. But, is that okay with you? Or, would you rather sort by severity?
I'm not sure. It doesn't look like the URL is changed with our current page sorting on error tracking so I wouldn't think that changing the URL would be necessary for the first version of column sorting. It might be a nice to have feature, in future. But, I wouldn't say that it's required for a first pass here. Not sure what your thoughts are on this, @sarahwaldner?
@ClemMakesApps - do we need to tackle the component before we can implement on the alert page? If so, should we note that as a blocking issue for implementing this feature?
On a related note, should I mark this as ready for dev since we have a design, or should we wait to do that until the component is built? Wasn't sure how to label this appropriately so everyone is clear on the current state :)
Yes, we will need to add the component to the component library first. I think @lauraMon was looking into this one in the other issue. I'll let her take it from here
FYI, I'm creating some issues to better keep track of what's going on. It's based on the way we broke down issues in 12.8 (with the a/b stuff, I really like that).
The sorting functionality is broken up into three issues:
When loading the page initially are you going to set the 'default sort'? This will allow you to update the UI with the default sort direction sort direction & call the Graphql API with this, rather than the backend setting the default.
Spotted this conversation so, adding a thought: I believe we were thinking of having the initial sort default to start time. Does that make sense to you all?
@ameliabauerly I just noticed the icon placement on the table Clement is pointing to in the screenshot above, and they are placing the icon to the left of the header. Would following that pattern work for this table as well?
Here's how it looks on the left:
Vs the right, where you're right, it looks like it's actually sorting the other column:
Doing this requieres no additional CSS since it's a prop on the table component, which is always a plus since it doesn't add ~"technical debt"
@lauraMon - hmm, I'm not sure why column sorting was implemented that way in CI/CD - maybe it was an old version of column sorting implemented before we had the feature actually designed? Since I didn't design column sorting, I feel like we should probably stick with the way @npost designed it, especially since what's been proposed will soon be the pajamas "official" design for sorting. But, I suppose we could check in with @npost on this question, since this was his design originally.
Nick, I don't understand the full details here from a technical POV but, it sounds like it's challenging to make sure the sorting arrow is 4px after the column header. What this means is that, in our current implementation, the sort arrow is quite far away from the column header of the column that's being sorted. Laura mentioned that having the sort arrow before the column header would require no additional CSS and wouldn't introduce any technical debt. How do you feel about this suggestion? Wanted to check in to see if you had strong feelings one way or the other, or in case you had had any thoughts/conversations around the placement of the icon that would be relevant here?
The original reason for arrow being after the heading is that the text doesn't move when hovering. This isn't the case when the arrow is in front.
However, the arrow being in front is definitely a better solution than being far away from the heading! I imagine the arrow in this format could be mistaken for another column's sort indicator.
If it makes implementation easier, I'm fine with the arrow in front. We just need to potentially refine any animations to counteract any jolts.
Great work on getting this implemented! I can't thank you enough!
Thanks @npost and @ameliabauerly! Perfect then, I will leave the arrow in the left (front?) for now, since there is waaaaay too much CSS involved in moving it.
So thankfully, the text won't move, but it will appear slightly to the right of where the text below starts. The CI/CD table deals with this by showing arrows in all states (the bootstrap default).
This is how the table would look:
If you'd rather we have a default icon, like the CI/CD table, let me know :)
The CI/CD table deals with this by showing arrows in all states (the bootstrap default).
Does this mean there are arrows on all sortable columns by default?
The only thing I'm noticing about having the arrows before the column header is that it impacts the alignment a bit:
The column headers are no longer left-aligned with the values. Could we make it so that the column headers are still left-aligned with the values and the arrows are a little to the right of both? OR, maybe we could have the sort arrow align with the values when it appears? Not sure which is best, but thinking we should align one of the two?