#Usability

I updated the issue credit, removing credit for a number of old rerolls where the contributor did not add anything else to the issue. I left credit for a couple people who were doing the reroll in the context of a mentored event as their first contribution. I also added credits for a number of reviewers.

I'm not able do do the review myself at the moment, but at least having the crediting in order should save some time.

Saving mentor credits as per #33.

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

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

Since it's been 3+ months without a follow up going to close out. If still a valid issue please please re-open!

Thanks all!

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

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

I'm not entirely convinced that we should not allow SDCs without meta:enum to be used in XB because it is possible to achieve an acceptable UX without providing meta:enum, albeit not in all scenarios. For example, for margin-top, you could choose to provide options '4px', '6px', and '8px'. In this case the same value could apply both as the human readable and machine readable value.

Hi Lauriii,

According to the 🐛 Don't raise exception when an enum value is missing from meta:enum Active , all SDC prop with an enum has also a complete meta:enum. We made the meta:enum optional at the YAML declaration level, but the parseSchemaInfo() method is aligning the values:

         // Ensure all enum values are also in meta:enum.
          $enum = array_combine($prop_schema['enum'], $prop_schema['enum']);
          $prop_schema['meta:enum'] = array_replace($enum, $prop_schema['meta:enum'] ?? []);

Source: https://git.drupalcode.org/project/drupal/-/commit/166350f2acc649d60e4da...

@divya.sejekan, thanks reviewing my previous code.. Please review this changes too. I had attached the reference image for review the UI changes.

@rkoller, thanks for the info, let me try this

Thank you for working on the issue! I've tested MR8, two observations:

1) It looks like the set radio buttons has no effect at all. no matter if i select main-only or full-dom, each time all the headings of the entire dom are displayed in skipto

2) the label for the first radio button (Only within the <main> element) is broken, main is being hidden and you only see

Only within the
element

probably no need to use angle brackets. will have to think about the wording

Thanks for the initial work! I've taken a look at MR7 and i am not sure if using javascript for adding a suffix is the right solution here. i guess the suffix itself could be solveable simply with plain php and the field api. by adding something like

'#field_suffix' => $this->t('percent', [], ['context' => 'skipto']),

to

$form['buttonSettings']['positionLeft'] = [

would solve things (except the wrong label for the number field, but that has to be fixed in 🐛 Improve the microcopy on the settings page Active - still havent had the capacity to work on it). imho it is always preferable to go with to write something out instead of using a symbol like % for screenreader users. but talking of screenreader users, i've tested the solution in MR7 as well as my suggested one and neither is being announced when the numbers input gets into focus. I gotta do some more research if that is maybe a shortcoming in core in general. I'll set the issue back to NW.

I need to self-review this yet, but feels close. Bálint changes look good to me, thanks!

Applied MR!7 , Patch gets applied cleanly.
% is displayed now as a suffix to Example Number Field.

Steps Followed :
1. Install drupal, Install Skip to module
2. Go to /admin/config/user-interface/skipto

RTBC++

Since there's been no follow up in 3 months going to close out, if still a valid task please re-open

Thanks all!

Okay, thanks for your time. I'll fix the tests. To be clear, are there specific tests that need to be passed or all of them?
I am not sure if some tests may be failing due to something unrelated.

This week, instead of discussing a particular issue, we have taken a general look at the skipto module. I wanted to get some feedback about its general direction. After there is no issue to comment on I use the comment here to provide a summary. These are the three issues that got created:

✨ Make the skipTo module configurable on a per user basis Active
📌 Add a percentage suffix to the position option Active
📌 Remove main-only option from heading checkbox list and add radio buttons instead Active

The other detail about making div and nav lower case will be covered in the already existing 🐛 Improve the microcopy on the settings page Active . The rest of the raised issues will get issues upstream at https://github.com/skipto-landmarks-headings/page-script-5 :

• If the focus is moved from the last available heading to the about skipto.js the focus outline remains on the last heading
• the form of the landmark regions is hard to read due to the front loading of the landmark type and its potentially redundant nature - several landmark regions starting with for example Navigation: in a row
• the indendation based on the heading level makes the heading list very hard to read - and the heading level is already communicated by the number

The MR now applies to D11.2.0, thx!

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

Working on this.

I have found the solution for add % suffix to position field..

Im working on this issue

"This gets quite tedious"
Not sure "tediousness" can be an issue.

Multi-step uninstall is pretty common to me. I find this process useful instead to better understand how that Drupal instance is made of.

Following though..

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

Believe the API change will need a CR

benjifisher → credited rkoller → .

It seems security_review has a similar check: https://git.drupalcode.org/project/security_review/-/blob/3.1.x/src/Plug...
Based on a list of unsafe tags: https://git.drupalcode.org/project/security_review/-/blob/87d5f3ea84b0be...

Thanks for fixing those, seems we are getting test-failures now, re-ran twice

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

Any SDC that has enum without the necessary meta:enum will no longer be available to XB users, and will now appear in the list of disabled XB components at /admin/appearance/component/status, with an explanation of why.

I'm not entirely convinced that we should not allow SDCs without meta:enum to be used in XB because it is possible to achieve an acceptable UX without providing meta:enum, albeit not in all scenarios. For example, for margin-top, you could choose to provide options '4px', '6px', and '8px'. In this case the same value could apply both as the human readable and machine readable value.

We could still allow translating the enum options but keep the machine readable names consistent across translations or we could simply prevent translating these enums.

I don't think this needs to block this issue from being committed. It seems that we could loosen this requirement in future if this would require a non-trivial amount of work to change.

Moving this to Claro theme as per #26 - IMO this could be closed.

Closing based on the last 2 comments and lack of activity here.

It's been 3 months since #92 and 9 years since the last comment before so I'm closing this for now.

It's been 3 months since #33 and 10 years since the last comment before so I'm closing this for now.

MR

https://git.drupalcode.org/project/drupal/-/merge_requests/10289/diffs

Moved the config translation hook over to the NodeHooks file and removed the additional NodeLocalTaskHooks.
Fixed some lint errors.

https://git.drupalcode.org/project/drupal/-/merge_requests/10289

benjifisher → credited drubb → .

benjifisher → credited franz-m → .

benjifisher → credited jurgenhaas → .

benjifisher → credited martin mayer → .

I am adding credit for the users mentioned in Comment #51.

Left comments on MR

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

Closed 🐛 Trying to remove code component from page immediately after attempting to edit it gives 404 error Active as a duplicate of this.

All tests passing 🎉

Something that doesn't have e2e tests is the code editor, but we need to fix it to at least send the same values in enum as meta:enum.
Bálint volunteered to write this.

@balintbrews For now I'd expect to send the same added values as labels. The only thing to take into account is replacing dots with underscores. Something like:

const getMetaEnumValue = (x: string) => x.replace('.', '_');

const enumValues = [
      '3.14',
      'b',
      'c',
    ];
const metaEnums = Object.fromEntries(new Map(enumValues.map(value => [getMetaEnumValue(value), value])))
console.log(metaEnums);


//{
//  "3_14": "3.14",
//  "b": "b",
//  "c": "c"
//} 

Thank you rkoller for this suggestion and the accompanying documentation. I will work on this soon.

Amending attribution.

xjm → credited effulgentsia → .

Belatedly adding discussion credits per #97 and #118.

@dqd, Folks mostly won't see comments on closed issues, so a followup issue is better.

xjm → credited tim.plunkett → .

Discussion credits as per #9:

Just discussed this with @lauriii, @bnjmnm, @xjm and @tim.plunkett.

If we're going to do that let's also credit the reviewers. :) Saving credit for historical reviewers.

xjm → credited star-szr → .

Adding missing credits for the major issue triage as per:

@webchick, @catch, @Cottser, @effuglentsia, and I agreed that this is a major issue

Thanks!

Sorry took a little longer than anticipated, but my eye problems have flared up again, making longer text where you have to focus a bit cumbersome. I have taken a look at MR199 and played around with the merge request. I’ve noticed a few things:

1. It looks like there is some additional padding between the Enabled services heading and its table underneath - that way the heading looks pushed towards the Add service button and the gap between the heading and the table is way bigger for the Enabled services compared to the Disabled services. It is probably due to margin-block-start within the .tabledrag-toggle-weight-wrapper class selector. I suppose due to the fact that the other pages that are using the enabled/disabled pattern don’t have the option to sort in consequence they also have don't have the Show row weights link on top of the table, and the div that is containing that link has that margin causing the larger gap.
2. The drop buttons in the Operations column are way bigger than usual - they look like twice the height compared to the drop buttons on for example admin/structure/display-modes/view, admin/structure/view, or admin/content.
3. The status checkbox pattern for enabling and disabling services works as expected, but it has a few downsides.
   • It is introducing a new pattern for handling the enabling and disabling of services, that is breaking with the existing one users are already familiar with - the other pages are using an Enable and Disable options on the drop buttons in the Operations column.
   • With checkboxes in place you have one additional click for saving the configuration, after selecting/checking all the services you want to enable or disable.
   • Those status checkboxes make you, the user, think. Depending on what you are trying to change, for disabled services you want to enable you might catching yourself thinking do i select the services to enable by ticking them, while the other way around if you want to disable services and you are still in that “selection mindset” you might leave those services checked you want to disable. Also due to the fact that the position of the service is only changed when the save button is clicked you might have both sections with checked and unchecked services. The cognitive load is high that way. :/
   • Save configuration button label and the Status<code> column header are decoupled semantically from the section headings <code>Enabled services and Disabled services.
   • And finally the width of the columns differs between the two tables.
4. If you enable or disable all available services, either way you are getting No services have been created yet.. This is sort of inaccurate since Klaro is shipping with 23 services by default.

In the following a few suggestion how to tackle the aforementioned points:

about point 1: If possible I would reduce the margin between the Enabled services heading the associated table.

about point 2: The other pages using the enable/disable pattern are using the extra small variant size for drop buttons from the Drupal Design System. I would suggest to stay consistent in regard to the styling. →

about point 3: I would suggest to follow the pattern the other pages with the enable/disable pattern are using. Remove the status column and adjust the width of the remaining columns in-between the two tables. On the drop buttons of the Enabled services section, keep Edit the default option and add a Disable option as secondary action. In the Disabled services section make Enable the default option on the drop button and move Edit to the secondary actions. If you enable a disabled service it is directly moved to the enabled services section, same as the other way around.
The only slightly “odd” detail about that pattern is having those handles for changing the order of enabled services by dragging them vertically. My first impulse was testing if it would be possible to disable services by drag and drop. But it was clearly communicated that dragging a service to a different section doesn't work/is not intended AND the disabled services section doesn't have those handles.

about point 4: Uncertain if it might be too granular, but the most accurate approach would be to check if there are no services created yet and then show No services have been created yet. in the enabled as well as the disabled services section. If there are services created, and none of them is enabled use something like There are no enabled services. in the enabled services section, if none of them is disabled use something like There are no disabled services. in the disabled services section.

Since this issue was already committed over a year ago in a previous major release, the best thing to do would be to search for or file a big report against core documenting the regression. Maintainers usually will not see comments posted against closed issues.

Restoring credit.

Retroactively saving the credits from that commit, for what it's worth.

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

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

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

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

.

This is a duplicate: https://www.drupal.org/project/drupal/issues/2621630 ✨ Make Search Field for Module Install/Uninstall usable Postponed: needs info

Consensus seems to be this is an accessibility gate break and should be closed.

Amending attribution.

Amending attribution.

Amending attribution.