🇩🇪Germany @rkoller

benjifisher → credited rkoller → .

i've also manually tested the filter with a screenreader (voiceover in my case - see filter.mp4 - recorded the video a few days ago but managed to finish the write up just now). there are a few details to note:

somehow the announcement is sort of cut when the initial string is entered. in the first example entered ( "basic block" ) you can only hear "6 permissions", the rest of the string "are available in the modified list" gets cut by some announcement about the styling, and then just "block" gets announced again even though "basic block" was entered. when the already entered string "basic block" gets adjusted to "basic" the full string "15 permissions are available in the modified list." is getting announced. but "basic" is not announced after the announcement of "15 permissions are available in the modified list." like with the entry of "basic block" and the additional announcement of "block" before. BUT in the video when the filter is cleared by pressing the ESC key "basic" is announced before "all available permissions are listed". That is potentially confusing. And the pattern is reproducible if you enter arbitrary characters ("bvgfh"), again "0 permissions" is announced interrupted by some styling announcement, the rest of the string "are available in the modified list" is getting dropped. after that the arbitrary string is announced again. if you clear the filter field with ESC "bvgfh" is announced another time for the empty filter field followed by " All available permissions are listed"

In regards of the micro copy used, "modified list" in the context of the example "x permissions are available in the modified list." raises potential questions and make the user at least think. Me as the user could ask what does modified list mean in this context? Which list and what is "modified" implying; results added and or removed or even altered entries? Why not go with something like "x filter results"? That would be slightly more generic but shorter and more clear.

There is also a problem with WCAG 2.2. SC3.2.2 (https://www.w3.org/WAI/WCAG22/Understanding/on-input.html) in the current MR as well as in Core in a few places. Discussed that aspect with @mgifford. In short the goal of that success criterion is that the interface can be operated predictably by the user. At the moment as soon as the user is entering any character in the filter field the results are getting updated based on that entry immediately. The user doesn't have to press return, nor is there a submit button, nor any "warning" in the filter label. The content gets re-rendered immediately based on the entered filter string . The option might be to either add a filter button and wait with filtering until the filter button/enter is pressed or at least add some sort of "warning" to the label of the filter field so the user is prepared that the list will be filtered based on the entry immediately.

griffynh → credited rkoller → .

I would like to raise 📌 UX: Certain users understand the word "Draft" to mean "Unpublished" and are surprised that a node in "Draft" is published if a previous revision of the node is Published Needs work . Stumbled across it in the issue queue a few days ago.

and one question. at the moment the filter field is using the browser based clear button. that has the downside that the behavior differs in between browsers and in firefox there is no clear button at all. would it make sense to include the suggestion from this issue ✨ Add a clear button to the fields ui Active , adding the clear button functionality recently added to project browser, already in this issue, or keep the scope tight and keep ✨ Add a clear button to the fields ui Active as a followup?

rkoller → created an issue.

Left a comment: #2619328-82: A required boolean field behaves differently depending on the widget →

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-07-12 Needs work . That issue will have a link to a recording of the meeting. For the record, the attendees at today's usability meeting were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

At first thanks for working on the issue. In general we had a clear consensus that this feature is useful and the implementation looks good.

In regards of the question in #63 🐛 A required boolean field behaves differently depending on the widget Needs work , we've agreed to go with Require changing the string to Require the user to select the checkbox.. That way, the label would be consistent with the other label Use field label instead of the "On" label as the label. on that form display widget.

And we've noticed a detail about the single on/off radio buttons option, which is out of the scope for this issue. If you create a boolean field, set the form display widget to Single on/off radio buttons, then set the field to required within the field settings, and check the Set default value checkbox, you then get three options: N/A, Off, and On. With the Required field checkbox checked the only possible options are either Off and On. If you now set the default value to N/A, save, and reopen the field setting you will notice that the previously ticked Set default value checkbox got unticked and the Set default value checkmark got dropped again. If you take a look at the configuration for the field you notice either way if the Set default value checkbox is checked without an option or with N/A, default_value: { } remains empty after saving the field settings. So the N/A option is sort of without any purpose except the potential to confuse user and it would be way more clear if the N/A option would be removed from the list of options when a boolean field is required. But that should be moved to a follow up issue.

@quietone raised 🐛 The content overview Views view filters out unpublished content Active in the #ux channel

and i would suggest to take a look at 🐛 A required boolean field behaves differently depending on the widget Needs work .

and forgot to actually upload the two videos

at first apologies, i somehow missed your last comment mid june. :( but i have taken a quick look at the current state now. at first happy to hear that with this approach a lot of hard coded things would be dropped. that sounds like a good thing, awesome!

in general, personally i like that the recommendations are shown now all the time next to the field for updating the password field instead of showing them right after the first keystroke. that is setting the context better for sighted users.

in regards of the experience for screenreader users i've created two small videos. in the first run through (full.mp4) all the recommendations are announced which was "sort of" an exception, during most of my tries the first announcement after the first keystroke was more like, see and hear in oblivious.mp4.

But the thing i wonder if we follow the idea to make those "call to action"/"recommendation" in random order is it then really necessary to provide a list of all four recommendations (or in case the list is extended by a contrib module there will be even more) it might be overwhelming and hard to memorize all of them at once. would it make sense and be technically possible to announce the first recommendation right after "password secure edit text with autofill menu" and not only after the first keystroke? so the user knows i am in a password field and i should add a number first for example ( another time the first recommendation would be start adding a lowercase letter for example). that way it would be a guided experience in case someone doesnt use a password manager or the browser password autogenerate or alike?

I've quickly tested the latest state. A few observations:

1. When i tab into the category select field and press space the browser scrolls again while expanding the category list. Happens in Safari and Edge.

2. Displaying all the categories within the select field is sort of redundant with the list of category chips. Plus the entire list of selected categories is sort of hard to read as well as to process cognitively

As soon as you select more categories than that could fit within a single line the height of the select field expands to a multi unit height select field. problem is that the position of the modal remains one of a single unit height select field.

3. In regards of keyboard navigation, I have to check and test a few other cases, but it feels sort of unexpected and odd if you press the tab key that the modal collapses and the focus moves to the next select field. if you try the same for example on one of the three others, pressing tab does nothing, the select field remains expanded and you are only able to navigate the options with the cursor keys and close the list by clicking outside or press esc. therefore the differing behavior for the multiselect with tab feels odd and "might" be potentially confusing in case muscle memory kicks in.

As already written over on the conversation on slack, tested on a fresh install of 10.3.1. installed with composer, then composer required package manager and project browser only. then went into the project browser folder and added the MR543 and switched to the feature branch. enabled the ui install and tested with the star rating module. The module got successfully installed now via the json api source type. from a manual testing perspective that looks fully functional now. thank you!

rkoller → changed the visibility of the branch 3459288-unable-to-add to active.

rkoller → changed the visibility of the branch 3459288-unable-to-add to hidden.

yes there is a basic set of filter settings but when you arrive on the start page no actual query was sent yet. so the user gets results without actually searching anything at this point. and by providing queues and ideas (with curated lists and alike) as well as potential educational material with for example the scope notes of categories it could be provided inspiration to the user what to search for.
take for example google, there you only have the search field and nothing else, no results are shown upfront. on the other hand amazon, they could should results out of the box, but without any search query entered they only show curated lists and provide ideas and queues.

hm i've just installed simple_block on a instance of the starshot prototype which is running on 10.3.1 and using the navigation module and the gin theme. i've also spun up an instance of 10.3.1 with simple_block on simplytest.me. in both cases, the local as well as the simplytest.me, i am able to hover over the structure top-level menu item, then click block layout, then the submenu expands, and then i am able to click the simple blocks menu item which forwards me to admin/structure/block/simple-block . I've also tested navigating to the simple blocks sub menu item just by the keyboard, which also works. so on my end i am unable to reproduce the issue you ran into. have i missed or done anything differently in the steps i've described?

In general i like the idea, in particular in such a case described in the issue summary with that many field types available. One detail that probably could be made more clear is the label of the filter. Currently it says "Filter by field name or description". Technically not all of the available elements are fields types, but you also have groups for step one of the "add field" process (which currently is not visually apparent). so with this filter only the "stand alone" field types as well as the groups are being filtered, all the field types contained within the groups are not filtered nor available in this step. And it looks sort of unusual, first having the "Choose a type of field" label directly followed by the label of the filter field. on other pages that use a filter field those are usually wrapped within a fieldset/box, for example on /admin/people/permissions?

In regards of consistency and usability, if you compare the filter with for example the filter on /admin/people/permissions, it is missing a clear button. Out of the scope for this issue, but probably relevant, problem with the clear button on the linked permissions page is that it is using a browser based clear button which leads to a differing experience across browsers. project browser has created a dedicated clear button for its search field which is not relying on any browser based clear button. i've opened an issue ( ✨ Add a clear button to the fields ui Active ) moving that clear button component into the field ui in core a few weeks ago.

benjifisher → credited rkoller → .

The issue can be fixed by applying the following command according to @chrisfromredfin ddev drush cset -y package_manager.settings include_unknown_files_in_project_root true, I think it is ok deliberately enabling including unknown files found in the project root and not making it automatically working per default.
but i see another problem then here. it is not clear at all based on the error message in the issue summary what the actual problem is and how to fix it. Instead of labeling it with "StageException: Failed to run process" and providing a cryptic cmd line output, how about explain what is actually happening instead, that some unknown files/directories are included in the project root and that is the reason why the install fails (include one or two examples)? and provide the drush command how to enable those unknown files to the user as well: ddev drush cset -y package_manager.settings include_unknown_files_in_project_root true. that would be way more clear and directly actionable.

rkoller → created an issue.

huh somehow the version got changed by accident, that wasnt itended.

re @lostcarpark i can confirm that the dropdown isnt collapsed anymore when a checkbox is ticked by pressing the space key. excellent! and also thanks for adding the close on esc functionality!

re #46 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work the problem you've raised has another dimension. if you tab through the multiselect list by the keyboard and tick one or two checkboxes down the way the focus outline follows along properly. but as soon as you tick another checkbox by the mouse the focus jumps back to the first checkbox.
probably we should discuss how the focus outline behaves in particular if the interaction is mixed with keyboard and mouse. maybe we should follow the behavior used for example on the permissions page. but yeah in general i agree move that discussion to the on blur followup issue.

another detail i've noticed, if you are opening the multi select with the space key the drop down is just expanded. if you try the same with voiceover activated in macos and use VO-space then the multiselect not only expands but the first element is auto-checked. that shouldnt happen. the multi select dropdown should just be expanded with space as well as with VO-space.

the following issue 🐛 Wrong DRUPAL_ROOT with non-standard code structure RTBC might be also relevant for drupal sites in production as soon as it gets committed?

rkoller → created an issue.

Thank you for the initial MR @chandansha! Problem is when I checkout the feature branch the button label is still Install (and i've cleared the cache several times). Another thing to note is that the only changed file in your commit is the compiled bundle.js. Shouldnt the change for the string be also reflected in one or more of the svelte sources? And talking of change while taking a look I realized the necessary change wouldnt be just about the button label but the verb will also has to change for the "add and apply" button, at the moment it is only possible to apply local recipes but as soon as recipes on d.o are available add and apply becomes relevant as well. And in addition to that the recipesactivator.php has to be adjusted as well probably, out the moment it only outlines the local install. I'll update the issue summary accordingly.

I've taken another look last night, the point about the html element used on the title as well as the behavior for closing a dialog modal is all outside of project browser. i will open up an issue for core in general. so the only detail left to do might be to increase the width of the dialog modal in project browser (my suggestion would be 80 or 90rem). aside that this issue looks good to go?

forgot to add a screenshot to the IS in my initial post

rkoller → created an issue.

There is already an existing cypress addon for ddev: https://github.com/tyler36/ddev-cypress Perhaps that is already providing everything needed?

i am not using a composer based workflow but a git only workflow instead. but i forgot to run a git pull for the drupal core folder alongside. maybe THAT was the reason. not sure. but after running git pull on that i was able to run drush cr again as well as the error accessing the site is gone. thanks for the reminder. i really need to run core updates before i pull updates for a contrib project (i still need to get used to that new workflow - i had a composer patches based approach before) . will take a look at the changes itself tonight. also still have to write up a few outcomes from the ux meeting the week before last friday where we discussed this issue another time.

I've tested the 3310908-2x-make-detail-modal branch. A few thoughts:

even though it is not applied consistently in core yet. but a dialog modal should have an h1 title. at the moment the title in the titlebar is wrapped just in a span, i wonder if the cleanest approach would be making the title in the titlebar the h1 and remove the title currently wrapped in an h2 in the main content area of the dialog modal. and it has to be noted that with drupal 11 and the jquery ui 0.14 there will be finally a fix for screenreader users in dialog modal by adding an aria-modal attribute as a short term fix. that way it is even more important to have an h1 within a dialog modal since the DOM elements in the background of the dialog modal are finally excluded from the AOM now. james scholes from PAC left a a comment explaining the ins and outs of the h1 in the context of dialog modals topic pretty well on that thread https://github.com/mui/material-ui/issues/34250#issuecomment-1244006106 (but there are many more to name)

at the moment the modal can be closed by clicking the close button or pressing the esc key. i wonder if it would make sense to close the modal also when the user is clicking outside of the dialog modal as seen in this example from deque as well: https://dequeuniversity.com/library/aria/simple-dialog

another detail to note, at the moment when a dialog modal is opened the "compatible" button is getting into focus as the first element. the screenreader (voiceover) announces "compatible, button" and then "this module is compatible with your version of drupal. you are currently on a button inside a web dialog. to click this button press control option space". if i do so, without the visual context available, i would expect i would be able to click this compatible button, but nothing is happening. me as a blind user would feel lost. so the question is does it make sense to auto focus the first focusable element in this details page dialog modal at all and if a focus should happen would there be another, better choice? and in general the question, is a button the correct element for these informal icons at all?

in regards of the width of the dialog modal, at the moment the max width is at 800px. i wonder if it would make sense to make the maximum width of the dialog modal a bit wider. cuz with a two column layout within the modal the content of both columns looks a bit squeezed. and at the same time on widescreen monitors, 800px leaves a lot of unused screen real estate:

if you open a dialog modal in views the modal is wider (it uses 75% instead of a fixed value).

but that width used for views would be too wide for project browser (that way you would again get these long line lengths). at the moment the dialog modal in project browser has a max width of 50rem, how about going with 80 or 90rem. that way the columns wouldnt be that squeezed but the line lengh would be also acceptable and not too long.

and @chrisfromredfin, have you made a backup copy of the invision board for the priority guides for the details page in phase 1 and phase 2 (moving to the dialog modal) from back then (where the results from that questionaire were aggregated)? cuz invision went out of business if i a remember correctly?

no i am not using AdvAgg on any of the test instances here. i have to note that the instance the screenshot was created on is on 11.x. i went ahead and added gin to a drupal 10.3 site. there the vertical drag icon was correctly displayed. next i've tried to add it to another instance also on 11.x, there the vertical drag icon was also correctly displayed. the only odd thing was that the instance i took the screenshot on was still sticking to that broken display of the icon. :/ i've already tried to clear the caches several times with no effect as i've mentioned. i can't explain why cuz technically it couldnt be related but on the status reports page i noticed a warning that the navigation module and the toolbar module are both installed but the former is replacing the latter. so i uninstalled the toolbar module. after the uninstall the vertical drag icon was displayed correctly now. but no idea at all why that uninstall could fix the display of that completely unrelated icon?! are on uninstall more or other "caches" being cleared than with "drush cr"? just trying to figure out what was causing this behavior.

i run drush cr after every composer update. I did now another time and also pressed the reload button with a pressed alt key in safari. still the same display of the icon :/

when i update and checkout the latest state of MR513 and do a drush cr i get an error:

TypeError: Drupal\project_browser\EnabledSourceHandler::__construct(): Argument #4 ($uuid) must be of type Drupal\Component\Uuid\UuidInterface, Drupal\Core\KeyValueStore\KeyValueExpirableFactory given, called in /var/www/html/repos/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 in /var/www/html/repos/project_browser/src/EnabledSourceHandler.php on line 34 #0 /var/www/html/repos/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php(259): Drupal\project_browser\EnabledSourceHandler->__construct()
#1 /var/www/html/repos/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php(177): Drupal\Component\DependencyInjection\Container->createService()
#2 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(278): Drupal\Component\DependencyInjection\Container->get()
#3 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(242): Drush\Runtime\LegacyServiceInstantiator->resolveFromContainer()
#4 [internal function]: Drush\Runtime\LegacyServiceInstantiator->resolveArgument()
#5 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(212): array_map()
#6 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(182): Drush\Runtime\LegacyServiceInstantiator->resolveArguments()
#7 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(163): Drush\Runtime\LegacyServiceInstantiator->instantiateObject()
#8 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(117): Drush\Runtime\LegacyServiceInstantiator->create()
#9 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(54): Drush\Runtime\LegacyServiceInstantiator->instantiateServices()
#10 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(242): Drush\Runtime\LegacyServiceInstantiator->loadServiceFiles()
#11 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(218): Drush\Boot\DrupalBoot8->addDrupalModuleDrushCommands()
#12 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(211): Drush\Boot\DrupalBoot8->bootstrapDrupalFull()
#13 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(397): Drush\Boot\BootstrapManager->doBootstrap()
#14 /var/www/html/vendor/drush/drush/src/Application.php(214): Drush\Boot\BootstrapManager->bootstrapMax()
#15 /var/www/html/vendor/drush/drush/src/Application.php(180): Drush\Application->bootstrapAndFind()
#16 /var/www/html/vendor/symfony/console/Application.php(258): Drush\Application->find()
#17 /var/www/html/vendor/symfony/console/Application.php(167): Symfony\Component\Console\Application->doRun()
#18 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#19 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#20 /var/www/html/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#21 /var/www/html/vendor/drush/drush/drush(4): require('...')
#22 /var/www/html/vendor/bin/drush(119): include('...')
#23 {main}
TypeError: Drupal\project_browser\EnabledSourceHandler::__construct(): Argument #4 ($uuid) must be of type Drupal\Component\Uuid\UuidInterface, Drupal\Core\KeyValueStore\KeyValueExpirableFactory given, called in /var/www/html/repos/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 in Drupal\project_browser\EnabledSourceHandler->__construct() (line 34 of /var/www/html/repos/project_browser/src/EnabledSourceHandler.php).
 [warning] Drush command terminated abnormally.

Thanks for the quick fix. I've tested with 4.0.x on macOS 14.5. Problem is with the latest Firefox and Edge the vertical drag icon is correctly displayed, BUT in Safari 17.5 the display is broken:

Setting the issue back to needs work.

rkoller → created an issue.

rkoller → created an issue.

rkoller → created an issue.

left a comment on the issue: #3323354-22: Review all pop-up messages shown by the Svelte UI installer for user friendliness →

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-06-28 Needs work . That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, and @rkoller.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Initially our main objective was trying to solve the problem with the third error message. As mentioned in #19 📌 Review all pop-up messages shown by the Svelte UI installer for user friendliness Needs work and #8 📌 Review all pop-up messages shown by the Svelte UI installer for user friendliness Needs work it should be tried to avoid using technical terminology like staging area, composer, and alike.

Our first idea was, in case error three takes place to write a more verbose entry to the log file and go with something like this:

Unable to download the $project_id module from any available source. Try again in a few minutes. If the problem persists, see the logs for more information.

That keeps the error message itself easier to comprehend, and it is pointing the user to the logs, the only problem it won't provide direct actionable instructions how to solve the actual error. But the user would have at least some clue that one could post in a support forum.
Another idea we then came up with is, making what is actually happening, a bit more explicit with the error message, by stating that the project is unavailable in the repos which are defined in the sites composer json, and then pointing the user again to those logs:

Unable to download the $project_id module from any available source. Try again in a few minutes. If the problem persists, make sure that $project_id is available from at least one repository in your site’s composer.json. See the logs for more information.

Problem here, the terms repository and composer.json might be too challenging and too technical for none technical folks. For the "see the logs" sentence the same problem applies like for the first idea. In the end we ended up on a consensus to the following third idea:

Unable to download the $project_id module from any available source. Try again in a few minutes. If the problem persists, see Project Browser: Troubleshooting. (*with something like #no-available-source in the link)

It is basically impossible to explain everything in plain (none technical) english within one or two sentences. Therefore, since from my understanding this error message is for an advanced edge case using an additional (private) source, the regular user browsing and installing projects from d.o won't ever run into that, we thought it might be the best compromise to create a troubleshooting page specific to that problem. The link in the error message should directly point to the to be created troubleshooting section. In that troubleshooting section the problem should be briefly explained and then more importantly outlined how to actually fix it.

We then went ahead and copied the current state of all 11 error messages to a google doc because we've noticed that there is the need of a consolidation of the rest of the error messages. Some are still using the term staging area, and then there is the question should the term Project Browser be used in the micro copy at all. @benjifisher raised the valid point that if you the user are just click through project browser you have the h1 of "browser projects" and some of the status messages contain "project browser" (but both are fyi status messages informing the user that a dev version is being used). So the question is has a regular none admin user who has no permissions accessing the extend page is familiar with the concept of project browser?

We agreed to move the discussion of the last details over into the google docs document. The link is the following: https://docs.google.com/document/d/1SEjq-UkbCQglh7DTIJw1_rk2ckDo8qk8tV7m...

I've just commented on the corresponding thread on the #accessibility channel only. but would it make sense to open up a follow up issue to add the aria-describedby to the image field as well? cuz there the ui and micro copy is basically the same as the file field but for the image field the description still isnt announced.

benjifisher → credited rkoller → .

ah thanks i wasn't aware of that detail in regards of the override of the method. but there is one detail i wonder about. would it make sense to also add a test that makes sure that this override adding the aria-modal attribute when the modal option is set to true is still properly working and not silently breaking in one of the future upgrades of core?

created the followup for point 5 in the remaining tasks section: ✨ Add a clear button to the fields ui Active

benjifisher → credited rkoller → .

benjifisher → credited rkoller → .

I've successfully applied the patch. I was curious because I've worked (with the help of @rocketeerbkw) on adding the aria-modal attribute to dialog modals upstream to jquery ui (https://github.com/jquery/jquery-ui/pull/2257), as a short term fix for a serious issue for screen reader users in drupal ✨ With an open dialog modal make only elements within the modal available to screenreaders Active until https://www.drupal.org/project/dialog_native → lands. I've assumed it should/would work out of the box with drupal but when i've tested with one of the dialog modals on admin/structure/views/view/content the dialog-min.js for the beta2 of jquery ui dialog is loaded but aria-modal="true" is not being added to the open dialog modal? Is the dialog initialized somehow else in drupal and not with the modal option set to true? because with the latter the aria-modal attribute should be added in beta2? and sorry for the basic question but creating the patch was already way out of my comfort zone. :/

nice, thanks for the update @zetagraph. I like the general direction, the interface is becoming more and more less cluttered. A few observations and thoughts, first about the recent changes in #20 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work :

• The filter by category multiselect field is currently not keyboard accessible, it is excluded from the tab order.
• It looks somehow odd to have the outline of a fieldset wrapping the search and filter element components while the underline of the secondary tabs is equal to the fieldset's top border. I wonder if it would make sense to remove the bottom, left, and right border of that fieldset? That way it would be more in line with other pages in core that have such secondary tabs.

and then about the open questions:

A) Category multiselect
The behavior of the multiselect in the current draft is odd. If you click exactly within a checkbox the checkbox gets selected and the multiselect collapses. If you click outside of a checkbox in close proximity the checkbox gets checked but the multiselect modal remains expanded. But in each case there is a reflow of the results section on every click - i am not sure if there is a new request each time when a filter setting is changed or only if the search query is altered. But i wonder either way if it would make sense to go with the suggestion in #7 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work adding an apply button to the multiselect. that way the categories could be selected and the reflow only happens when the apply button is pressed and the multiselect collapses (like for example on https://www.galaxus.ch/search?q=nintendo%20switch for the category multiselect)?

and then there is still the question if there should be an "all categories" option? I've thought again about the question if it would make sense to add a "show all" option to categories like you have for the development status, maintenance status and security advisory coverage filter components. For one all of the four current filter components should be consistent, either all should have a "show all" option or none should have one imho. But strictly speaking, the purpose of a filter is to filter for something aka narrowing down. so without a filter applied you show everything while as soon as you apply a filter either one or more of the categories or something like maintained you reduce the number of results.

Styling wise, there is no interface component for a multiselect in the drupal design system yet but i suppose the styling for the checkboxes should follow the design system. Another detail to note, at the moment if the list of categories is expanded the visible options are from "access control" to "integrations". If a user has hidden the scrollbars by default on for example macOS it might be unclear that this list is a scrollable one. It might be a good thing to make the height of the select list uneven; instead of going with a whole number of options, 11 visible categories at the moment, go with 10,5 or 11,5 instead maybe?

B) The development status, maintenance status and security advisory coverage filter components
It is more than a valid point that was raised again during the last UX meeting, that there should be at least three options for any select list in use. But i have to admit i really liked the EUR-Lex example where you have no label for the select fields and the current selection and context is provided just within the multiselect field. That way you see what the multiselect is about while nothing is selected or you see the actual selection, plus you get a consistent look of all the four filter components.
My worry was by having just a single multiselect field and then three checkboxes or toggle switches with an appended label might look less consistent and uneven. Plus the problem of communicating within a single label that unchecking shows all modules while checking shows modules with for example an active development status. That "might" be potentially challenging to communicate as well as to comprehend. One potential compromise might be the approach Semantic Scholar took (see the "has PDF" button on https://www.semanticscholar.org/search?q=geography&sort=relevance). Their filter options are a mix of multiselect fields and a toggle button. That way the filter line could look way more consistent and the multiselect and the toggle button would both add filters narrowing down the selection.

C) The active chips
The question is if the chips for active filters add value or noise. In the current form with a "few" filters added the chips take up quite a lot of space.

Plus there is the point that was raised during the UX meeting twice, that there is no way to distinguish which chips are about categories, which about the development status, which the maintenance status and which about the security coverage.

from my understanding all work should happen in 2.x from now on and i doubt it would be committed to both branches, but suppose @chrisfromredfin is the better person to answer that. but in regards of the 2.x branch you've created, a huge thank you to you @sime! that one i am able to apply with composer patches, 1.x failed to apply constantly and i was unable to test locally.

thanks for pushing it forward! about your questions. the category filter breakpoint made the filter category sidebar collapsed by default on mobile. i agree, that can be removed. and about the second question in regards of the filter category and keyword search field order. yep that should be switched.

about your screenshots. i still think the search field and the filter multi select fields should be visually distinguishable. i'll just add my thoughts in regards of the different screenshots:

first screenshot: there you have the search field and the four filters with the same padding in one row (the order of search and categories put aside) all wrapped in a fieldset which also contains the reset link and the sort by option select field. in regards of the "all in a single line" approach i consider the eur-lex example clearer. there you have the search field in a different color and font size while the selected options for the filters have a larger font size and weight as well as a different color. plus the multiselects have no borders. and the search glass is left aligned, prepended instead of appended. (i am not entirely sold on the single line approach). and i dont know how the smashing mag would envision the single line approach for mobil cuz visually it is one single large field with three multiselects included. but i doubt it would work if the multiselects get wrapped.

second screenshot.same issue like with the single line approach, search is visually similar or close to identical to the four filter options. personally i am more drawn to an approach looking something like that:

desktop viewport (2 lines)

search
category, dev status, maintenance status, security advisory

and depending on the available horizontal viewport width the options for mobile viewports would be

mobile viewport (3 lines)
search
category, dev status,
maintenance status, security advisory

mobile viewport (5 lines)
search
category,
dev status,
maintenance status,
security advisory

and i wonder if the recommended filters link would be necessary at all? and at the same time i also still wonder if it would make sense to move the sort options out of the search and filter box. that the different steps (search, filter, sort /results) a separated visually more clearly?

benjifisher → credited rkoller → .

Finally managed to finish the comment: #3318817-15: Improve the categories filter type in context to the rest of the filter component ui → . Please feel free to correct and or add any point that is missing or misleading. I've really struggled to get everything into a coherent and comprehensible form :(

A few additional thoughts observations I came up during the write up for #15 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work :

In regards of right sidebar in point A. I wonder if the university of Edinburgh tested for pages that have a horizontal main menu on top. Meaning in the context of the Drupal admin ui with the horizontal admin toolbar in place having the filter sidebar on the right is definitely a viable option. But with a vertical navigation like with the the navigation module installed you have one sidebar on the left and one side bar on the right, the results are crammed in-between leaving again the problem of not enough room for the results. Plus having the setting on the right brings up the problem of continuous reflow every time the filter settings are changed which makes the results section busy and a constant source of distraction every time the filter settings are being altered.

By aligning the interface pattern for the list and grid view in project browser as mentioned in #15.4 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work to the media module there are two details to note:

• The elements, order, and/or labels for the filter section in media for the table and grid view vary significantly. For table you have media name, type, publish status and language. For grid you have published, name , media type, language, and sort by. For grid it might be considered as well to move the sort by option out of the filter section because it is not actually a filter. In regards of the micro copy, media uses - Any -, while project browser uses Show all. Also the filter button label differs, table has just filter while grid has apply filters - the filter button wouldn't be necessary for project browser. But over all i think it would be reasonable to make the filter options within those two tabs more consistent for media as well as align media and project browser in particular with any/show all. What do others think, is it a reasonable thought and should i open a follow up issue over in media?
• In regards of consistency i wonder if it would also make sense to drop the secondary tabs for table and grid in media and replace it with the toggle switch solution used in project browser. That way the interface pattern would be consistent inbetween the two? same question, what do others think?

And finally my current personal preference about the proposed resolution. I am in favor of having four filter types and each being a multi select field. The category filter type should get a show all option. I also like the x number of selected categories label for the multi select field in case more than one category is selected instead of to concatenate the list of selected categories. I also see the need to communicate the active filters, in particular for categories in some additional and/or different way alongside the multi select label, but chips still feel suboptimal as outlined in the second point in B.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-05-24 Needs work . The direct link to the recording of the meeting is https://youtu.be/eRTK--QbRmQ

For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell, and @SKAUGHT.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

At first apologies for the delayed comment, but the first week something else came up and the second week I've heavily struggled getting all the points raised during the meeting into a coherent and hopefully comprehensible order without leaving out too much detail. It has to be noted that the basis for our discussion was a brief presentation of the status quo in version 1.0.x-dev of project browser followed by the current proposed solution illustrated in the form of https://www.nejm.org/search?q=health&isFilterOpen=true and the EUR-Lex example by the Smashing Magazine:

The first impression an attendee had looking at the status quo of the search page of project browser at the beginning of the meeting, was that it is sort of busy and cluttered. It made him even feel sort of anxious due to the sheer amount of information one has to digest all at once, which is sort of overwhelming. So at the end of the meeting our conclusion and general consensus was that the proposed resolution is definitely a step into the right direction even though we haven't agreed on any clear recommendations.

Therefore in the following a list of all the points raised during our discussion within the scope of this issue and after that a few additional noteworthy points:

A) General layout
There was a clear consensus that the filter categories, currently placed in the sidebar, take up way too much room and something should be done to hide most or all of them by default. With the new navigation module installed and with the filter categories sidebar in place there is even less space left for the results horizontally compared to the horizontal admin_toolbar (screenshot is on a 16"):

• One part of the group liked the idea of moving and including the categories with the other filter options above the search results. It was also well received that with the multi-select field the list of categories currently shown on desktop viewports is hidden by default. It also removes the details element on mobile view port making the interface consistent in between desktop and mobile.

  (*Post meeting addendum: With the filter categories sidebar removed, you gain more room for the results, plus there is a clear separation of concerns, first the search then the filter section, and then the results section, stacked onto each other)

• As an alternative, based on the user research assessed at the University of Edinburgh in the context of search ux, it was suggested instead of moving all the filter components into a horizontal element on top of the search results, to move all the filter components into a sidebar on the right next to the search results.

  That is just a brief mockup done in devtools moving just the filter categories over. But the suggestion was to have a box/section for each filter option. For the reading direction of LTR, having the sidebar on the right, the filter would not interfere with the processing of the search results. It was also noted that research showed that their students wanted to see all results, since they mistrust filtering.

B) How active filter settings are communicated
The mockup for EUR-LEX (presented by the Smashing Magazine in the webinar on search ux) was very well received by all the attendees - overall it felt less visually cluttered. With that approach the chips for the active filter settings would be dropped. But the concern was raised by one attendee that people like chips, enabling them to easily assess the current state of the set active filters or remove one chip by clicking its close button.

• In case the chips are dropped it would be possible to communicate the default selection aka the active filter setting within each multi select field. That would work very well for the development status, maintenance status, and the security advisory coverage which is basically a boolean, either show all or the actual setting. Category filters have two problems, an "all" option is missing, at the moment that setting is implicit when no category checkbox is checked, so it would be desirable to add and "all" option. Then you have the problem that you can have up to eighteen categories selected, but already with two or three categories selected you wont have enough space available within the multi select field. nejm simply concatenates (https://www.nejm.org/search?q=health&isFilterOpen=true&startPage=1&isFil...) which is not helpful nor desirable. The suggestion was raised instead of concatenating simply display something like "3 categories selected". That way it would be communicated either all categories are selected or a subset, and if so how many. The downside it would still require one click to see the actual list of selected categories. A relevant aspect for people with a small working memory.
• To tackle the fact that people like chips as a way to easily assess and alter the set of active filter settings it was suggested to consider to combine having a set of four multiselect fields and chips for active filters. But these chips would have the same problem as the current state of the project browser interface. Having category chips in the same row as the chips for other filters is confusing. Development status, maintenance status, and the security advisory coverage are actual toggles/booleans standing for a single filter setting, while filter categories can have several chips. Then there is the fact that there is an effort to make those category chips clickable (see point 2 later within this comment). Instead of trying to make those different types of filters more visually distinct there was the thought why not wrap the chips for categories in one details element and the other three in another details element, to group them separately.

C) Multi-select fields vs checkboxes
There was also the question if each of the four filter types should be a multi select field or if development status, maintenance status, and the security advisory coverage should be checkboxes instead, since they are boolean values switching between for example maintained and not maintained, and grouped together somehow. So you have a multiselect field and a group of three checkboxes.

D) User testing
It was suggested to consider user testing whether to combine the three existing filters into one set of checkboxes and also for the question if the four filter types should be on top of the results or if they should go into a sidebar on the right.

During our explorations there were a few still noteworthy details out of the scope for this issue:

1. https://www.drupal.org/project/search_web_components → was brought up. Maybe project browser can get some inspirations from this module or even use some of its components? The attendee who brought up the module didn't know how feasible this suggestion actually is, but it might be at least worth looking at it or maybe get its maintainer interested in the effort of project browser?
2. One attendee wondered why it isn't possible to click a category chip on a module card on /admin/modules/browse, same as it is possible on a details page. His expectation was by clicking a chip on the browse page the clicked chips category would extend the list of already ticked filter categories. Another attendee had the exact opposite expectation, he thought the list of ticked filter categories would be narrowed down to the one clicked, same as the behavior on the details page. There is already an issue 🐛 Module categories on Browse tab aren't clickable, don't perform a search RTBC making the chips clickable. Behavior wise it follows the second pattern, and mimics the chips behavior on the details page. But the question remains how to make the link behavior of those chips clear on the /admin/modules/browse page?
3. On the other hand the question was raised if the chips are really needed there? What is the actual value of these chips being added there? The card layout feels visually cluttered, like there is a lot of visual information. But if a user has already filtered by categories, they already know the selected categories, if they have not filtered by category they are probably searching by a specific term. And the actual categories would be available on the details page for a module anyway. But in the context of the content of a module card on the search results page the attended was unable to imagine a situation where displaying those categories adds a huge amount of value. (*Post meeting addendum: to get an idea if these chips are of any value it was suggested to run some user interviews. During the meeting I haven't remembered but there was a questionnaire covering that question a few months ago: https://docs.google.com/spreadsheets/d/17JiSqr5VH0fupdGLo6pLatM2Vfx0y3vw... . In the sheet Question 1&2Stats the category component is ranked into the third important group out of four for the second question when people are just "browsing" with no clear goal in mind. It has to be noted that the questions referred to the module page aka the details page. So there was no specific question in the context of are categories considered a useful component on cards).
   On a related note in the context of the visual clutter, another attendee noted that cards should be as easy scan-able and consistent layout wise as possible (according to Vitali Friedman from Smashing Magazine). But at the moment you have one or two line titles making the short description start at different heights across the different cards and then you have one or two lines of chips depending on the number of modules a module maintainer has set.
4. In grid view cards are already hard to scan. At the moment the list view is using cards as well. For the list view the content of a card is just rearranged: a single column, less height, way larger line length where only the horizontal viewport is the limit, which is way past the goal of ~80 characters. Technically the list and grid view are both card based views. The group came up with the idea to instead align with the interface pattern media applies. To use an actual table for the list view (like on /admin/content/media) and keep using the cards for the grid view. By using a table you would be able to display way way more results onto a single page and those results would be way more easy to scan. @chrisfromredfin already opened a follow up issue: ✨ List view should actually be a table Active .

uhhh took another look after @chrisfromredfin mentioned the issue on slack. i thought it wouldnt be needed after MRs were successfully applied, but somehow none of the changes were in place still. but running yarn install and yarn build did the trick. completely forgot about that :( but all the changes look good now and setting to rtbc

thankt @kwiseman, this looks good! i've also tested in safari and edge with voiceover. the only small nitpick with voiceover is that if you have a state change from not pressed to pressed, voiceover is just announcing "selected" without repeating the context like for example "selected list toggle button". but that is a voiceocer thing.

one detail i've noticed, i am testing on drupal 11.x-dev, project browser is still using yarn 1.x, but drupal 11 is requiring yarn 4 for a few weeks now: https://www.drupal.org/node/3428571 → . would it make sense to create a follow up upgrading the yarn version?

and in regards of the styling, we've both agreed (according to your comment on the thread on slack) to move the styling to new issue. the only question is how to approach it. cuz that would be an issue for core in general, project browser would be the exception having two toggle buttons next to each other which are slightly different contstraints. not sure but probably a single issue summarizing the points from the linked thread including the requirement for project browser as another mandatory variant might be the best choice?

benjifisher → credited rkoller → .

Thanks for the clarification! and one thought i've raised over on slack but wanted to document in here per request by @drumm. would it be make sense and be possible to get the search strings only when works with is set to either any, drupal 11, drupal 10, drupal 9 , or drupal 8. and to exclude searches targeting drupal 4-7. those wouldnt have any relevance for project browser anymore?

I've applied MR480 and also cleared the caches. Hovering over a category pill brings up the pointer, and adding the pointer rule to each list item instead of the wrapping unordered list seems like a reasonable call. only problem at the moment it doesnt happen anything on click, i've tried in safari and edge, while the click on the details page still works. but clicking a category pill on any card on the main page has no effect.

but there is also the question how the category selection behaves on click. if you have access control and accessibility selected in the filters category section on the main project browser page and you go to a details page and then click the category decoupled for that module you are forwarded back to the main page, access control and accessibility are unticked now while decoupled gets ticked.
but the question is what would be the expectation, returning to the example from the details page, if access control and accessibility are ticked and you now click for example the integrations category pill will now access control, accessibility, and integrations be ticked or will access control and accessibility be unticked and only integrations be the sole category being ticked? also the point that applies to the detail and the main page to the same degree, how to signify that you've clicked a category pill and how to revert to the previous category filter selection? yes you have the option to use the back button function in your browser but shouldn't there be at least some signage and/or an option to revert the selection on the page itself as well?

and two more aspects about the category pill design in general which are probably out of the scope for this issue. at the moment only the pointer changes on hover but shouldnt the styling be changed on hover and when active aka click, to create an affordance like for other interface components as well? the cursor alone could get missed.
and the background color for the category pills has one general problem, the background color (#E5E5E5) against the card background (#FFFFFF) has a color contrast of 1.3:1. In particular since the pills are clickable, interface components the user is able to interact with have to have a color contrast of at least 3:1 (WCAG 2.2 SC 1.4.11)

on the other hand you could also ask a controversial question and question what is the benefit of having the categories on each card? the user is able to control which module cards are shown in the results list by ones selection on the categories filter. problem is there is no switch between AND and OR for filter categories, so it is possible one card could contain only one out of three selected categories, or two or all. but the cognitive load is high to figuring out which categories are selected and which categories a card belong to. but as i said the card is matching the filter criteria and on the details page you have the category pills anyway so are those pills really necessary on a card? and on cards those pills are sort of harming the easy readability and scanability.

hm i am not sure if changing the styling from the regular button grey to the primary button blue for the pressed button would be the right choice. might be potentially confusing :/ technically there doesn't exist an actual toggle state for the drupal design system unfortunately yet. :( the following comment and the comments in the following in this thread https://drupal.slack.com/archives/C1AFW2ZPD/p1704456082112179?thread_ts=... are about introducing a toggle state to claro. the switch between the grid and list view would actually another example to be named in the list of examples in this linked discussion.

I wonder if it would make sense to narrow the scope for this issue and make it only about screenreader accessibility and move the design to a dedicated issue and maybe ping @ckrina in that regard, bringing the new toggle state for the drupal design system back on the map? what do you all think?

and would it be possible that you open a MR for this issue fork. that way it would be easier to apply the patch for me since i rely only on the composer patches based workflow still. would have to manually test the changes in voiceover.

hm a few thoughts. "technically" sort by is not a button but a select field so the greyish regular button background feels off and semantically wrong. while on the other hand the grey for the filter is semantically correct since it is a toggle button. but that filter button has a border (#919297) buttons usually dont have according to the drupal design system? also on hover that border gets solid dark/black instead of changing the background to a darker grey, also not in line with the drupal design system. i am not sure if styling the filter toggle button and the select field the same way is the right call here. those are different kinds of interface elements. and from an accessibility point view the background of the select field (#D3D4D9) against the filter section background (#F3F4F9) results in 1.3:1 , WCAG 2.2. SC 1.4.11 would require at least a color contrast of 3:1. the filter toggle button would have the same issue but with the border in place it is "slightly" better but still not meeting SC1.4.11. border (#919297) against the filter section background (#F3F4F9) has 2.8:1 and border (#919297) against filter section background (#F3F4F9) gets 2.1:1. and then there is also 📌 Improve the categories filter type in context to the rest of the filter component ui Needs work which would change that entire filter section. and strictly speaking the sort select field wouldnt be part of the filter section anymore since it gets untwined.

thank you for the list! just for the context, what period of time these queries cover? are those the top queries the last week or the last month? and searches from google analytics data, does that mean the searches on google, or searches directly on d.o just tracked with google analytics?

rkoller → created an issue.

benjifisher → credited rkoller → .

closed #3047809-15: Tabbing inside dialogs do not work with Safari → as outdated. turned out it was not an issue anymore testing the steps to reproduce in the current version of safari.

The issue was raised in the bugsmash channel on the drupal slack today. I've quickly followed the instructions in the issue summary on an instance of 11.x-dev and tested with safari 17.5. As illustrated in the added video (see safari.mp4) the issue seems to be fixed and or working in safari as well now. I'll set the issue to closed and outdated.

I am not sure if the categorical avoidance of contractions is the right choice here. First a few additional aspects:

1. The Drupal User Interface Standards for interface text have already the requirement not to use contractions ( https://www.drupal.org/docs/develop/user-interface-standards/interface-text → see the last point within the style section)
2. The Yahoo style guide (Barr 2010: The Yahoo Style Guide) has the recommendation to use contractions with caution. From their point of view readers should know common contractions like it's or she's and some might even understand irregular contractions like let's (let us). While negative contraction, even the simple ones like can't and don't, can easily be misread by people who are only briefly scanning a text. Their recommendation is, for the sake of clarity, in case the information is in particular important, to spell these out (for example, Do not click Buy before you complete the form). While slangy, outdated, or less usual contractions such as ain't, that'll, could've, shan't, 'tis, and the unwieldy shouldn't've should be avoided in general.
3. Erika Jorgensen takes a similar approach in her book on Strategic Content Design. In the section about plain language she actually advocates for the use of contractions. According to her avoiding contractions is another writing rule that was advocated for long ago by English teachers everywhere. From her perspective this recommendation feels extremely outdated, in particular in the context of digital content. Contractions improve the readability and create a more conversational, friendlier tone for your content. According to her there are only a few reasons to avoid contractions. First, cases where one is writing an amicus briefs or some kind of formal legal documents. Second, cases where one is writing a warning or error message in the context of UX content/micro copy. In these cases it can be considered helpful to avoid contraction entirely, because doing so forces the recipient/reader to slow down a bit and to focus on why the error happened and what the exact next steps are they have to take. The example she provided alongside was: The app did not launch can be more emphatic and clearer than The app didn’t launch. In this particular case, not is the most important word in the sentence and you are doing the reader a favor by writing out did not instead of condensing it into didn’t.

The three links about contractions and plain english in the issue summary are in the same vein like point 2 and 3.
So as I've state in my initial statement, I would be rather hesitant to ban and remove contractions from the documentation entirely. I would try to still allow the usage of contractions but avoid negative contractions and maybe conditional contractions. And as a rule of thumb in situations where you as the writer want to be empathic and extra clear avoid contractions as well (see point 3). That would be sort of the middle ground between completely banning contractions or using contractions for everything. From my perspective it would improve the general readability but at the same time the copy would become more clear in the situations where it is necessary. And on a side note, personally I also disagree for the given reasons with the strict ban of contractions in the Drupal User Interface Guidelines in point 1.

I'll assign the issue to myself after a discussion with @ckrina. she highlighted the problem that at the moment some or quite a few of the raised issues might be layout builder rooted issues which might even already have existing issues. I will dive into the list of existing layout builder issues and also compare the navigation layout page with a layouts page of a content type. so that the number of issues specific to the navigation module might be smaller.

rkoller → created an issue.

finally found the already existing issue for the quickedit button again. added the issue ( 🐛 The toggle that makes Contextual Links visible at all times might not be sufficiently discoverable Active ) to the proposed resolutions for point 6.1 in the issue summary

rkoller → created an issue.

rkoller → created an issue.

itmaybejj → credited rkoller → .

I've tested MR5231 and created a short video (see dropbutton.mp4 - recorded on macOS 14.5 and safari 17.5 with voiceover). In general the first point of the proposed solution looks good, the open and closed state are commenunicated, that's perfect.

In regards of the second point reducing the drop button label from "list additional actions" to just "additional actions" is a good choice, i agree to that. The only thing i wonder is if it would make sense to append the context the button is in, front load "additional actions" and then append the context. that way a screenreader user could jump off at any time but still has the option or in case the person has a small working memory to reassure it is the correct button in the correct context (also if someone navigates by the rotor). the edit button as well as the delete option already provide that context while the additional actions button and translate option do not? I would consider it out of the scope for this issue but moving "providing a context" into a follow up might be a reasonable step, what do you think?

In regards of the third point, keeping the dropdown up when focus and hover are out i consider a good thing but as soon as another drop button is expanded it looks and feels odd (check dropdown.mp4)? wouldnt it make sense to collapse a drop button as soon as another is expanded? would be the same pattern that was used for the subnav of top level menu items in the admin_toolbar?

and @camilledavis you've suggested to allow the user to collapse the drop button by pressing ESC in #4 ✨ Dropbutton widget not accessible to screen readers Needs review . I would +1 that option.

Left a comment on the issue: #3382787-46: Add responsive_image field widget in form display for image type field →

We discussed this issue at 📌 Drupal Usability Meeting 2024-05-17 Needs work . That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMchale, @benjifisher, @rkoller, @shaal, @skaught, and @simhohell.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

While exploring the new responsive image form display widget we ran into one problem. On a standard 11.x-dev install with the responsive image module installed, and MR4628 applied, we had the following three options available for Preview responsive image styles:

2. Narrow
3. Wide

Our assumption was that based on micro copy you would either get the preview image added in the dimensions of the chosen responsive image style or you have no preview depending on your choice. But problem was no matter what setting we set the resulting preview looked like this:

Our expectation, based on the micro copy, would have been that this would only be the result in case option 1, no preview, was chosen. So we were not sure if this is a bug, and in general we've asked us how this feature is intended to work? We would need some clarification in that regard before we are able to make any recommendations.

We will also continue our initial discussion we've started in regards of the micro copy. There was already a clear consensus to change the label Preview responsive image style to Responsive image style for preview. "Technically" a user isn't "previewing a responsive image style", instead a preview image based on that responsive image style is being generated. About the corresponding description, there was the consensus to clarify where the image is shown (aka that it is shown on the edit form), and that "preview responsive image" is too verbose as well as misleading (There is only a single image being used, based on the responsive image style - but again we need to know how the feature is supposed to work).
One radio button option is called Bar with progress meter while within the description it is referred to as a progress bar. Aside this inconsistency in terminology it was also noted that the first sentence of the description is imprecise, the throbber actually is communicating the status of the upload, it is telling the user if the upload is still underway or was already finished. But the microcopy about the progress indicator would apply to regular image widgets as well. So making adjustments in that regard would be more suitable for a followup issue to keep things consistent between image and responsive image widgets.

But we will finish the discussions about the micro copy as well as the functionality in general as soon as the feedback is in. Thank you in advance!

Not sure what the best status would be in this case? I went with needs work but to postpone with maintainer needs more infos felt wrong since i am not the maintainer nor person working on this issue. I'll go with needs work, but please adjust accordingly if that is not the right choice and there is a more suitable one. Apologies in that case.

I've updated the issue summary clarifying that the creation of the body field should be prevented for content types and block types and added the Needs product manager review per discussion on Slack.

According to @drumm this issue doesn't have to be postponed anymore since d.o has project browsing now.

I've applied the latest changes. When I test in Edge in LTR the megaphone points to the right while on RTL i can confirm it points to the left - that is the expected behavior. BUT when i test in Safari (17.4.1 on macOS 14.4.1) it is the other way around, LTR still points to the left and RTL points to the right.

I've succesfully applied MR46. First a feedback about the points listed in the issue summary:

* When expanded, it should be possible to click outside of the button to close the dropdown.

that works as described but i wonder if would it make sense to close the dropdown also when the user clicks inside the preview area? at the moment it only closes when the dark title bar, the frame in slightly lighter dark or one of the other buttons is clicked.
and talking about closing the dropdown the usual pattern keyboard users are familiar with is pressing the ESC key. but that immediately closes the entire preview window. would it be possible and make sense when ESC key pressed and the dropdown is open the dropdown is closed while if the dropdown is closed and the ESC key is pressed the preview window is closed?
And there is also no aural feedback when the dropdown is showing or closed - a screenreader user is unaware if a dropdown is opened or closed (see keyboard_vo.mp4). that might be accomplished by introducing a toggle or switch button for the settings button?

* It should be possible to click on the checkbox to toggle an option in addition to clicking on the link.

That works as described in the issue summary the only problem i notice is if you navigate by the keyboard and you have the screenreader announcement active. that way you get two announcements per setting within the aural interface (see keyboard_vo.mp4) which is sort of redundant.

✅ The dropdown should not overlap other buttons.

✅ Dropdown links should show pointer on hover.

✅ Preview panel jumps slightly when view mode control is added or removed.

aside those points there are two more details to note. First the focus outline has a too low color contrast with 1.5:1 it should be at least 3:1.

and one detail about settings in general. those four settings overlap with the settings found on /admin/config/content/same-page-preview in one setting, the "open preview by default". but that surfaces one problem. it is not clear to me at all if the settings on the node are "individual" settings aka overrides on a per node basis or a mirror of the global overall settings (on a sidenote "open preview by default" is way more clear than "on by default" on the settings page)? i've unticked the "on by default" checkbox on /admin/config/content/same-page-preview while "open preview by default" is ticked on the node preview, when i open a node the preview window is opened automatically though. that is confusing, me as the user i always ask myself which of the two counts and is there a "hierarchy" or do the settings simply mirror themselve? having that kind of settings in two different places, with some only available on the node others only availble on the config page and some availble in both places, is simply confusing.

sorry havent found time earlier during the weekend to jump over from the github issue into this one. I think i might have found something that that is at least within the same_page_preview code and might be a potential clue?

I've just git cloned the latest state of starshot another time and required 2.1.x-dev from same_page preview and also switched off the aggregation of css and js. the console error when previewing one of the two nodes available is:

[Error] TypeError: null is not an object (evaluating 'previewOnHiddenField.value')
	(anonymous function) (drupal.js:64)

switching to the source view:

(function(Drupal, drupalSettings, drupalTranslations, console, Proxy, Reflect) {
    Drupal.throwError = function(error) {
        setTimeout(() => {
            throw error;
        }, 0);   (the inline error shown here is: <strong>null is not an object (evaluating 'previewOnHiddenField.value'</strong>))
    };

if i uninstall the navigation module as well as gin toolbar and switch from gin to claro with the starship install i get the following error:

TypeError: null is not an object (evaluating 'previewOnHiddenField.value*)
(anonymous function) — drupal.js:64
setTimeout
(anonymous function)  drupal.js:63
(anonymous function)  drupal.js:168
forEach
(anonymous function)  drupal.js: 162
(anonymous function)  big_pipe.js:153
Global Code - big_pipe.js:184

benjifisher → credited rkoller → .

Added a link to an article by Luke Woroblewski to the issue summary for more context.

rkoller → created an issue.

rkoller → created an issue.