Provide access to action links in the modules page on small screens

I will review this later.

Please keep in mind that stating its "major" needs either some empirical evidence or community consensus. Since this has not come up before, I am marking it back down - I hope you can be mindfull that your gripe, is not necessarily everyones gripe.

Hi, thanks for working on this. It would be great if this issue only moved the configure link to be visible all the time. I think that configure is an 80% use case and the other two aren't as commonly used. What do you think?

This would also make it possible to keep each module on one line, which is good because the module listing page is already long, we are effectively doubling the length of the page here.

It does seem we went a bit overboard here and put away too much behind the little triangle, so I support this proposal. And immediately have additional considerations: Why did we add icons? Why are the links in this order? I'd expect 'Configure' to be the first. Should the links be blue?

@lewisnyman: not sure about singling out the configure link. If there are permissions, it's quite likely you need to set those up as well.

I am not that convinced we want to go to two lines here again. Will make the module page a lot taller.

Thanks for patch, It is working fine.

Can we provide better visibility by just hovering on module link and it will show all action links associate with module.
I think it will be effective to avoid making module page taller.

What about doing something like the following? Its going to break with our idea of not having loads of variating stuff on this screen - but I don't see an alternative solution, that doesn't completely double all of our elements.

Give drop button a try and see what it looks like. It's a bit messy - since then we don't need the > but then again do - to display the machine name.

It's quite hard to do this cleanly, not displaying them was a design choice by default - retrofitting them in is a challenge. Without sacrificing core design qualities. You are right the page is long, but your proposal makes it 50% more longer. I prefer ease of finding and enabling modules, over any of the other benefits.

I am not sure, what constitutes the change - there is nothing that changed. Your simply restating your original arguments in a different manner. There is no empirical evidence, or significant community feedback that this is a big issue in either the original design issue or this issue. So moving it back.

@jcnventura I'm a bit confused why this patch doesn't create a dropbutton in PHP and then just render it inside the template?

+++ b/core/modules/system/css/system.admin.css
@@ -200,6 +203,15 @@ small .admin-link:after {
+  width: 8.5em !important;
+  text-align: center !important;

Is there a way to get rid of the !important here? It doesn't really feel right.

I've reviewed this during DevDaysSeville.

As a starting remark: I think the current usability of the Extend page is bad to start with. Neither the module name nor the description are clearly links. Clicking on the name ticks ticks the tickbox, while clicking on the description extends it on reveal additional information (machine name, version, requirements). Once a module is enabled, clicking on the description also displays links to help, permission and configuration pages, but nothing indicates to users that any of that functionality is there.
On a small screen, the description is not visible, therefore it cannot be expanded, and users can't get to the information and links.
Before

The patch moves the links for enabled modules into a dropdown list which is visible at all times, and also on small screens. This dropdown list is also consistent with functionality at other places where an item has several options (such as editing an entity type).
We discussed a fixed width for buttons for a cleaner look, but this is likely to break with interface translations where the words are longer.
So this is certainly a usability improvement, and probably also better accessibility.
After

However, so far if a module description is very long, it just affects that one text that either breaks off or that the user needs to scroll sideways to read. But with this patch, the dropdown buttons are placed on the right side of the longest text, which means a single over-long module description moves all buttons of that section out of view.
Is there any way of fixing that? For example by forcing too long lines to wrap?
After - with a too long module description.

Thanks, that looks much better. Personally, I much more prefer too long descriptions to wrap anyway instead of to force me to scroll side ways.

But something goes wrong there if in a section the enabled modules only have "Help" as an option: Then the button is off too far to the right. Once there is one module with "Configuration" then everything is fine again. See screen shots.
only Help

Help and Configuration

Thanks,
if other buttons like this have the same padding/margin then it's fine to use this here as well. If it needs fixing then it would need fixing in general.

The patch works. Drop-down buttons are available for the enabled modules. Users are therefore able to access the action links at any screen size. Without the patch that information is totally inaccessible. So this is a great improvement.

The drawback is that the module description text now breaks off at a certain point, and users only can read the end of the text once they have click on the description to expand that part. On small screens the text is not available anyway so we don't loose anything.
In practice, texts that are too long are not fully visible on the screen anyway, as it requires scrolling sideways.

So basically the patch changes one problem (scrolling sideways) with another (text breaks off), but the gains of accessible actions links outweighs this in any case.
So, for me this is an overall improvement.

Discussed at UX meeting on 2 May:
The cutting off of the text is less of an problem because when the text becomes too short to be useful, it is hidden anyway as a low-priority column.
(Other tables have a link to toggle between "Show all columns/Hide lower priority columns" on smaller screens, but this is not displayed on the Modules page, probably because there are several tables on the page and not just one.)

Concerns are about varying width of the buttons. On other tables all buttons have the same options are therefore the same width, even if they then change their width when the users clicks on them. Maybe this can be helped with a minimum width?

There's also something wrong with the theming of background of the active option, that doesn't go over the whole width. See screenshot comparing it to a similar dropdown on the content types page.

Modules page:

Content type page for comparison:

Link to the recording: https://youtu.be/tKm4-MCUzSg?t=53s

About the change in general: yes, looks like we over-designed this and hid important links. The dropbuttons aren't pretty, but the current situation with the links simply not present on small screens needs to changed.

## Review:

On smaller widths the buttons should still be floated(?) to the right side:

---

There's also something wrong with the theming of background of the active option, that doesn't go over the whole width. See screenshot comparing it to a similar dropdown on the content types page.

This is still the case. Maybe needs a width:100% on the anchor tag there.

I would say that works - and most importantly: it gives users access to these operations.

The attached screenshots show the operation links on a large and smaller screen, with the description text expanded, and also in a right-to-left language.

I've updated the issue summary with ifrik's most recent screenshots (thanks ifrik!)

Test had failed, but then run again and passed, so I put it back on RTBC

Yeah, I thought it might.

Too bad this didn't make the 8.4 deadline, but let's make sure it gets in to 8.5!

Thanks everyone for the work so far on this issue. I agree it's an important change.

I think this may need more thought as far as backward compatibility goes, I'm wondering for example what an admin theme would need to do to compensate for this. We would at least need a change record if we're changing the structure of this page.

What we could do here is leave stable and classy alone (don't update the templates to print module.operations) and change the core (core/modules/*) markup and CSS as well as Seven (and Bartik if we want too). That should make this no longer a breaking change for third party admin themes, and those themes can still choose to adopt this pattern if they haven't already by printing module.operations and styling as they wish.

+++ b/core/modules/system/templates/system-modules-details.html.twig
@@ -59,17 +60,15 @@
+          {% if module.operations %}
+            {{ module.operations }}
+          {% endif %}

+++ b/core/themes/stable/templates/admin/system-modules-details.html.twig
@@ -57,17 +58,15 @@
+          {% if module.operations %}
+            {{ module.operations }}
+          {% endif %}

Minor: Unless there's wrapping markup or similar, this type of if block is not needed. https://www.drupal.org/docs/develop/coding-standards/twig-coding-standar...

We should still work on this for Drupal 8.

This still needs to address the BC issues in #65. Thanks!

Doesn't apply to 9.2.x

A re-rolled patch against the latest 9.2.x.

Re-rolled patch for drupal 9.2.x as patch 77 getting error.

I've been working on #3012004: Add a link to the module's drupal.org project page in the module admin page, merged into #2906547: Add links to Drupal.org project pages to module listings in /admin/modules, and found this as a related issue. Sounds important. Tagging for Bug Smash. Will see if I can find time to move this forward again.

Conflicted with #3216341: Provide a module-specific permissions form. Rebased.

This seems like a massive usability improvement 🤩

It looks a bit odd visually, but I think this is a case where it's reasonable to decide that usability should trump aesthetics:

Review

1. I found one visual glitch when using Seven:
2. There's no support for Claro yet. 😅 I think this is probably a hard blocker at this point, because Claro is very close to becoming stable (not experimental anymore). And … that would actually be a very cool strategy here: if we'd do this only for Claro, we avoid the BC break for classy and stable, which means we could do this right away!

This has been discussed in usability meeting on 23 Sept 2022 as part of another issue #2035079: [PP-3] Figure out what to do with the install/uninstall modules page and I made a mockup how it would look like in Claro. We didn't revisit the issue after that.

These images are from the other issue I linked here

Think this could be WCAG SC 1.4.4 Resize Text & 1.4.10 Reflow. Running with 1.4.10 for tagging.