yeah, I’m not sure why I particularly called this out as overly optimistic either… having said that, I’m sure we’ve been cautioned elsewhere that this not going to be an easy task. Happy to be wrong about that tho’ (and all the more reason for consolidating all that stuff here now!)

Their “Plugin Repository” allows an admin to see on one page what modules are installed and whether there’s an update available, click through to documentation, install/enable/disable, configure, etc.

You can choose to see only the modules that are relevant to your current core version or some future version, or specify that you want to only see modules that have reached a certain level of stability.

Glad you put this up. I personally like the direction you have here better. Unlike the plug-in manager, this UI is consistent with the rest of your major ideas (people and content) – thereby making Drupal feel less strung together.

Since there’s lots of people behind the plug-in manager project, maybe there’s a way to combine some of PM’s findings into this approach. Seems like the two share common goals, although I think PM is based on the assumption that all modules on D.O are accessible from the start – which is probably the wrong assumption to make. I tend to think that idea (list all mods) might have been based on how hard it is to find modules today – which should go away with the redesign of D.O.

Drupal needs to move towards having a layer on top of the modules to present users with turn key functionality. This could be called features or perhaps a recipes.
The non-tech user often doesn’t care what imagecache or views is, they just want to turn on their gallery. Having a feature would download, enable and configure any needed modules.

Development seed have done a great job with the context module where users can easily enable or disable a feature with a single click. A feature is a group of things in a context. This could be a 2 Blocks a view and a content type and a vocabulary to make up a news section feature. Tick the news section box and all the blocks, views etc are created and configured, quick and easy. Context shows it can be done, but can we have it in core? It would certainly be a lot better supported if so.

This is similar to the idea of install profiles where sane defaults can be set depending on a persons needs.

1. Please, for the love of all that is holy, do NOT put a “Select All” checkbox on this page:
a) Running out of memory by having too many modules installed is a serious concern.
b) There are sometimes modules that conflict with each other and you might have one or more of them in the modules directory as you are playing around with different solutions.
c) Even in the benign case where you don’t end up with either a fatal error or a blank screen after checking all modules, what it does is make the interface more and more complex. You thought it was hard to the setting you were looking for before? Try it when you have 52 *more* settings! 😉

2. I do not understand what that On/Off slidey toggle thing is for. We already have a checkbox to turn modules on/off, no?

3. The visual nesting of Views and Views Sub Module is a little bit awkward for me. My eyeball infers that if I check “Views” then “Views Sub Module” will automatically be checked for me, and often that’s not what I want. With this specific example, the choices would be (hope list items work on this thing):

Views

Views Bonus/li>
Views Bulk Operations
Views Export
Views UI

Of those, I only want to have Views and Views UI enabled. What I need is a way to check off only two of those without unchecking other 2-3 other boxes.

4. What does “more” do? or is that what expands the settings | permissions boxes?

5. Now that I see “bulk actions” up there, I’m wondering if the checkboxes aren’t intending to turn modules on at all. If so, how do you do so? Do you have to click each “more” on each module listed, then slide “On” to “Off” x 10-20 modules? If so, I predict a complete outcry. 🙁

Modules are designed to do one specific thing only so that they can be mixed and matched in infinite ways. This is the power of Drupal. But as a result, it is extremely rare that you are only turning on/off one module here. Normally, you turn them on/off in batches. For example, CCK is Content, Number, Text, Node Reference, OptionWidgets, User Reference, FileField, ImageField, Date… Ubercart is Cart, Shipping, Product, Store, Paypal, Inventory, etc.

6. Is the collapsible stuff collapsed by default or no? Admin Menu 1.0 collapsed everything on this page by default. This is great when you innately know that a new module stuck itself under “Other” or “Views” but if you don’t, you are stuck expanding 100s of fieldsets. No one’s idea of a fun time.

7. On that note, I think that I notice there are no more concept of packages. Does that mean this list would be sorted alphabetically? If so, why isn’t it? 🙂 And why is Backup & Migrate both enabled and disabled? Or are those just bugs in the wireframe?

Going to need to spend some time thinking about this. I think there’s a lot of good stuff here, like jump-off points to settings/permissions and update status info integrated directly. Just a little fuzzy about some of the details.

1. “Select all” doesn’t mean “turn on all of these modules at once, you crazy person, you” it means “select these all for some sort of batch processing.” That can be enabling/disabling/updating, and there are also drop-downs to filter the list. So you could filter by, presumably, package name or a keyword or whatever. I missed those initially because I was having heart palpatations about the inevitable torrent of support requests from users who locked themselves entirely out of their Drupal sites by enabling all core + contributed modules at once. 😉

2. On/Off slidey thing is an indicator of whether the module is enabled or not. You can use it to toggle on/off a module, but you can also use the checkboxes with the “Enable” bulk action for more than one. That renders concern 5. moot.

3. Visual nesting is still being discussed. What it probably is is based on package, but there are implementation and visual details still being hammered out. This is still in ‘wireframe’ mode.

4. “more” does indeed expand out so that it looks like the example at the top.

5. Addressed (see 2.)

6. Still in process (see 3.), but probably tTop-level “Views” is expanded, while sub-items are collapsed.

7. These are copy/paste bugs. Each of the sections (enabled, disabled, and “hey, buddy, this is stuff you have to deal with yet”) are alphabetical.

re:3: I’ve observed LOTS of people using the modules and config page (new and seasoned users), and the majority don’t know what to enable, so they enable all first. That said, while enabling all sub-modules under a contrib module may have several adverse side effects, I’m always in favor of supporting the natural inclination of the user – which in this case is enabling all sub-modules.

The trouble with doing this, is that often you end up with an overly complicated UI because of it. For example, If take this approach with Ubbercart, you enable like 20 modules, and after doing so, trying to configure a store is painful becuase you’re confronted with sooo many options.

In contrast, if developers could engineer modules in such a way that separates ancillary features from primary features, maybe the UI could take a different direction. Seems to me the right approach would be to have one checkbox for each module (no sub-modules), have sub-modules as config settings for that module, and auto enable the core features. For example, Views would have one check box to enable, enabling would automatically turn on Views, Views UI, and maybe Views Export, and the rest of the features would be enabled via config (like preferences for a given module).

I’ve been thinking about this recently but not done anything about it. We now have hidden modules in D7, so there’s probably nothing stopping someone from shipping with hidden modules, then enabling them programatically on form submit or whatever- the problem is how to generalize this (and we don’t have any core examples, or not yet).

I did a lot of the initial work to improve the modules page to its current state from what it was in 4.7. A lot of what I did ended up getting thrown away for various reasons, but most of the improvements I wanted then I still want. Now we have update status. Here are some things that are important. Some are concerns, some are different features.

1) The modules page serves THREE purposes. In order to be successful, this page must serve all three purposes.
a) Understanding what you currently have in your system. You need to know what is enabled, and you need to be able to get from this information to configuration pages. Currently Drupal 7 has gotten a little better about this with automatic help links, but it’s fairly weak.
b) Understanding what you can add to your system. When you install core, going to the modules page will allow you to turn on a number of optional components. This means being able to find out more data about those components. As you install new modules, this is the first place you interact with that new module.
c) Actually turning on and off modules.

2) Drupal has always used checkboxes for enabling and disabling modules. I HATE this for a number of reasons.
a) When enabling just one module, you have to click on the module, then scroll down on the page.
b) When enabling multiple modules, you select a bunch of checkboxes, which probably means a bunch of scrolling…then scroll down and hit submit.
c) There is no way to ask the user for install time decisions.
d) The use of checkboxes combined with the select at the top means that if you select a module, and then go and change the filtering/sorting to find another module, you’re probably going to lose the checkbox, because form data cannot easily be preserved across page views. You can mitigate this somewhat with clever javascript, but that can also add more confusion.

My idea here has always been that we want ‘enable’, ‘disable’ and ‘uninstall’ buttons here. These would use ajax requests so that when you hit enable, instead of a page refresh, you see the little ajax notification we have, and then any messages from the module will appear right there. Possibly with a question. “I need to enable these X modules to enable this. Proceed? Cancel.” Then ajax and the module is enabled. If modules are in a group, enabling all within a group would be a nice idea.

Note that the argument against buttons has always been that it’s a pain if you have to enable a lot of modules, but that’s only true, IMO, if the button leads to a page refresh every time. With an AJAX enable, you’re left where you were so you can keep enabling things. And if you can enable in groups, then you get a pretty big win, though I can’t quite envision a functional UI for enabling in groups.

3) One unfortunate problem is that the concept of a ‘project’ (which is what you donwload from drupal.org and what you update) is not the same as a module. A project might contain many modules, or it might contain just one. A project might have one main module and a bunch of sub modules, or it might have many unrelated modules. It’s difficult to do this kind of grouping. While Views and CCK have an obvious main module and many sub modules, others don’t.

Worse, packages can contain the project that created it, plus other modules that are downloaded and attached to it. Look at Views and Views attach. Views attach adds itself to the Views package, but in itself is not part of Views. But in terms of discoverability, it does need to be near Views.

4) The ‘package’ keyword that all modules have has not been as successful as I wanted it to be. Many modules treat this as a ‘category’ which it expressly is not supposed to be, but some module authors are very adamant about this. This has resulted in an unfortunate mishmash of packages on the modules page, vastly diluting the utility of it. We need to find a way to address this, and I’ve no idea how to do it.

5) It’s really easy to have a hundred modules. A modest install will have over a hundred entries on the page. The design you have here takes up a lot of space. We need to come up with a design that makes it very easy to sort through a LOT of modules. The gadgets you have on top look good, but you’ve only got enough space to show 8 modules in your mockup. That’s a very, very small slice of the available modules. I think we need to come up with a way to show the absolutely minimal information. Module name, Project that owns the module, and maybe augment Package with module categories. We could initially show modules by project, but we could switch to ‘Category: Views’, ‘Category: CCK’ or some such.

Then, when you have a module, you have a ‘more information’, which will show description, links to config and help for the module, and anything else that makes sense there. Modules which happen to be named the same as a Package could emulate the module/sub-module bits nicely. By being explicit about projects we can be less confusing, and while I haven’t done the mockup work to really see it ot be sure, right now I think having the description right there is actually a detriment. There’s too much information initially and the descriptions are only read once you get to the modules you’re looking for anyway.

In the “permissions” page all things are listed alphabetically. In the module’s page there is attempt at “groups” of modules. Often it is so very difficult to find the one I installed both because it is not listed alphabetically and because it is difficult to understand or predict what group it will belong to. The only way out is to use the “Find” option in the browser.

“”My idea here has always been that we want ‘enable’, ‘disable’ and ‘uninstall’ buttons here. These would use ajax requests so that when you hit enable, instead of a page refresh, you see the little ajax notification we have, and then any messages from the module will appear right there. Possibly with a question. “I need to enable these X modules to enable this. Proceed? Cancel.””

+1 for this. In fact without this there is no meaning in releasing D7. This needs to be backported to Drupal 6 also as a module.
In addition to the question of “I need to enable these X modules to enable this. Proceed? Cancel.” I would suggest a link in the same line to “Enable permissions”. This too can be a ajax box, overlay or inline/pop-up, unless of course the modules in D7 get default user and admission permissions enabled automatically at the time of installation.

“There’s too much information initially and the descriptions are only read once you get to the modules you’re looking for anyway.”

Descriptions can be shown as just balloon tips on hover. For core modules there is meaning in telling descriptions but for the modules that I download by myself and install I do not find any meaning in adding descriptions on this page because I have already read about them, sort of understood what they are for and then have proceeded to download and install.