Modules page

I agree that the current workflow for enabling and disabling modules could be improved a lot. If you have a lot of modules, and if you are developing a lot, you spend a lot of time enabling and disabling modules. I've already created a little module which also collapses all fieldsets in the module page, but for usability this is not the best solution. I've thought about a way you could drag and drop modules, in order to enable and disable modules. We than need two panes. For example a left pane for enabled, (and thus installed) modules. The right pane contains the disabled modules. If you drag a module from to the left pane to the right pane, it will light up, just like when you're reordering blocks in D6. After submitting the module form, all new modules in the left pane, will be installed.

If a module had dependencies, the module and it's dependant modules will light up orange, when the user starts to drag. When you want to uninstall a module, you just click on a red cross, which redirects you to the confirmation form.

A little example:

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

Hmm... good idea, as far as the module categories maybe there could be a "add group" button that adds a arbitrary container just for the modules page, that a way you dont have a bunch of subfolders in the modules directory. then the groups could be saved in a xml file in the modules directory (or somewhere else) so a multi site setup could use the groupings on multiple sites (make this optional so you dont have to use the same groupings)

Craig Bertrand

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 am just thinking here, why would you make a drag/drop interaction when checking a box is faster?

Maybe instead of drag n drop there could be a >> button that just automatically slides over to the activated side. (also I think the right side should be activated in my mind at least )

maybe we need to rethink the entire workflow of modules after a module is activated we should be able to set permissions in a popup or something like that? and have an option to configure it?

What are all of the actions that can be done to a module?

1. enable
2. disable
3. uninstall
4. permissions
5. configure
6. update

Did I miss anything?
How could these be integrated and made into a more usable system?

I know when I first started drupal after I installed a module I expected it to just work.
Just thinking out loud

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.

maybe there could be a sort by drop down

sort by...

Name
Category
Need Updating
Create Custom Group

This way if you need something that isnt there you can just create it.

also on every module why not have a link section (small icons maybe) that represent Uninstall (with warning popup), Permissions, Configure, Drupal.org issues for this module, and one that appears if the module needs to be updated.

Craig Bertrand

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

This is exactly what I am addressing on the below thread.

If you could create your roles, permissions, enable, disable and uninstall your modules from one modules control panel it would be beyond ideal. Less page loads and moving back an forward. You can work it just like the views add page.

At the top you would be able create your roles.

Then enabling your modules.

You could drag and drop the same modules into the three or how many user roles you require for that module.

I think modules should throttled on installation i always throttle all my modules - my clients tell me my site runs quick enough for them.

You should be able to just drag each module into every role. Another idea is to have a throttle option with each role.
that way when the module is installed Drupal automatically decides what roles the module is used for what roles the module should be throttled for - maybe this is just to much. But knowing the quality and seeing where these features
already exist on other online systems i am pretty sure all this can happen.

I just think it would be really neat if all of this could be achieved with than going to roles, then permissions and so on.

I would set the whole panel up like this - just as if you where creating a tinyMCE profile

roles collapsible, permissions collapsible, enable collapsible, disable collapsible and un install.

I think that roles should created then the modules enabled in the field below, then after the modules are you can select the enable modules by a click all and then drag to the particular role. It only makes sense as well that when Drupal is install an Admin role should not have to be created and a when a module is enabled the Admin should automatically have all the permissions - only makes sense correct me if i am wrong.

Hopefully this gets some ideas rattling around

http://groups.drupal.org/node/11042

Friendship,

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

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

This kind of uber-cockpit is exactly what I'm planning to do. Integrating everything into one process: you activate a module: you are taken to a page where you can access, or have links, to all pages: Access settings, Activation, Module settings and what else is needed. Since I'm more of a UI / Graphics designer I am looking for a Developer to team up with. I will soon provide mockups to illustrate what I mean. But this will not stop at mockups, Whith the aid of Panels 2 and Jquery I should succeed to get a proof of concept on my own in the worst case...

Life is a process

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 think in first light of the idea of everything on one page it could be very overwhelming.

I reflect on the set up of the TinyMCE profile creation.

We have a pretty extensive set up page but when we hack at it one step at a time from each category of the set up you move through it pretty quickly.

I just feel that setting the permissions seems to be a more drawn out process than it should be.

Perhaps we can set the permissions as part of installing the each and every module.

We are already grouping the modules with their proper classes which is a very healthy start for the work flow of erecting a new site.

I just think after each selection of modules we should install group by group without a entire page refresh.

I am also not sure that the white screen is memory issue because 100% of the time when I refresh the white page of death i get message that the configuration has been saved. I have found Firefox has been wonky period since the release
of Leopard and does all sorts of weird things - sometimes i just work with Safari when Firefox is having issues.

Would it be less strain on the server if we were able to install smaller groups of modules at a time. I just think that we want to keep Drupal light on it's feet and what I read on Drupal.org is Drupal becoming to sophisticated for contributing module developers to keep up with how far out in front core keeps on jumping from one release to the next.
Don't get me wrong, Drupal is out in front and we must work hard to stay out in front. We swim or we sink that's life!

For my server I am running with servage.net - and these guys are really good at what they do for an outstanding price. Most issues I do come across which happens once every 6 month or so is normally resolved in under a hour which I think is champion.

Back to Modules...

When we submit a new node theres ajax all over the place, I just think with all this great code happening we can organize and brake down the whole site module building task without having to go over to the roles page and then the permissions page which is 20 inches of scrolling for a smaller site - you get half way down and you better had memorized which column is what role - and back to modules or vice versa.

Am I making any sense with all of this?

Regardless I would still use Drupal as Web Solution over Dream Weaver any given day of the week!

Lets face it my new Subaru, My 2 new lovely imacs with 4gb of ram, My new 12.2 mega pixel cameras , are all made possible with the a very basic use of Drupal - it is a major piece of the puzzle I call my Digital Photography Company.
I honestly say Drupal is what gives me the "Edge" over my local competitors - my "Ace" up my sleeve.

I am not knocking the present process of setting up a site from back when I was using 4.6 -5.0 is white lighting compared.

Just trying post some suggestions.

Johnny

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

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.

Just updated the original post
see the top

Craig Bertrand

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!

Woot! Right like it should be. Where can I sign up?
Some people may complain this looks a bit too "Joomly".
But others say this is standard like many other applications handle this, so it is a massive Argument pro.

Maybe just reduce size and saturation of colored Buttons a bit to make it a bit less hit-in-the-face.

If THIS might be implemented the least bit, it would be a HUGE step forward.

Life is a process

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.

I agree in making the icons a little smaller Eigentor!

@Kingmoore: In my opinion the modules should be enabled separately and not after a 'click and install required modules' confirmation box. Having to enable them one by one has the big advantage of knowing what you do. It also avoids conflicts during multi-installations.

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

Some thoughts:

• 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.

• 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.

• A mouseover on the Status column should show you what version(s) you can upgrade to, and a click should (A) download the new version if there's only one choice or (B) show a pop-up dialog that lets you choose which version to download if there are multiple options. Perhaps there could even be a different icon indicating that there are multiple options.

• With a lot of roles, the Permissions pop-up could get very wide.

• There should still be a way to set permissions on a per-role basis.

• There should still be an indication of dependency (that doesn't require any clicking).

Otherwise, it looks good.

Ok, I think we are on to something now!

Craig Bertrand

1. I've never understood why there aren't module configuration links from the modules page.
2. 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.
3. Agree on the size of those graphics. Yikes.
4. What's the significance of the recycle graphic? What does a checkmark mean?
5. If you're at the bottom of the page, will the dependency popup stay above the fold? (I agree that dependency shouldn't require clicking. I think I actually like the v5 approach for showing dependencies: simple, and the lack of icons to share this information doesn't bother me a bit.)
6. Will want a multi-level sort. Sort by package, and then alphabetically.
7. Hmmm... Why not configurable fields.. for instance, date of install, or date module was written, as optional fields? Right click the header to add such fields.

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

Thanks a lot for all your feedback! The comments were very useful to rethink my design. I totally agree with everything Senpai wrote. I will stick mainly to my design, but will take a few things in consideration.

I agree the icons, as well as the switches, should be smaller. In the current design, they are just a little bit overdone.
Secondly, I really like the idea mroswell came up with, of showing- or hiding columns. Some kind of data-grid idea.

As a response to mroswell's question of where the check-mark and recycle icons stand for: They are a way to let the user know the status of the module. Whether the module is up to date, or requires an update.

With eigentor I've had some correspondence by mail about kicking of the project. We've decided to create a task list for development. If ne1 feels committed to this project, and has got some free time, please contact one of us.

This week I've already reviewed the module I used for the dialog boxes. I'm planning to contribute the module as a project to Drupal today.