Modules page

The only thing I'm not sure of if is how I should order the modules in categories.

I haven't yet played with D6 so maybe this already happens this way but.. It would also make sense to have any alerts for updates (update status) be shown on this page.

Craig Bertrand

I was thinking about a sloution for categorizing the modules when we'd use the left and right pane. We could maybe create sortable columns in the left and right pane. This way users can choose between sorting the modules by name, or by category.

By the way I like the screen shot of the modules page that just has the module name.
an idea is to have the module info section toggle down when the module is selected showing the description and the other links I mentioned.

except the needs updating link that should be represented while collapsed and open(maybe a alert color border or icon or both)

Craig Bertrand

Agreed this is so true!

I have simple sites like this one.

http://katieandbrent.rockiesweddings.com/

running modules on this site are...

comment
contact
drupal
help
Legacy
Locale
Menu
Path
Profile
Statistics
Taxonomy
Throttle
Tracker
Upload
Gallerix - with widget engine modules as well
Image -entire group
Notify
Flash Gallery - not linked any longer
autologout
Poormanscron

When I go to enable the modules which normally requires doing it in two goes Fire foxlikes to go to a white page and then when I refresh the modules are enabled and installed.

I just feel that we should be able to do all of this without these agreed excess page loads for all these basic operations

Johnny
"In Drupal We Trust" - the best online solution since Google!
http://mybanffphotographer.com - using Drupal since 2005

As a Newcomer and beginning to havely test different Drupal versions installations on my Local Server for testing
Themes and the overall performance of different Modules I really get clicking all the time. I agree that the Modules page should not be expanded by default.

Cheers
Wolfflow

I like the idea of an ajaxy interface and some way for arbitrary groups of modules to be made (and automatically collapsed)... but instead of building an entire interface for pop-up configuration when a module is enabled (which could get obnoxiously long) why don't we just have some sort of system that displays relevant links? I know that's basically what admin>>by module is for, but maybe we could just move those links to the modules page itself.

Hi All,

I've tried to create a new design for the module interface. I really believe this will approach most of the needs and wishes previously discussed. Please give me some comments about the design.

The whole idea is an AJAX interface which enables administrators to enable and disable the modules, without a page refresh. The suggestions of integrating the permissions with the module page, is in my opinion indeed a really good idea. I've already created a module for inline popups which I can use to display and submit Drupal forms. This module can be used for such purposes as configuring the permissions at the module page.

But let me explain the screenshots.

The first (top) one is the module page in default view. It's a table with sortable columns. I really think this would be the easiest way to quickly find the module you are looking for. In this idea you could sort by name, version, package, status, permission and enabled/disabled. The first two columns need no explanation I assume.

The third column displays the packages, or categories, of the modules. Sorting by package improves quicker finding the module you are looking for.

The fourth column presents the info for all modules. When you move your cursor over the question mark, a tooltip will appear with the description of the module. You can also see the dependencies of that module here.

The status column is for future branches of Drupal, where update statuses can be used for modules. When a newer version of a module is available, you can see it directly in this column.

The sixth (permissions) column enables administrators to change the permissions of each module directly in the module page, using a inline window.

The last, most right column is the column in which you can enable/disable all modules. Instead of using checkboxes, I think sliders are much fancier. The jQuery Interface Library includes a slide plugin, but with only jQuery it wouldn't be that hard to create this either. The whole idea of these slides is that you can enable and disable modules on the fly, without a page refresh. If you try to enable a module which has dependent modules, which are not enabled yet, the background of the slider will turn orange and the required modules will light up orange. If you release the slider, the slider will slide back to OFF and a notification message will appear telling you which modules are required. If a module is disabled and a uninstall is available, an uninstall icon will appear. Clicking this icon will guide you to the uninstall confirmation form.

The second screenshot displays the permissions form. After clicking the permissions icon, this inline window will appear an gets a drupal form for changing the permissions of the module.

The third screenshot displays what happens if you try to enable a module which has disabled required modules. In this example I used the forum module which depends on Taxonomy and Comment. While Comment is not enabled yet, it will turn orange. It will not be possible to enable Forum before Comment is enabled.

The last one displays a notification message. This done by a module I already created, called inline_dialog. It uses an other module float_window I also created. The float_window module is a module which enables you to create inline draggable windows. float_window also provides me the ability to get drupal form using AJAX. inline_dialog uses float_window for catching the status and error messages from Drupal and displaying them in a dialog box. The float_window module could also be used for managing permissions directly on the modules page.

It has become a long story. Please give me some feedback on my ideas!

Skilip, I like that a lot. I would like to see the required module popup give you a 'click to install required modules' option. That would streamline the process nicely.

This is white lightning hot Skilip!

Great Work So Far!

Tell your boss to give you 2 raises because I said your just too damn good for only one!

We are all core here so I am sure someone will say "Eureka!" soon and have fixes for any possible security leaks.

cheers and bottoms up!

Johnny
"In Drupal We Trust" - the best online solution since Google!
http://mybanffphotographer.com - using Drupal since 2005

Ok, I think we are on to something now!

Craig Bertrand

The proposed hook_configuration() would be far less complex if modules were enabled one at a time via AJAX. If the page itself dimmed or ghosted or gave some indication to the user that a setting was being saved (like Netflix) then users could get instantaneous feedback if a module had unmet requirements that needed to be dealt with first.

This has the added benefit that 12 modules don't have to be enabled all at once, like our current system of checkboxes does. I disagree with mroswell's comment about checkboxes. Don't stay with checkboxes for an app that's fast approaching the year 2010. Selecting checkboxes and submitting a form to enable a module is so old school.

Let me give a running report of the plusses and minuses I see with this fantastic UI design idea.

IceCreamYou sez:
You shouldn't have to enable or disable modules in "waves." That is to say, you should be able to enable or disable a module regardless of whether its dependencies are enabled/disabled; the warning should let you choose to enable/disable dependencies, rather than forcing you to take the time to enable/disable them first.

While I agree that its better to try and not hinder the admin during the performance of their duties, allowing a popup warning message to enable all needed dependencies hurts the site admin in two ways. First, They have no idea what those other modules do. Second, They will always click yes to something that's asking them if they want to turn on 'other modules' in order to get their desired functionality out of this module. When they clicked 'yes', what else did they turn on? They don't know, but they got what they wanted, which was to have their new module enabled. The big problem that hook_configuration() can't yet address, and the reason it hasn't been built yet, is that Drupal doesn't know how to handle the following situation.

The admin enables Module D. Module D has been programmed (via it's hook_configuration() settings) to automatically create a content type called 'blartfast' provided the admin hasn't already created a content type with the same name, and if they have, hook_configuration() is going to need to ask what this new content type should be called in order to avoid conflicts with what the module's programmer thought would be a good name for their new content type but which is already used up. Get it so far?

Now, Module D relies on Module A, B, and C but none of them are switched on right now. Module D can't proceed with enabling itself because it might be relying on functions that live in A,B, or C and if Drupal allows Module D to become enabled, a PHP fatal error will happen when due to an undeclared function call. Ungood.

Drupal's admin/build/modules UI can't just enable Modules A,B, and C if Module D needs then, because what if module B has a dependency? The whole system would fall apart at that point.

IceCreamYou also sez:
You should be able to select multiple modules and perform operations on them, like enabling/disabling and setting permissions. You have to be careful with permissions though because the pop-up could end up very long.

No, no, no, and here's why. You should be performing permission changes based upon workflow, and not upon modules themselves. That's one of the usability things for which Drupal missed the boat. We the programmers designed Drupal to allow modules to set amazingly complex permissions for different functionality that a module creates for itself. We the admins and users alike want to enable or disable functionalities, not just a certain module's permission to do something that relies on another module's permission to do something which relies on another module's...

No, let's not continue to cater to the flawed programming model with a UI band aid. The permissions system could be undergoing some fantastically great changes, from the look of some of the issues I see filed for D7. Keep the permissions UI popup at a one-to-one ratio, and sooner or later when the permissions system catches up to a 'Would you like to enable the ability for people to blog?' and the option to choose more fine-grained controls rather than forcing admins into enabling 8 different permissions just so users can post blogs, comment on blogs, upload pictures to blogs, and see other user's blogs, This awesomely cooltastic UI proposal won't have to change again. It'll still be familiar.

Mroswell sez:
I strongly dislike the on/off graphics. They're confusing. Do you click ON to turn it off? Or ON to turn it on? Does the word Off signal that it's off, or that you have to click 'off' to turn it off? Good old-fashioned checkboxes are much easier! Also, they take up much less real estate.

The same thing could be said about checkboxes, I presume? Is the module on when it's checked, or do I have to check the box to turn it off and then submit the form?

Naw, I think the on/off switches are just fine. In fact, they're really cool! I only wish that they could be oriented vertically, like a lightswitch, but alas there's not that much room in a single table row if the other icons are going to shrink.

Senpai (my d.o account)
Drupal | Community Plumbing
Drupal | The Website Building System created by the Community and for the World

The last few months I have put some effort on developing a module for the admin page. At the moment I've got more spare time and I'm eager to spent more time on it.

Before leaping into the dark, and locking myself up in the attic for a month, (I'm tempted, trust me), I think it's wise to have some thoughts on it with you guys. With Thomas I'v had some discussions earlier. He already gave me some good advices when I started the project.

I've launched a temporarily site for previewing the module. People who are interested can mail me for an user login.

As mentioned before, it's still in development. Here's what has been done so far:

• Enabling / disabling modules
• Sorting table columns (the last sorted state is saved per user)
• Setting permissions
• Tooltips for quick access to administration pages per module
• Info-tooltip including dependent and required modules

And this is what I'm planning to do:

• Reinitializing dependencies and requirements after enabling or disabling a mdule
• Grouping tablerows after sorting (the table columns are sotable)
• Add a filter input field, which filters results as you type
• Add an uninstall icon if a module is disabled an can be uninstalled
• Remove the on-off slider for core-required modules
• Gray out info buttons if no help page is available. (currently only the info buttons of modules which have help pages are anchors)
• Reinitializing dependencies and requirements after enabling or disabling a mdule
• Probably redesign the layout to make it more generic. (damn you Garland@!)

Here's the module.

I forgot to mention the dependencies for the module. I will launch a project page for it asap.

my biggest issues with this are as follows:

1.) While I like the idea of putting permissions here, ultimately we can't have this replace the existing perms page, as a user needs to have the permission to access the modules page to change permissions... which ultimately if they can change permissions I guess they could give themselves that permissions but... you see the dilemma.

2.) WAY too big still. Needs to be slimmed up a bit, but I do like the colors, and I do like the general feel.

3.) Finally, I'm not so sure that how these will be organized is clear from your screen shots. Are they organized by package still? I think there's a lot of work for this particular issue left to do with every redesign of this page I've seen. I also don't like the fact that your screenshots imply that a user can't enable modules from the pop-up dialog box if they're required by the current module. Instead they have to go find said modules and install the individually.

What if we turn the model on it's head and instead of simply organizing modules by package (which I think is important) why don't we also consider organizing dependencies into the packages as well. For example:

Panels 3 requires ctools and views. ctools and views are their own packages (and rightfully so) but if we want to make this more task oriented, then I user shouldn't need to navigate away from the panels package area to find ctools and views (to enable or disable them) they should be provided to the user all in a single package window. This would allow us to orient the entire module screen by site functionality, instead of simply by package.

The downside to this is that some modules will show up in MANY places. Lots of things depend on taxonomy, so we'd have it half a dozen times on the screen. This might suggest we need an extra layer of UI here somewhere. That said, lots of us are simply used to the "by package" method, and there will be lots of resistance if we try to eliminate that (and I don't think we should). It's similar to by module administration.

Anyway, that's my $0.02.

Eclipse

Perhaps sharing some of the UI/IA/IX work done for plugin manager on http://groups.drupal.org/node/17765 could work here too?

PDF: Dmm-v1r1

Edit:

Here's a new iteration with enabled/disabled notices moved and a selection box added for multiple enables/disables. A toggle link to display all modules, only enabled modules or only disabled modules has been added as well.

Wire frame including indication for when a module update is available

Edit: Re-arranged a few elements including update information and inline enabled/disabled notices.

PDF: Dmm-v1r4

Hey Skilip,

Yes a sortable column works well there. Saves having to figure out how long modules should stay in the sticky.

I'm posting this here after posting it on the issue for improving the module page for Drupal 7: http://drupal.org/node/363319

I've been poking around with core making small patches to do something I've thought about for a long long time, which was using vertical tabs for the module groups.

I think the screenshots and skilip's module do look good, and have functional improvements, I'm just not convinced that a massive table is a step forward... (look at drupal 4.7)

I've successfully tested out the beginnings of turning the fieldsets into vertical tabs using the patch here: http://drupal.org/node/323112

When I started to rebuild the actual table rows, I realized some more design research would be required...

Here's a mockup I made that tries to address many concerns
My goals were:

1. Keep it simple: Drupal is trying to be easy for beginners. This is probably the most complex page in core.
2. Keep it Drupal: Drupal has a certain feel that is universal. I tried to keep it that way, using only fonts, colors, and icons already in core.
3. Make it more Useful: Allow for detailed information and functionality without overwhelming the form.

All module rows would default to collapsed tabsets. If JQuery UI gets in core, the tabs element has this functionality already.

Modules could extend the links AND tabs being displayed here, and potentially provide extra help text for installing, etc.

Thoughts?

I created a custom module with the following code in .info file:

and adding the following jQuery code to the js/eaposztrof_hacks.js file:

And the best, you can continue this script as you wish ;)