This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
The environment picker does take a long time to load ALL the environments
What is the expected correct behavior?
The environment picker does NOT take a long time to load the first 20 environments. The dropdown works with infinite scrolling, where when a user scrolls to the bottom of the first 20 environments, another 20 are retrieved
Design
Possible fixes
frontend update the environment picker/request to only request 20 policies at a time
and implement infinite scrolling
@aturinske If don't get it wrong, @bwill's suggestion is to add infinite scroll to the dropdown component as a component change, right? This will be a technical change to all dropdowns across the site? In that case, we need to double-check with @jeldergl and @tauriedavis this is ok for them.
@cam.x , I interpruted @bwill suggestion as to add infinite scrolling only to environment picker dropdown component, which is possible (e.g. here). My plan was to only apply infinite scrolling to our dropdown component.
This will be a technical change to all dropdowns across the site?
I was not planning on it. While I think having an infinite scroll option for the dropdown component would be nice to have, I do not think it is necessary at this time. Also, I think it may be better as a separate pajamas component (i.e. gl-dropdown-infinite, that name actually sounds really cool), but I do not know much about that, so I will leave it to the experts (@jeldergl and @tauriedavis ) to determine if that is a component worth having.
@cam.x could we consider a "load more" option instead of infinite scroll? I think it's a more opt-in and accessible approach that helps the user understand there's more loading, rather than items just continuing to appear on scroll with no expectation of how long that could go on.
@cam.x yes, something like that would be great. I'd work on the spacing though so that it's equal above and below the action.
What type of behavior do you see happening when this is clicked? Would there be a skeleton loader or spinner? Would the results load in place of the button (preferred) or scroll to the top of the new set?
@tauriedavis I think your suggestion is opposite of what's needed here. With search the goal is to narrow down, with the load more it helps solve the performance issue mentioned above so that all don't have to load initially.
That is true, however, for assinees we don't load all options immediately. What is the difference with that pattern compared to what is needed here? In both circumstances, we are limiting what is seen in order to improve performance I believe.
however, for assinees we don't load all options immediately.
Good to know! How are those loaded? I hadn't thought about it before, but when scrolling there and no other options load it makes me think that those are the only people I can assign.
What is the difference with that pattern compared to what is needed here?
I wasn't aware that not all options load right away. Based on that, I think the pattern you suggested could work. I still wonder about the UX of only loading a handful of options without users knowing there are more and the only way to see them is to search.
Good to know! How are those loaded? I hadn't thought about it before, but when scrolling there and no other options load it makes me think that those are the only people I can assign.
For issues it seems to list current user and then maybe project members sorted by name (would be better to list participants but thats a separate discussion). Otherwise, you must search. Since you haven't noticed before, I wonder if you just always search and never need to scroll (or load more)?
What type of behaviour do you see happening when this is clicked? Would there be a skeleton loader or spinner? Would the results load in place of the button (preferred) or scroll to the top of the new set?
I think a spinner and after it loaded, it will scroll to the top of the new set. For how much it will load each time, I will ask the devs.
For @tauriedavis 's suggestion, I like the idea of adding a search. But without the loading option, it might not work as well as the users list example. For the user's list, it is normal I remember my teammate's name. But here we are listing environments, I don't expect users to remember the environments name, it is more possible they will scroll to find out what they need first and maybe with the help of search to narrow down.
For the user's list, it is normal I remember my teammate's name. But here we are listing environments, I don't expect users to remember the environments name, it is more possible they will scroll to find out what they need first and maybe with the help of search to narrow down.
That is fair and a good consideration 👍 If users don't know what to initially search for then seeing options is helpful.
We're experiencing this issue as well. Apparently the list is sorted by creation date and takes the oldest 20. I just had to manually delete 40 stopped review environments in order to have the most important newer ones in the list.
But for new review environments we can not check the logs as this will soon hit the limit again.
If an pod is directly clicked at under Deployments-Environents it takes you directly to the Logs. This does also not work because it's missing in the list.
@cam.x I have a few design questions. I created the dropdown and it is slightly different to your mock and I wanted to ask you about it.
Proposed dropdown
WDYT about not explicitly showing the checkboxes to match with other dropdowns in the app?
Page
Dropdown
Vulnerability Report Filters
Sidebar - Assignees
Sidebar - Milestone
WDYT about having the Load More button in the middle of the dropdown to better signify that it is a button? It would be similar to how "more" buttons at the bottom of lists are presented in the app today
WDYT about not explicitly showing the checkboxes to match with other dropdowns in the app?
Because in Pajamas new styles, what we have in Figma files(our design files), all dropdown has been updated already. Like this
The reason for multi-selection to have checkboxes is that we want to show users that this multi-selection. We did research before that without checkboxes, it is confusing for users, users don't know it is single or multi-selection.
I can see in designs, a lot of designers have adapted to the new styles already. (Such as vulnerability manage is also going towards the new style soon, see discussion here).
I am not sure the development status of this component. I am asking in slack channel now. If this is already in UI library, we should use it directly and then create a new issue to update all our dropdowns in Secure and Protect. If they are not in UI library yet, we can discuss do we have time to contribute to building it or create a separate issue. Does it sound good to you?
WDYT about having the Load More button in the middle of the dropdown to better signify that it is a button? It would be similar to how "more" buttons at the bottom of lists are presented in the app today
I tried in the middle, but I think visually it looks cleaner in a dropdown especially with the radio button there and the actions in dropdown such as select all etc, they are all left-aligned. Different from the other two examples, those are more complex content, in the middle, it is more obvious. We don't need this emphasis in the dropdown. But it is a personal preference for visual styles. I am ok with putting it in the middle now and when we have this discussion as an official pyjama component, we can update later ;) (Here is the issue, I am not sure we can have it done before you implement this)
Thank you @cam.x for the great and thorough explanations! TIL!
The reason for multi-selection to have checkboxes is that we want to show users that this multi-selection. We did research before that without checkboxes, it is confusing for users, users don't know it is single or multi-selection.
Currently in the app we do not support multi-select for this dropdown. We could potentially in the future, but I do not want to research/implement that as part of this issue as there is already enough going on. Since we do not support multi-select, does that affect the design of the checkboxes?
@aturinske multi-selection with a checkbox is not a blocker for this issue. We can have the current one and upgrade to the new one in the future! No problems! I heard from the Foundation team, it will be ready for 14.6. Maybe this will help us plan.
Alexander Turinskechanged title from Make environments picker dropdown infinite scroll to Make environments picker dropdown not load all environments at once
changed title from Make environments picker dropdown infinite scroll to Make environments picker dropdown not load all environments at once