[PP-1] Decide on naming Queue/Dequeue button text

Queue and Dequeue, while short don't describe the action. "Add to queue" or "Remove from queue" would be preferable and easier to understand. (or maybe "+ Queue" and "- Queue")

Wouldn't using the term "install" also make it clearer? "Add to install queue" or "Remove from install queue" .

Adding comment from @lostcarpark from Sitebuilder Subcommittee call on 10/15:

"Another approach might be to have a sidebar with the install queue always visible in the sidebar. When there's nothing queued, it could contain a message like "Items queued for install will be shown here. Use 'Add' and 'Remove' buttons to select modules to install, and press 'Install' when ready."

Adding comment from @rkoller from Sitebuilder Subcommittee call on 10/15:

"ui wise i would orient to the ui pattern used on admin/content for bulk operations. at the moment the add and install button for project browser is just a free hovering button at the button at the bottom of the page."

leslieg → credited chrisfromredfin → .

leslieg → credited lostcarpark → .

leslieg → credited rkoller → .

Adding comment from @chrisfromredfin in slack:

"Yeah I am preferring it as a banner all the way across the bottom, the way gin does bulk operations"

Additional comments from today's Project Browser slack meeting:

rkoller: ah no then it is like in claro i was refering to. just styled slightly different.
the claro one is just easier to recognize in black

rkoller: in comparison gin has a black box for the bul operations. that has a clear color contrast against the white background while gins light blue makes it disappear against the white background has a color contrast of 1.1:1 in gin compared to 15.5:1 in claro.
but the pattern is identical just different styling.
in gin it just breaks with SC1.4.11 that way. but that is the point utilizing already existing ui patterns. and that bulk operations bar went through a lot of discussions

see attached file - claro_bulkoperationsbar.jpg

Hey @leslieg,
Personally, I prefer using "Add to queue" and "Remove from queue" for clarity—it just feels more intuitive. I also really like the UI approach that Gin uses for bulk operations; I think it strikes a good balance between functionality and visibility.

(Also, I've created a child issue to change the layout of the bulk operations bar for the install queue - so we can keep this issue scoped to copy)

I have added the text's for the buttons in 2 different cases as per the proposed resolution.Marking it NR.

I found this confusing (my install multiple button had gone because of a front end bug and was hidden so I had to do some reading to figure out what should happen).

This is my opinion:

I would like to see a simple install button per project and a checkbox to select and deselect to install multiple recipes if I want to. I think that select and deselect is the correct wording for that. As an end user I don't think I will have an opinion on the order in which things are installed so the language of queuing things doesn't make sense to me.

@chrisfromredfin made a good point in a discussion on slack:

In this way, "queue" is really quite a misnomer, you're really "adding to batch") but queue/batch are not user-friendly words anyway

I agree that queue/batch are both challenging and abstract terms, but for me batch is less abstract as a none native english speaker (it would be easier to explain to someone else), plus i always prefer to use precise denomination. so why not instead of going with Add to queue go with Add to batch instead?

In regard of #18 📌 [PP-1] Decide on naming Queue/Dequeue button text Postponed - there is a child issue to this one ( 📌 Change UI for the install queue to match bulk operations Active } that is about adding a bulk action bar at the bottom of the page like you have on /admin/content. that bar will always be in the visible viewport (if it behaves like the one on the content page) and within the action select list the default action is shown. there you could basically use the button labels that were used before the queue button was introduced and that way it would be clear what will actually happen ( my suggested actions on the issue are "add and install" and "add"). there might be only the person who is using project browser for the first time or someone who only wants to install a single module (like the case you've described in #18 @tonypaulbarker), for those there might be "friction" with the current plan until the first module is added. definitely a valid concern.

Two or three weeks ago I've done an impromptu user test, asking attendees of the Drupal Dojo Austin about their first impression about certain parts of Project Browsers browser page. For the reference, that nights attendees were @rocketeerbkw and @cutehair. On the browse page both considered the word "queue" challenging, there was also the uncertainty in one initial reaction what queue actually means and implies. But they've also considered the pattern of using a regular button for adding a module to the queue not that helpful.
After explaining the functionality behind, as well as pointing to the planned bulk action component outlined in 📌 Change UI for the install queue to match bulk operations Active , their feeling was a checkbox would be the more suitable and familiar interface pattern for adding something to the batch. The currently used "toggle" button functionality is not that apparent and it was also noted that both button states only differ by their button labels, there are no other visual queues, so the user has to actually read to distinguish which modules have been added to the batch yet. The cognitive load is sort of high that way.
The suggestion was to add a "stylized" checkbox to the button, so modules not added and installed would have "add to batch" as the button label (picking up the suggestion from #19) with an unticked checkbox, while a pressed button would have the same button label "add to batch" but a ticked checkbox. That way sighted users dont have to distinguish between uniform looking buttons that differ just based on their button label . Same for screenreader users where the aural interface does not really announces the actual button state, there is always the uncertainty for someone without the visual context "am i in the unqueued state and by pressing the button i will move the module into the queued state or is it the other way around?". ( a similar problem is illustrated by leonie watson with the example of the light and dark theme toggle button over here https://youtu.be/OUDV1gqs9GA?t=3220)
if you make the button a switch button with a fixed label of for example "add to batch" in for example voiceover a screenreader user gets the announcement "add to batch" for the not pressed button and "add to batch selected" for the pressed button. that way the state is crystal clear there as well. and for both the rest of the necessary details could be communicated on the bulk action component.

I think that select and deselect is the correct wording for that.

I also think 'Select' and 'Deselect' (or 'Unselect' ??) are probably the least confusing. I think we should avoid use of the word 'queue' altogether. It might not be totally expected what happens when you click 'Select' but at least it's pretty clear in the meaning. And once you select something, you get the 'Install' button so the next step is still clear enough.

There are of course other things we can do to improve the UX of this, but I think updating this wording should be a priority since it is the UX that we have now.

Changes are aligned with #22, marking as RTBC.

having dedicated labels (select and deselect) for the different states is sort of problematic for screenreader users, see #20 📌 [PP-1] Decide on naming Queue/Dequeue button text Postponed (the linked video illustrates the problem)

shipping this as-is as the incremental improvement that it is to what we have; however, i've pulled Ralf's (very valid) comment over to the child issue, so all of it can be fixed there. Checkbox approached is seconded in #18, too.

ship it

Automatically closed - issue fixed for 2 weeks with no activity.