Propose another organisation for the filter buttons of the conda-forge status dashboard page
Opened this issue · 5 comments
Where should the content be changed?
The content that has to be changed will be in src/pages/status/migration/ in index.js.
What should be changed?
This issue is opened from a suggestion made in this comment #2239 (comment) by @GabrielaVives
[...] the filters could be organised differently:
- Align all the filter buttons on the left
- Reduce the space between each button
- They are organised in the order of the progress bar above, but I don't think that brings any value because there is no visual correspondence. I would rather organise them based on their usage: for example, put the "done" button last.
Is it possible to please change the labels from bug to enhancement ? Thanks.
cc @h-vetinari (as IIRC you had preferences on how feedstocks are sorted in migrations)
I'm not a UX guy, so I'll let folks here come up with what they think is best, but my personal opinion is that
-
the correspondence with the progress bar is good (it got substantially weakened by the recent changes in colour scheme; compare this old image from #2137)
-
I don't see how alignment of the filter buttons on the left would help the overall usability. It seems to me they would further eat into the limited horizontal space, which is already blowing up the page lengths (for displaying all the children).
But ultimately I don't care how these things look exactly, what I care about are work-flows related to managing migrations:
- what are the current bottlenecks (--> sort by number of children, allow filtering on the various states)
- what's happening with a specific feedstock (currently only possible with "CTRL+F", which finds many false positives where it appears as a child, especially if "Done" is unfolded)
- Figure out why a job failed (display error, link to logs)
- Easily go to affected feedstock (currently there are only links for feedstock in PR or done)
One thing I've wished for in the past that it would be possible to hide the "immediate children" for all feedstocks that are under "Done" (as they're all necessarily already found in one of the other categories anyway, and just eats up so much space that "Done" becomes almost useless). Not sure how easy or hard that would be.
PS. Thanks for the ping @jakirkham 🙏
- I don't see how alignment of the filter buttons on the left would help the overall usability. It seems to me they would further eat into the limited horizontal space, which is already blowing up the page lengths (for displaying all the children).
I may have not been clear about what I meant when saying "aligning to the left". I didn't mean having them in a horizontal column on the left, but just aligned to the left of the page instead of being centered. The two main reasons for this are:
- Familiarity and consistency with standard design practices
- Scalability and maintenance of layout: by aligning the filter buttons on the left, we're setting up the interface for future growth and adaptability. If we later need to add additional filters, doing so will be simpler, as new elements can be added next to existing ones without the need to rearrange the entire button group or disrupt the page layout. This is much more efficient than centering them, where adding a new button would mean re-centering the entire row of buttons, potentially disrupting the visual flow of the page.
The core of my suggestion is about improving how the filtering buttons are arranged. I believe aligning them with the progress bar doesn’t add significant value for users.
1. Clarity of Labels vs. Visual Cues
The filter buttons are already clear thanks to their labels. Even if the progress bar were not there, users would easily understand what each button represents. For example, the "In PR" button explicitly indicates jobs that are in the "PR" state. The meaning is self-evident from the text alone, following the principle of clarity in UX, which emphasizes that text should clearly communicate a function without needing extra visual reinforcement. Adding a colored progress bar doesn’t really help users better understand these labels.
2. Improving Information Hierarchy
The real benefit of the progress bar seems to be showing the percentage of jobs in each state. However, this information could be more useful if displayed directly within each filter button. For instance, adding a "n/total of jobs" indicator inside each button could provide users with instant feedback on how many jobs are in each status. This leverages the principle of visibility, where users can see relevant information in the same place where they take action, reducing cognitive effort.
3. Rearranging Buttons Based on User Priorities
Regarding the button arrangement, I suggest ordering the filters based on how frequently users need them. In UX, this ties into the principle of frequency of use, where the most commonly used elements are placed in the most accessible positions. From what I understand of the workflow, users are primarily interested in jobs with errors or jobs awaiting review (like "error" or "In PR"), so it makes sense for those filters to appear first. Filters for completed jobs ("Done") are used less frequently and can appear later.
4. Reversing the Progress Bar for Usability
Similarly, I think the progress bar could be reversed. By placing the most critical states first, such as errors and jobs needing attention, and placing "Done" jobs last, we align the design with the principle of task relevance. This helps users focus on what matters most, particularly urgent or incomplete tasks, which improves the overall flow and efficiency of the interface.