Change UI for the install queue to match bulk operations

i've raised my concern i had with the current direction of first removing the drop button, moving to an add and install button solution and now moving even one step further and queuing several module to add and install. definitely convenient and streamlined for a big group of people. but that approach has one downside. from my personal perspective i have always a really really hard time figuring out after a module is installed where i am able to find configuration pages for that very module. the more module install at once it multiplies the struggle and cognitive load exponentially for me. that is the reason and rule of thumb, i also add several contrib modules but i never ever install more than one module at once. that is also the reason i am not a fan of a prebuild setup like drupal_cms where you not only have to figure out where all the configuration pages for all the installed modules are but also how they are configured. intimidating. and i suppose there are more people similar like me with similar concerns. but i think i might have an idea to to tackle the problem, without the need of re introducing drop buttons and complicate the entire flow further. i would suggest to have more actions in the bulk action list:

at the moment there is only the "add and install" action i suppose, but i would also an "add" action .with the add action people are able to select a set of modules upfront and then only composer require them . afterwards it is completely up to their preference how to proceed. and that way you would also have the flexibility. for example if you already know a certain set of module and you are familiar with their configuration you could also still choose the default "add and install".

Pulling in the comment here from https://www.drupal.org/project/project_browser/issues/3476807#comment-15... 📌 [PP-1] Decide on naming Queue/Dequeue button text Postponed - we need the "Select" button to actually behave more like a checkbox. So as part of this issue, the buttons should be in a sort of "secondary" button state, and the "select" state should indicate that it's checked. I recommend using the button styles we use for 'installed' right now, where it's white background, and then use the blue state when the button is hovered and/or checkbox is active. This will be better for a11y.

Quick mockup provided in the issue summary. This is _very close_ to what I want to see, but not perfect. Please make the bottom bar as close as you can to claro's in markup, and let it inherit as many styles as it can.

Also, we MAY need a second visual indicator for the select button, like an actual checkbox next to it or something.

I checked that section but couldn't find the 'Install' button. Instead, I see a 'Command' button. I've attached a screenshot for reference.
Let me know if you need any adjustments.

you have to go to admin/config/development/project_browser and check the "allow installing via the UI (experimental)" checkbox. that option requires package_manager being installed, which is either shipping as a submodule of automatic updates ( https://www.drupal.org/project/automatic_updates → ) or if you are on drupal 11.x is available there as an experimental module.

I'll try to work on this.

Tested manually and here are some suggestions:

• 0 items selected ==> No projects selected
• Install selected projects button should be disabled if no project selected
• Bulk action banner should be sticky as soon as some project is selected
• Remove unnecessary added classes
• #5 Needs to be addressed

Two additional observations to the points @narendrar made in #18 📌 Change UI for the install queue to match bulk operations Active :

the dark blue of the "install selected projects" button is too dark and has a too low color contrast (#003ECC/#232429 => 1.9:1). admin/content uses --color-blue-400 for the "apply to selected items" button, that way you have 3:1 meeting SC1.4.11

if you first select a module and then deselect (not sure if the bar was already shown without a selection), the styling of the "install selected projects" button becomes broken. grey background and greyish typography (SC 1.4.3&1.4.11). strictly speaking i wonder if it would make sense to hide the bulk action bar again as soon as no module is selected anymore. admin/content is showing the bulk bar all the time, but not sure if this is a desirable pattern since the bulk bar is sort of a visual distraction if someone has not checked a checkbox for any node why then show the bulk action bar on top of the content? the bulk action bar should only be shown if it is needed and in actual use imho. in particular on the project browser page you have already an information overload and having a bulk action bar shown all the time adds to that overload imho.

Addressed all the feedbacks and tests are also passing.Ready for review.

Trying to apply MR!634 but getting an error

Attaching screenshot for reference

Below are some findings:

• Still shows 1 item selected
• I think on clicking Install selected projects when no project is selected, it should scroll to top where the error message is shown
• Cursor : pointer in select button
• I am not sure if color of Install selected projects and Select/Unselect is correct or not.

I am not sure if color of Install selected projects and Select/Unselect is correct or not.

So i was trying to make this inline with the comment mentioned in #5 📌 Change UI for the install queue to match bulk operations Active by @chrisfromredfin. Not sure if that's not what we want.It would be helpful if someone clearly describes what behaviour we want for the select and deselect buttons.
Or i think we can take that as a follow-up because this issue is majorly fixing the install button behaviour to match the bulk action.

Trying to apply MR! 634 on Drupal 10 but getting an error
also In summary MR shows "Open Failed Pipeline"

Attaching screenshot for reference

i had already commented over on slack a few days ago, but add my comment for reference here as well now as well. the only two problems i see with the current state is for one that the button style for the queue button moved from a primary button style over to a secondary button style. per se a reasonable and good move since the primary action on this page is the install button on the bulk action bar now. but it feels not correct that the dequeue button is still styled as a primary button. semantically i think it would be the right choice to style the dequeue button as a secondary button as well? that could be done within the scope of this issue. the other styling with the stylized checkboxes we've discussed might be moved to a follow up to provide visual cues aside the plain button label helping the user to distinguish the queue and dequeue buttons more easily.

the color of the hover state has a too low color contrast against the background color of the bulk action bar, but that is an issue that core itself has with claro as well. on the thread i've suggested moving that to a follow up issue , opening an issue for claro and project browser. i'Ve also asked @mgifford about that detail, but havent had a feedback yet.

and another problem that core has on for example admin/content as well is the fact if you have not selected anything (an entity on admin/content or a a module on admin/modules/browse) you are able to click/press the apply to selected items / install selected project button anyway and you get a no project selected error. that error should be avoided in the first place. again that could be moved to a follow up issue.

so in summary the only thing i think from my perspecitve that would definitley make sense within the scope of this issue is changing the styling of the dequeue buttons to secondary buttons as well. what do others think?

ps: oh and i just noticed the secondary button is missing the state style changes (hover and active). the blue remains the same here? https://www.figma.com/design/OqWgzAluHtsOd5uwm1lubFeH/%F0%9F%92%A7-Drupa...

I have changed the deselect button to secondary button.

@rkoller can you have a look at this again?I have addressed feedbacks that i think can be addressed as a part of this issue.

thanks for the changes. over all things look better and more consistent moving the dequeue button to the secondary button style as well.thanks for that. the color for the normal and hover are correct now. the only thing missing is setting the active state when the button is pressed as well. that is still at #003ECC same as the normal state. and on a sidenote wouldnt it be the better choice to use the color variable instead of hardcoding the hex value? normal would be --color-blue-600, hover --color-blue-650, and active --color-blue-700... and the other points could be moved to follow up issues i agree.

Adding related issue here - just to note that we _may_ at some point (and it may be a future/follow-on issue) want to change the button action text based on the source plugin. So once you've picked some we may want "Apply selected recipes" for the recipe sources, and "Install selected projects" for the modules, ex.g.

Addressed the feedbacks.

re #31 📌 Change UI for the install queue to match bulk operations Active thank you! left a few comments on gitlab that added variables to the install button states as well plus to the border of the select button states to make things more consistent. but aside that things look good. everything else should be moved to follow ups as utkarsh_33 suggested.

re #30 📌 Change UI for the install queue to match bulk operations Active i still think it is important to be explicit about the terminology used on source type and i wouldnt consider the problem outdated but having an issue just about a single source type might be the wrong approach and there probably needs to be an issue for all source types in general. but there are a few need that need to be discussed how the bulk action bar should behave (out of the scope for this issue) if entities are selected for a source type and the person is switching source types. on admin/content the bulk action bar disappears on the new tab and if you return the previous selection is not restored. with svelte the selection is remembered, if you switch the source type after selecting entities on source type 1, there is no bar and no selection on source type 2 but if you switch back to source type 1 the selection is being restored (i m even able to switch to pages outside of project browser and if i return the filter string, filter settings and my selections are being restored?!). and within the same source type you are also able to add modules across several pages (something not possible on admin/content):

• if you have selected several entities across several pages of a source type it is difficult to remember (in particular people with a small working memory) on which pages you have selected which entity, there is currently no way to at least reset a selection. i suppose having an interface were you get an overview of your selection and where you are able to remove individual selections would overcomplicate the UI, but having at least some kind of reset option might be helpful or even necessary?
• about the selection being persistent. i wonder if it would be a good idea if a person is deliberately moving away from the context of project browser based pages to reset the persons selection and maybe even the string someone searched for? i imagine it might be a source for confusion and even a potential source for other problems (person unaware that a selection is still active, adding more to that, and in the end it becomes an unexpected number of installs for the person) or even be simply annoying if a selection is being persistent if someone leaves project browser pages and returns.
• in the context of an unexpected number of modules installs, would it be reasonable to add an option to the project browser settings to enable a confirmation step for the bulk install option? that the site builder gets an overview of the things being installed and has to confirm that first? that the person has the situational awareness what is happening next (also the case that an accidental selection of the wrong module was made?)
• in the context of the related issue it might be important to clarify that the "streams shouldnt be crossed" (i helped myself with ghostbusters). i imagine it potentially confusing if it would be possible down the line to have a "global" bulk action list for all available source types. solely terminology wise that would create tricky problems probably.

After reading through the issues that @rkoller listed in #32 i have. my own set of suggestions of how we can handle the issues as a seperate follow-ups for each of them.I'll describe them one by one.

1. The issue related to the
   

   if you have selected several entities across several pages of a source type

   it would be hard Or i would say not a good UI/UX to keep a track of which module was selected from which page as a user might change the number of module that should be listed on page at any point of time.I would suggest to keep a track of all the modules that we are going to install and the show a pop-up or maybe a simple UI that is shown in case of the uninstall modules page in Drupal core where we list the modules that are going to be un-installed.
   This might also solve the issue mentioned in
   

   n the context of an unexpected number of modules installs, would it be reasonable to add an option to the project browser settings to enable a confirmation step for the bulk install option? that the site builder gets an overview of the things being installed and has to confirm that first? that the person has the situational awareness what is happening next (also the case that an accidental selection of the wrong module was made?)

2. about the selection being persistent

   I think the better way to solve this problem of selection persitence is to give a reset button for now which simply deletes all the selections from a particular source type(or maybe all the source types at once) and then further we can provide an option to individually remove modules in case if a user has selected something by mistake.

✨ Make the "add to cart" threshold configurable Active allows DCMS to sidestep this issue.