In Drupal 7 you are now able to install modules and themes using the interface. This opens the possibility for contrib to create a browser of projects.
Creating a better experience in exploring and installing modules is important for new users, to understand the Drupal ecoystem and the process of installing and configuring modules. Additionally seasoned users, are able to get everything up and running quicker. This is an design exploration, showing some of the possible interfaces for a project browser.
Exploring projects
Beside providing a simple listing of all themes and modules, the project browser could anticipate on already installed modules, versions and dependencies and from this able to give recommendations.
Many users at the beginning of the Drupal learning curve are struggling to find and install many of the modules we consider basic needs. Lets take a look at three very commonly used modules and the dependencies required for installation :
- Views requires CTools
- Rules requires Entity and Entity_token
- Pathauto requires Token
All perfectly understandable requirements, but also often requiring many additional steps for the user. A project browser could eliminate this part and as we are moving more towards projects that depend on more on abstract modules, better separation of API & UI, distributions, features and so on - the need for a more intertwined approach to downloading and installing projects should be explored.
The mockup above shows how-to explore themes, sorted by downloads. Some of the parts exposed :
- Listing of the projects, prioritized on overall usage.
- Filter pane, to quickly limit the number of results on your interests.
- Ability to make a list of projects you want to install
- Search, primarily for know-item seeking.
Installing projects
Installing several projects
Drupal 7 core does not allow you to install several modules at once. The project browser could allow this, allowing to install a list of modules.
Backup website
You remember that "you should backup your database and files before installing..." message that is often ignored? By automating this process we can ensure that this step is not overlooked. Using a module like Backup and Migrate would make this possible.
The image belows shows this in a progress bar, I separated this process from that of installing modules to clearly show that a backup is being made and you don't have to worry (as much).
Enabling projects
This is a step we currently miss in Drupal core it's installer, the possibility to directly enable the modules that have been installed - this instead of directing them to a page with dozens of modules.
There is a great opportunity for creating a better flow in finding, installing, enabling and configuring projects. The examples shown are above, are about solving some of the major problems that users encounter, ideally we also find resolutions for the next step that of configuring (but this might be Drupal 8 material).
The full sized screenshots with additional annotations can be found on Flickr :
How to make it happen?
The biggest roadblock for making it happen, is the technical implementation of browsing all these projects. Do we for example require users to store a big file listing all the projects, that gets updated continuously or do we solve it by querying Drupal.org? There are many questions, but it is solving a big problem both new and seasoned users encounter.
Stijn Vanden Brande who works at Krimson worked on this a bit and put his work up at Github, we hope people can help solving this technical hurdle and contribute to actually make it happen as Drupal 7 contrib.
What are your thoughts?
Update: A GSoC project has been started to do this, called Project browser.
Discussion
i like it!
February 7, 2011
I've had this idea too (an app-store like interface for modules) - and I definitely identify with the steep learning curve of Drupal simply in terms of familiarising oneself with all the useful modules out there.
And the mock ups are great and clearly show the potential of the idea.
Expanding on the idea, we need to incorporate Drush-like features into the UI - updating, backup, module installation etc.
February 7, 2011
Great idea and very nice mockups! :)
Wheres not that useful for those using Drush this is HUGE for lowering the Drupal entry barrier and luring in people used to Wordpress.
Awesome! Gonna check out the code on github
-- Alex
February 7, 2011
This seems to duplicate (or at least be closely related to) the work on the Plugin Manager module for D7. See http://drupal.org/node/336743, for example.
Will the code be moved from Github to drupal.org so there can be an issue queue and we can work on merging those efforts?
In any case, this is great - a really important project.
February 7, 2011
I love this model. This would greatly simplify the process for adding modules and themes to a site and would lower the barrier to entry quite a bit.
Another thing I believe is desperately needed is a robust tagging system for themes. For example, there could be a set of tags based around what column configurations are available for a theme. Or color schemes. Or whether the theme taps into the Color module. Whether or not a theme is up to standards, whether that's XHTML Transitional, XHTML Strict or HTML5. These are all things I wonder about when trying to find a theme, but it's very difficult to track things down. Drupal has such a robust taxonomy system that this would seem like a no-brainer.
Similar tags could be used for modules, to help classify their exact purpose, their adherence to standards, etc. Whatever would help people find the module they need for the task at hand.
I'd love to see that built into both drupal.org and any system for browsing modules and themes within a Drupal site.
February 7, 2011
A *very* interesting idea!
I hadn't thought of true integration between Drupal installations and drupal.org before... but why not? We're fortunate to have a single, inarguable source for "official" Drupal information... why not take advantage of it in this way?
This sort of integration throughout Drupal would be interesting to consider for Drupal 8 (or 9). Are you listening, Dries? ;)
February 7, 2011
I like it! Really good job on the mock-ups!
This should probably be tackled in a few steps.
First, build the UI to browse & install modules.
Next, add a UI to help enable newly installed modules.
Then, start adding features (the devil is the details):
1.) Browse/select different versions of modules (-dev, alpha, beta, and stable) to install.
2.) Dependencies handling. If the user chooses to install/enable a module with missing dependencies prompt to automatically install/enable the required modules.
3.) Modules that require 3rd party libraries might be a challenge.
February 7, 2011
If such a tool were available right now I'd advise a site admin to be *extremely* careful with its use, if not avoiding it entirely.
Why? Because there are wild and ravenous modules out there that will eat your home. They may entice you with their shiny widgets and fancy names, but once you install they'll WSOD your site so bad you'll straight cry.
Really, before the release of such a tool we would need built-in database backup capabilities so one could easily revert from a broken state. Perhaps sandbox after installation, a sort of "is everything ok? hit no to revert back" fallback.
February 8, 2011
@Ben J: The tool itself only automates a task every site maintainer currently does by hand or by using Drush. There will not be a higher risk of crashing your site. It will only be easier to download modules, both good and bad ones.
I like the mockups. One little thing: modules are currently automatically enabled upon installation. Installing only means "enabling for the first time", so the module can perform initial configuration tasks, such as setting up database tables.
Also, one thing I haven't heard anybody talk about is repositories. It would be a waste of potential to let this module work only with drupal.org. Site admins should be able to add URLs for other Drupal repositories. This way site builders can set up their own repositories with custom Drupal modules they use for their clients. Drupal installations can then automatically fetch and install the newest versions of those modules as well, making updates even smoother.
February 8, 2011
@Bart: I agree about the repositories aspect. It could be achieved with something like an extra setting in module .info files, and the update status list would get the benefit too.
As well as being useful for Drupal shops with custom modules for clients, it would also be beneficial for distribution-specific custom modules which are not hosted on drupal.org (e.g. Aqcuia, Open Atrium, etc).
February 8, 2011
Nice work! Here are my 2 cents.
What's the point of the version filter on the right? The system should only show the versions compatible with the installed version of core, and there's no point in filtering by 7.15, 7.2, etc, since the recommended and supported versions are usually the latest one.
For the dependencies, I think it should just select the required modules behind the scenes and list them on the confirmation screen. So e.g. if you select to install Views module, on the confirmation screen it will also list CTools. This is how apt GUIs does this.
February 8, 2011
I like it. My only thought it to add a recommendations[] element to .info files so that modules and themes may suggest complimentary (but notrequired) modules and themes for download.
February 8, 2011
wow, can't wait ! This is just what Drupal needs
February 8, 2011
It's interesting to hear a lot of diffrent ideas. There are definitly a lot of ideas to improve browsing of themes (better seperation of base themes, certain validity etc.). There surely are a lot of functions that could be added, by building this in contrib we could experiment with diffrent ideas. As some of the comments suggest, we should make greater use of existing intelligence like version numbers - I definitely agree there.
@Ben J I think that's more a Drupal problem, than a problem of this particular functionality.
@David I am not sure, plugin_manager isn't really being developed as far as I know. Given that the development stalled on both Github and plugin_manager I see no good starting point.
@agent I am really not sure that's the role of module maintainers, instead we should be able to provide suggestions by analyzing installed modules (we already collect that information) of other Drupal sites.
February 8, 2011
@agentrickard: Module supports tried extending the .info file with recommends[], enhances[] and other declarations.
February 8, 2011
I love the idea. WordPress I know has similar and is one of the few advantages to WordPress. I would love to see something like this in Drupal. As for how to query, I can imagine if Drupal.org was queried then that would create a massive load on the servers, having said that two things spring to mind.
1. Does the Update Status module not already query Drupal.org? Okay it is a small subset of modules, but could that not be a starting point?
2. With Git being used, could that not be used to distribute a list of modules/themes? i.e. create a Git Repo with a list of modules, descriptions, versions, etc.
Anyway, will keep a keen eye on this...
February 13, 2011
If we could have complete control of what gets shown there, and point to Features Servers, then Drupal distributions would totally kick ass.
February 19, 2011
It might be a good idea to get the module rating from drupalmodules.com in as well.
What does concern me about this project is that low level users never visit drupal.org before adding modules.
This means they don't get to read the info provided on the project page.
But what concerns me more is that they are less likely to add issues to the issue queue, when they don't know where it is, or even if it's there.
So i think there should definitelypu be links to the module's project page and issue queue
March 11, 2011
Just thought I'd mention that I am building the Project Browser module for GSOC 2011. I am following the mockups in this article as much as possible. Here is a link to the project page: http://groups.drupal.org/node/145159
Sincerely,
Leighton Whiting
June 29, 2011
Post new comment