Make dependency list hidden on modules page until requested

Yes, lets do this!

I would love if we can use the http://www.yoroy.com/2009/floaded-state-harmonicas pattern for showing the dependencies rather than a modal dialog or separate page. I believe we have some ideas around the update page which if thought out fully, can make this pattern applicable to any table.

We need to think about how to show missing, or required by - ideally this is less common and we can handle it more nicely visually (e.g. not a screaming red).

Actually being able to search for a module is really close over at http://drupal.org/node/396478 .

This needs work :) A patch or perhaps detailed designs?

Like!

One of Jstollers mockups provides a solution for that. It may be far from perfect, but putting all additional information that is not visible in the bare list into a collapsible might make perfect sense.
It has some flaws insofar as dependencies need not be checkboxes - one cannot switch them on or off anyway.
He even put my beloved Operations in there, too :'(. But it may make sense.

Yoroys flooded state harmonicas would be the perfect high-end solution :) This would need testing: do people want to see some repeating stuff in the rows or not? Indications if updates are needed might make the most sense indeed, as they should not be too frequent in a well-updated site and gives a much better place for update information.

That mockup looks a lot like http://drupal.org/project/module_filter ...

On another point, it would be nice to have a developer switch to put all dependencies back in. Otherwise, we have the situation where you edit your module's info file and you've no way of really checking you've done it right...

I am also in favor of not showing the dependency info by default, but really think it should be available, either through a javascript-link on each module description area, or one at the top, perhaps a separate tab/url that lets admins work and use the nice filtering and search options in "dependency mode"? So what I am saying that I actually appreciate the dependency information very much in certain situations, but normally would like it hidden. So "who cares" is not really that black or white.

How it compares when simply removing requirements info:

An unfortunate side-effect

Making it work in a default collapsed state?

There are certainly cases where the dependency information is important to get to. What is the plan here, to remove it completely so it is in fact not available anymore at all with only Drupal core? Does that mean moving it to contrib, then?
I hope it will not be totally REmoved, just moved.

I haven't heard anyone suggest that it be completely removed. Just hidden from view until it is called for.

It looks good. What does the "on"/"off" switch do though? Does it enable all submodules? Only the "main" and its requirements perhaps? What state does it have when not all submodules are enabled?

That looks good. We can easily achieve this allowing modules to set their 'parent' module (which defaults to the module itself).

However... That doesn't work if the parent module is unavailable and there is no human-readable title or description to display for the fieldset.

// Edit: @jstoller below: Oops, sorry! I'm following all these issues about the modules pages. Sometimes I mix them up.

In order to prevent too much fragmentation of effort, I'd suggest going to #538904: D8UX: Redesign Modules Page for a more general discussion of the module page interface. This issue should stick to the task of hiding dependency information.

Admin Menu has long had (maybe in earlier versions?) the option to collapse Categories on modules page.
I liked this at first, but in the end it was a drag because one had to open everything to find anything.

Most of yoroy's mockups seem to collapse module groups (like Views and everything that belongs to it) which should be fine.
It is a fine line, though, to collapsing too much like Categories. It is not easy to find the sweet spot in what to hide and what to show and at the same time keep more advanced users and Novices happy at the same time.

In conflict I would advocate to put Novices first and offer the power-users options in the backend to show stuff just as they want it - simply because power users will find the settings for tweaking the display while Novices probably won't.

Yeah, I'm not interested in discussing the tension between module packages and module categories here. How I imagine it would work re: the dependency info:

- Right now we add a whole lot of noise by explicitly mentioning all the bits and pieces that are OK already: the 'requires X, wich is enabled' bits. Lets drop those from immediate view
- The 'requires Y, which is disabled' bits are kinda 'meh'-level information: enabling required modules should just happen (I think it already does that, no?)
- The 'requires Z, which is *missing* is the most important information, because that requires user action to be able to solve it. I imagine this would somehow be made immediately visible.

Seeing all dependencies/dependees (?) can be made an option but we can put that deeper down in the ui for the reason eigentor points out: it's advanced stuff for the expert user who is more likely to find this info if she really needs it.

Agreed w/ @yoroy, the only thing that needs to be immediately apparent is if a dependency is missing. The user is already asked to confirm if they wish to enable dependencies that are not enabled. And, IMO, it is rare to need to know if a dependency is currently enabled.

Is it safe to remove the "Required by" information 100% of the time? That seems like the kind of thing we could take care of quickly (and get in a backport to D7!)

@jenlampton Is it safe to remove the "Required by" information 100% of the time?

In some cases, there's a module enabled that you can't disable due to it being required by another module. That's when it's handy to see the Required By information. Maybe a collapsible do-thingy like in webchick's first post. Or maybe a Tooltip of some kind?

@jenlampton (and get in a backport to D7!)

For Drupal 7, might be better to hit up http://drupal.org/project/module_filter or http://drupal.org/project/simplified_modules ;-) .

I agree to hiding dependencies but they should not be removed entirely.

Modules you cannot disable because other modules depend on them have a greyed out checkbox.
So you cannot do anything wrong, which is good to start with.

Should we display a tooltip "cannot be disabled because XY" when someone tries to click it still? Note: only click, not hover. Hover thingies often add clutter and aggravation.

Novice:
will be angry "why can't I click this freakin checkbox". Is at the present situation also, little chance of understanding the dependency thing. So would be an improvement to him.

Pro:
Knows about dependencies. Might pause for a little moment when presented with a greyed out checkbox. Good chance he looks into detailed information as to why this module cannot be disabled and what other modules depend on it.

Note: both groups gain nothing from the present layout. Removing dependency not necessary, put them into collapsed "detailed information" "more info": check.

I agree to hiding dependencies but they should not be removed entirely.

Can you please tell us why?

Modules you cannot disable because other modules depend on them have a greyed out checkbox.
So you cannot do anything wrong, which is good to start with.

Disabled (greyed out) checkboxes only tell the user he can't use them, but it doesn't tell him why. In such cases showing a dependents list (not to be confused with a dependency list) may be handy.

A slightly related issue I often hear about is that it's annoying people cannot directly disable module X, because Y depends on it. They have to disable Y and then disable X, which requires two separate actions. When enabling Y, however, X will be enabled automatically. Can't we provide the same behavior for disabling modules? That would kill two birds with one stone:
1) We can get rid of the dependency and dependents lists entirely
2) With an extra confirmation page, we can still show dependencies and prevent users from breaking stuff by accident AND we can disable loads of modules in one single action. We can create a separate issue for this if there isn't one yet.

I'm coming to think that removing the dependancies entirely is going to ruffle too many feathers. All I want is a cleaner UI, and since the list is in there already, I'd be willing to settle for hiding them, as per the original screenshots. Plus, maybe that means we can get this into D7? :) :) :)

What do others think?

I'm okay with that. Would it work to put it in a collapsible "more information about this module" section? There may be more information we want hidden. I don't mind reinventing the wheel, but only if that actually adds something.

I support an idea of hiding dependencies rather than removing them completely. Even if disabling dependent modules will be automated (which would be great! because I can't remember something more frustrating with this page than scrolling for 5+ modules, dependent on specific one and disabling them 1 by 1, each time waiting for page reload, just when I want to update one specific module) still sometimes you just need to know why certain module is there, what is it connected to. I do not want to turn module off to find this out.

The detailed information should definetely be available "somewhere" (not removed).

I suggest a horizontal "tab" (read: "mode") that shows the modules in "full details view". Whatever we have searched/filtered or listed through the vertical tabs on the left side, would be shown with full details on that tab.

It does not have to be auto-loaded with the rest of the information on the initial page load, if that may increase the time it takes to get the full simple listing.

What about collapsible table rows, or something similar?

I am far more interested in collapsible table rows than a tab. The module details should be accessible within each individual module listing, independently. I see no reason why I would ever want to see an entire page of modules with dependency information ever again. The story I foresee is something like this:

1. User is browsing module page.
2. Users sees a module and isn't sure why it is there.
3. User clicks the link for more information about that module, expanding a hidden div.
4. User examines the dependency information and disables the module, or not, before moving on with her life.

As you can see, the dependency information really only becomes interesting after a module has been located. Switching to a different tab would be too disruptive, requiring the user to find their module of interest a second time. Besides, I have other plans for tabs on this page. :-)

#25: collapsible table rows could also be interesting, but IMO there should be a way to get everything expanded easily without lots of clicking: one whole page showing all details for all modules without having to expand one by one first, which would be a nightmare.

@Taxoman:
What is the use case for wanting to see all dependency information on all modules at the same time? I've only ever seen this information be useful when examining a specific module. Assuming the information was quickly available, with one click, without a page load, under what circumstances would you want to expand all modules at once?

#29: for example, sometimes it is practical to be able to search across all installed modules with Ctrl+F on one page to get an overview on which modules on the current site depends on a certain module.

Personal preference and habit (which takes time to change for some people) also affects the user experience: for some of us it just feels better to have one full overview "someplace" instead of not having the option to view other than just bits and pieces, even if one strictly speaking have the information we need available. This latter argument is a kind of a "peace of mind" or "quality of (work) life" aspect that also have some value.

I am also wary of not being able to foresee the various use cases until after this option is gone.

So I guess right now it makes me feel "safer", knowing that I have that information readily available when/if I need it. And yes, I have definetely found it useful until now.

Perhaps we could phase it out in two steps, one which leaves it on a separate page for some time, then after running some statistics and having had some time to see how the new arrangement works, it could eventually be removed entirely if we see that we actually dont use/need it.

And further on that:
Psychologically, perhaps especially for new users, having a page that gives a full overview can be important in the process of getting into Drupal, getting the feeling of mastering it and having an overview of it all.
I fear it may be a mistake to underestimate the value of such an overview.

After all, we are all aware of the (ongoing) challenges of lowering the learning curve.

It is easier for us who already have that feeling, to accept a more "efficient" page arrangement, but I dont think that is the only valid angle/view and concern here.

@Taxoman We need to be careful with that though, the usability studies show that too much information on a page can be overwhelming and causes people (especially new users) to shut down and fail at whatever task they've been assigned. Yes, an overview is useful, but let's not scare anyone away by giving them more than necessary.

yes, that is why I suggest having a separate page for all that info.
I think the direction of these discussions are a good one, just dont want to loose (too abruptly) the option of having a page with all information available. Usability studies do not provide a one-answer-fits-all anyway, they are general pointers for the main focus, not necessarily suggestions to throw away all other options entirely. There will still be a multitude of "user types" out there with various preferences.

That's actually something we haven't really touched on, but I think it's a good point. Should we build different pages for different user types rather than focusing on trying to improve this one display to make it work for everyone? We obviously need to improve the page we already have (and we are), but what about adding other pages?

I'm going to duplicate this comment over in #538904: D8UX: Redesign Modules Page since I think it applies to a larger audience than those of us who are frustrated that our browser's "find" commend doesn't work on the current modules page ;)

This is why we'll be conducting interviews, so that we don't have to weigh individual opinions or preferences. In general we should be very careful about multiple pages. The admin IA is fragmented enough as it is, we should try very hard to *not* add stuff but focus on removing things.

For anyone who wants to quickly get CTRL+F working on their module pages, here is a greasemonkey script that should hide the dependencies and add a link to show them again in case you need. If you have any questions / problems with this script please contact me directly or open a separate issue to prevent noise in this one.

[renamed .txt so drupal.org will allow the upload]

The modules page has been revamped since then. We can search too :)

x

Unfortunately this issue was closed years ago, but with the "needs backport to D7" tag still on it...

I think there should be something we could do in Drupal 7 to hide the dependencies by default? (Not a full redesign of the page like what went into Drupal 8, but something more limited?) It's really annoying when you get the paragraph-long dependency lists on there; it definitely makes the page very hard to use.

As far as I am concerned, this is fixed in the contrib space by https://www.drupal.org/project/module_filter.

That module helps with the on-page search issue, but not sure it does much for the other problems mentioned in the issue summary... I think there's a good argument for this to be improved in core.

I would like to see similar to the Module Filter module, plus an Expand All/Collapse All. I don't like hover because you can't easily copy and paste if you need advice or want to Google something in that list.

I am strongly opposed to completely removing the information.