It is a known fact that the drupal modules page (http://drupal.org/project/Modules) is not perfect. There's a lot of discussion going on about how to gather module quality metrics, whether to enable a voting module or not, etc.
It's quite true that it's currently rather difficult to find what you're looking for. I think that by now I've got quite a good overview about the "hot" modules, but still for me, I often find the modules by using the advanced search or by checking cvs commit track page of the user of which I know he created the module.
If you're trying to look for new stuff, it's getting even harder. Most categories contain more than 50 modules, some even up to over a hundred, and many are attached to several of the just 26 module categories.
I think the discussion about sorting modules by their "quality" is a very worthy one, but most solutions involve coding and therefore will need quite some time to get deployed.
However, there's quite a simple thing we can do right now without any coding (at least I think so) that would increase the usability of the module page enormously: Improve the categorization. Drupal is famous for its taxonomy system, so why shouldn't we use it in a more sophisticated way?
For example, there are at least 10 modules out there that provide more usable menu blocks, usually by using DHTML (examples are nice_menus, dhtml_menu, lucid_menu, simplemenu, ..), yet they're scattered all over the different categories.
So, what I propose is to refine the module categorization. For example by using at least two levels of hierarchy.
This is a wiki page, so anyone is welcome to update and improve this working draft for a better categorization of drupal modules. Whenever you edit this page, please add a comment that quickly describes your changes!
Working draft for a better categorization of drupal modules
(very early working draft)
- Usability enhancements
- Menus
- Javascript-based usability enhancements
- General usability enhancements
- Administration tools
- General administration usability
- Taxonomy management
- Content management
- Comment management
- Import / Expor tools
- Backup tools
- Statistics
- Caching and Performance
- Content
- Content rating systems
- Event managment
- Content listing
- Paging
- Input filters
- Editors
- Image modules
- Media integration
- Project management
- Wiki related
- Forum related
- Content access
- Taxonomy-based
- Forum-based
- Menu based
- other
- Internationalization
- Communication
- Mailing
- Newsletters
- Messaging
- Chat
- E-Commerce
- Aggregation & Syndication
- OpenSearch
- Content aggregation
- Feed creation
- File managment
- User management
- Authorization
- other
- Theme related
- 3rd party integration
- Web services
- Authorization
- Bridges
- Module specific
- Views
- Organic groups
- VotingAPI
- CCK fields
- other CCK related modules
- Developer modules
- API-only modules
Comments
already using 2 levels -- not sure a 3rd is possible
in general, i like the idea, though i might nit-pick some of your suggestions above.
i hate to say this, since this is really a dumb limitation in project.module... however, the fact of the matter is that we're already using 2 levels of taxonomy for project classification -- the 1st is project type (module, theme, translation, etc). the 2nd is the stuff you're thinking about, which is currently only under the "Modules" top-level term (though we'll soon have 2nd level terms for each language under the "Translations" term -- see http://drupal.org/node/105986).
due to how hard the taxonomy UI was for people to get right when it used to be one giant monolithic multi-select, i put in code to split out the top level terms, make those radio buttons, and then put the 2nd-level terms into their own multi-select boxes (which are now conditionally hidden/show via JS depending on which radio is selected). i'm not positive that a 3nd tier of classification for modules would work given this code. :(
there are also other places in the code that have hard-coded logic about the Project taxonomy, like the very browsing pages you're talking about. for example, i'm assuming that you'd like to see the categories grouped in the same hierarchy on http://drupal.org/project/Modules as in the vocabulary itself. however, that would require more custom code. :(
so, the above proposal has a few prerequisites before it can even be considered seriously:
sorry to be the bearer of bad news, but that's life...
Yeah, when I reread the part
Yeah, when I reread the part about "requires no custom code", I already thought that that unfortunately might be not true, as there are so many hard-coded things in there.
Right now, I won't have the time to work on this, unfortunately, but in two or three weeks, I'll hopefully be able to look into this.
Nevertheless, everyone is welcomed to discuss the actual categorization of modules, edit the wiki page, and so on..
any use?
Wim Leers' hierarchical select module helps a lot with the form issues. It'd be a change, but a nice change - and three levels of hierarchy wouldn't be a problem. Would have to strip out the radio/select combo and just rely on this probably. And D6 only for jQuery dependency.
http://drupal.org/project/hierarchical_select
Doesn't fix 4 and 5, but there for your consideration.