Categorizing modules-demonstrating the value of the Drupal platform
Hi, software platforms like Drupal are often evaluated by the additional components they have. Today Drupal's contributed modules are plentiful but the value of the modules is hard to discover because the modules are hard to understand. This can be fixed in 3 ways. First, we need to categorize modules so that they can be quickly discovered. Second, we need to evaluate modules to rate their quality. Third, we need to make it easier to understand contributed modules. CivicSpace Labs with a lot of personal contributions from Nedjo and Dries have extended the project module to allow modules to be categorized. This new categorization can be seen on the Drupal.org beta site: http://scratch.drupal.org/project/Modules We are looking for volunteers to help us discover what the logical categories for modules on the Drupal platform is. We are starting with the developer community who know the modules best. In the long run we are likely to conduct a card sort usability experiment to confirm that modules are well categorized for web site developers, and Drupal administrators. We know from recent surveys that installing new modules is one of the most common tasks and therefore represents one of the biggest usability improvements for Drupal. We are looking for volunteers to wade through the modules and attempt a first pass at categorization. There are 4 groups of modules we could evaluate with the total modules increasing in each category. The larger the group to categorize the more work. 1) Most downloaded modules about 40- http://drupal.org/node/46109 2) Modules with administration help documentation. http://drupal.org/ handbook/modules -about 80 3) Modules with project pages http://drupal.org/project/Modules- about 200? <-has the advantage of allowing us to categorize all the project modules 4) Modules checked into the CVS contributions directory http:// cvs.drupal.org/viewcvs/drupal/contributions/modules/- Several hundred? The goal is to get this categorization done for the upcoming Drupal.org upgrade. I'll moderate this thread to coordinate volunteers and help to come up with some top level categories. Please suggest some top level categories for module project pages. Cheers, Kieran
Please suggest some top level categories for module project pages.
Turn on free tagging and let everyone suggest categories as desired. If you really want to enforce order then wait 60 days and analyze the free tag information for a hierarchy My .02 -moshe
Turn on free tagging and let everyone suggest categories as desired.
Thanks Moshe, it's a good suggestion. The way we've coded this in project.module, though, is that the projects vocabulary is used in a special way: the top level terms are project types (Modules, Themes, etc.). This is what allows us to have a local task (tab) for each project type. Second+ level terms are the options for that project type (e.g., Modules might have mail, XML, etc.). Am I right in thinking that freetagging always creates top-level terms? If so, that won't work here because of the specialized use of top-level terms. One suggestion has been that we could have this specialized (and manually maintained) vocabulary, plus another freetagging vocabulary. This permits a vocabulary with a select, limited number of terms, plus a larger community-built one. If we want to combine them, I suppose we could either: * use a different vocabulary for each project type (this would require a fair bit of recoding) * use a modified autocomplete, sending a designated parent term, so that projects with 'Modules' as a first-level term would create second-level child terms of 'Modules'. Alternately, we can simply create a second, freetagging vocabulary, to be used in the interim to gather information that will be used to manually create categories. Or we could return the designated project vocabulary to having just first-level terms, and use other vocabularies for categorization. Thoughts on what would work best?
On 23-Jan-06, at 9:00 PM, Nedjo Rogers wrote:
Turn on free tagging and let everyone suggest categories as desired.
Thanks Moshe, it's a good suggestion. The way we've coded this in project.module, though, is that the projects vocabulary is used in a special way: the top level terms are project types (Modules, Themes, etc.). This is what allows us to have a local task (tab) for each project type. Second+ level terms are the options for that project type (e.g., Modules might have mail, XML, etc.).
Am I right in thinking that freetagging always creates top-level terms? If so, that won't work here because of the specialized use of top-level terms.
One suggestion has been that we could have this specialized (and manually maintained) vocabulary, plus another freetagging vocabulary. This permits a vocabulary with a select, limited number of terms, plus a larger community-built one.
Yes, it should use both. See the 4.6-era version of weblinks. It uses one vocab for a navigational structure, and can use one or more additional vocabularies for keyword-style tagging. Works really well. We should probably look at some of the old archives for some first cuts at categorization... This really should have been built with two vocabularies -- one for top level, one for categorization. Yeah, probably too late now. Means you have to set vocab to multi-hierachy too -- if you want to use XML for both Modules and Themes, has to appear under both hierarchies.... Here are some ideas that should nicely mess with peoples' perceptions: Content Types * Event * Reviews * Image * Audio ... APIs * Event * Form * Mailhandler ... Image * Image * Img_assist ... User * user_import * troll ... Mail * Mailhandler ... Presentation * Sections * Views * Dashboard * Theme_editor ... Date * Event * EventFinder ... Community * Troll * Privatemsg * Buddylist ... -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
This really should have been built with two vocabularies -- one for top level, one for categorization. Yeah, probably too late now. Means you have to set vocab to multi-hierachy too -- if you want to use XML for both Modules and Themes, has to appear under both hierarchies....
The issue has been in the patch queue for several weeks and links to it have been posted on the mailing list. It's too late now, so let us move forward with the tools at hand. We can always look at changing/extending things later on. The suggested categories looks like a great starting point. -- Dries Buytaert :: http://buytaert.net/
On 24-Jan-06, at 7:32 AM, Dries Buytaert wrote:
This really should have been built with two vocabularies -- one for top level, one for categorization. Yeah, probably too late now. Means you have to set vocab to multi-hierachy too -- if you want to use XML for both Modules and Themes, has to appear under both hierarchies....
The issue has been in the patch queue for several weeks and links to it have been posted on the mailing list. It's too late now, so let us move forward with the tools at hand. We can always look at changing/extending things later on.
I know, which is why I said "too late". Patches aren't quite the same thing as an overall plan aka DEPs....next time!
The suggested categories looks like a great starting point.
Thanks. I extended it and stuck it in a wiki here, in case it's useful: http://dev.bryght.com/t/wiki/DrupalProjectCategories -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
Thanks. I extended it and stuck it in a wiki here, in case it's useful: http://dev.bryght.com/t/wiki/DrupalProjectCategories
Looks useful to me. Maybe someone can try to implement it on scratch.drupal.org to see how it would look like? -- Dries Buytaert :: http://buytaert.net/
The suggested categories looks like a great starting point.
Thanks. I extended it and stuck it in a wiki here, in case it's useful: http://dev.bryght.com/t/wiki/DrupalProjectCategories
I added some. Hope you find useful.
Alternately, we can simply create a second, freetagging vocabulary, to be used in the interim to gather information that will be used to manually create categories.
sure, this works well IMO. I hope drupal.org will consider running some taxonomy browsing module like tagadelic so we can visualize this free tagging vocab.
On 24 Jan 2006, at 02:45, Moshe Weitzman wrote:
Turn on free tagging and let everyone suggest categories as desired. If you really want to enforce order then wait 60 days and analyze the free tag information for a hierarchy
Content can only be tagged by the maintainer of the module, or by site administrators. I think we are best of coming up with an initial number of top-level categories. I can try to come up with a categorization if no one else beats me at it. -- Dries Buytaert :: http://www.buytaert.net/
On 24/01/06, Kieran Lal <kieran@civicspacelabs.org> wrote:
Hi, software platforms like Drupal are often evaluated by the additional components they have. Today Drupal's contributed modules are plentiful but the value of the modules is hard to discover because the modules are hard to understand. This can be fixed in 3 ways. First, we need to categorize modules so that they can be quickly discovered. Second, we need to evaluate modules to rate their quality. Third, we need to make it easier to understand contributed modules.
I think that the option of tagging modules under multiple categories/parents will be an inevitable requirement.. A few doozies to kick things off: -Filters - bbcode, codefilter etc. -3rd party - Modules which interface with 3rd party software/websites. Google Site map, Adsense, Amazon * etc. -Enhancements - Modules that enhance the look or functionality of existing modules.. Most of the filters will probably also belong here along with stuff like Nice Menus etc. -Administration - database administration etc. -Security/Authentication/Access Control - spam, bad behaviour, ldap, taxonomy_acess etc. -Taxonomy - taxonomy related modules.. IMO there should not be more than say 10-15 primary categories and they should be displayed (along with a brief one-line description) without the need for any scrolling - perhaps in a two column layout. Else the point of categorisation will be lost.. hth, -K
On 24/01/06, Kieran Lal <kieran@civicspacelabs.org> wrote:
Hi, software platforms like Drupal are often evaluated by the additional components they have. Today Drupal's contributed modules are plentiful but the value of the modules is hard to discover because the modules are hard to understand. This can be fixed in 3 ways. First, we need to categorize modules so that they can be quickly discovered. Second, we need to evaluate modules to rate their quality. Third, we need to make it easier to understand contributed modules.
This page is also perfect for an autocomplete textfield (based on module title).. -K
Last summer Kieran and I took a stab at a card-sort for categorizing modules. I'm not sure where this left off, but it might be worthwhile to revive as a means to create the categories and/or sort the modules into them. I agree that it would be nice to allow freetagging as well as a more structured categorization, and to allow modules to be placed into multiple categories. Djun On 23-Jan-2006, at 11:45 PM, Karthik wrote:
On 24/01/06, Kieran Lal <kieran@civicspacelabs.org> wrote:
Hi, software platforms like Drupal are often evaluated by the additional components they have. Today Drupal's contributed modules are plentiful but the value of the modules is hard to discover because the modules are hard to understand. This can be fixed in 3 ways. First, we need to categorize modules so that they can be quickly discovered. Second, we need to evaluate modules to rate their quality. Third, we need to make it easier to understand contributed modules.
This page is also perfect for an autocomplete textfield (based on module title)..
-K
participants (9)
-
Boris Mann -
Dries Buytaert -
Dries Buytaert -
Karoly Negyesi -
Karthik -
Kieran Lal -
Moshe Weitzman -
Nedjo Rogers -
puregin