Every week it seems like there's a new issue in the webmasters/issue queue about new taxonomy terms for projects, this is a sure sign that the existing categories don't fit current needs. An obvious issue is that some of the categories are huuuge, which means in some cases you're just as well off browsing the full modules list. Who wants to look through 414 'utility' modules? What does 'content display' even mean.
So... let's look at reworking it. I see this having two elements to it. Overall, the categories should be task based, I want to look at modules which fulfil a particular need, I'm unlikely to want to view a list of modules that happen to include third party integration (although I might want to exclude those, which afaik I can't at the moment). For that, it'd be better to have a longer list of more specific categories, and less modules in them.
Additionally, more technical categories can be useful categories for some kinds of browsing especially for developers - say I want to find a module that supports Views2, or want to see examples of third party integration. However, I don't think they belong on the main modules listing - and strongly think we should move them to a separate free tagging vocabulary.
current list
* 3rd party integration (291)
* Administration (236)
* CCK (158)
* Commerce / advertising (78)
* Community (166)
* Content (392)
* Content display (422)
* Developer (157)
* e-Commerce (64)
* Evaluation/rating (65)
* Event (41)
* File management (54)
* Filters/editors (141)
* Import/export (63)
* Javascript Utilities (96)
* Location (38)
* Mail (100)
* Media (143)
* Multilingual (25)
* Organic Groups (53)
* Paging (19)
* RDF (15)
* Search (63)
* Security (55)
* Syndication (60)
* Taxonomy (119)
* Theme related (115)
* User access/authentication (138)
* User management (127)
* Utility (414)
* Views (92)
Rough draft of a new list:
* Advertising
* Amusements
* Audio
* Content administration
* Content rating and recommendation
* Content organisation
* Development
* E-commerce
* E-mail and messaging
* Events
* File management
* Form building and enhancement
* Forums
* Images
* Import/export
* Javascript
* Mapping and addresses
* Menus
* Multilingual
* Performance
* Permissions and access control
* Search
* Security
* Site building tools
* Syndication and aggregation
* Text editors
* Text filters and processors
* User authentication
* User administration
* User interface enhancements
* Video
* Web services and semantic web
That's 30 categories, I reckon it could get to 40-45 pretty quick (currently there's 38).
The next thing though, would be adding a separate free-tagging vocabulary, this would handle stuff like module groupings (views, cck, panels, ecommerce, ubercart, RDF API, Organic Groups), and stuff that's either not useful to 90% of Drupal users trying to find a module, or not task-oriented enough to go in the above list - things like Third party integration, taxonomy, node_access, third party migration, blogging, community etc. - which either have little to do with what the module actually does, or are too broad to be useful.
These tags could be displayed on project pages, in a list linked off project/modules somewhere, maybe a tagadelic thing at some point, and we could then use modules like "similar by terms" to show related modules based on this (or use it alongside pivots and other recommendation algorithms). We could also very slowly move tags from the freetagging vocabulary into the fixed one, if they turned out to be very useful, or vice versa.
I'd volunteer to do some of the work of reclassifying modules if something like this was implemented, obviously it'd be quite a big job though, but since only project maintainers and drupal.org site maintainers would be able to tag, it'd probably have some limitation on noise and bad tags.
Comments
One thing to keep in mind
Overall I think this proposal is a good idea.
One thing to keep in mind--the project types vocabulary is pretty connected with how the entire project module functions.
On d.o, the Project type vocabulary looks something like this:
Drupal project
Modules
-CCK
-Developer
-Organic Groups
-Views
Themes
Theme engines
Top level terms have menu paths like:
http://drupal.org/project/Modules
For the top level terms which have children terms, such as the Modules term, there are also paths for browsing those subcategories like:
http://drupal.org/project/Modules/category/XXX
So changing the terms to be task based won't cause a problem. But I'm not sure how we'd also make available "browsing" by the free-tagging type terms. Or, at least, I'm not sure how easy it would be do do a parallel type browse by free tag list. With the D6 port using Views, it'd probably be possible to make available an exposed filter for the free tagging vocabulary term so the user could filter further by terms in that vocabulary, however.
So, just something to keep in mind, but I do like the idea.
listings
Initially I'm not envisioning much listings of terms from the free tagging vocabulary.
I'd see them being on project pages initially which ought to be zero extra work, or at least very little (and which'd link to taxonomy/term/123 of course), and then look at Views/tagadelic/recommendation stuff once Drupal is on D6 and/or a subdomain split has happened. For a start, listings and filtering won't be much use until a few hundred modules have got some tags.
Some of the terms which'd move from the fixed list to tags, like views, cck, organic groups - we could list them manually somewhere in the interim and create path aliases for the category listings - or just leave them in the main vocabulary until the free tagging one is usable.
Missing category? . . .
I might be missing something, but it looks like you broke out the media section and didn't create a place for audio modules.
Man, and I'm supposed to be
Man, and I'm supposed to be a musician :(
edited in :)
sub-categories are needed to refine the lists
So instead of, for example
you have
I'm envisioning that only the User category would be listed on the top page and then the sub-categories would be listed on a new page when the category is clicked or would expand the listing to show the sub-categories.
I don't think so. User
I don't think so.
User interface isn't a subcategory of 'User' for a start.
i'd think about it
I would certainly consider subcategories as a valid path. For instance audio, video and image could be a subcategory of "File management". Generic module likes filefield, emfield or asset would fall under the generic FM category while more specific module such as the audio module would go below FM > Audio.
Category "API"
Should we consider a category that adds a taxonomy named API or Extended API so that modules that add callable functionality can be better classified in the listings?
Some suggestions, comments and questions
Looks good! Some suggestions, comments and questions:
I do think the module related categories are important for a lot of users (I'd say getting a list of CCK and Views related modules might be relevant for 90% of the users...) However, it's probably a good idea to separate these categories from the task oriented ones. I suggest a separate vocabulary for module groupings, not mixed in with other categories or tags.
Events also contains other date/time/calendar related modules. Perhaps name it to Date and time, or something like that.
What's Content administration? Could you give an example or two of modules which would fit there?
What's a Site building tool? (I'd say http://drupal.org/project/drupal would fit in that category :-)
Some other categories I've thought of are Navigation (for menus and breadcrumbs), Comments, and Forum. I'm not sure if all of them would be big enough to be viable, though.
Come to think of it: It's pretty hard to choose a good set of categories without seeing examples, and seeing how the various suggestions will work in the wild. If Someone (TM) can set up a test site with http://drupal.org/project/cmt or http://drupal.org/project/community_tags, copies of all the module descriptions, and some intelligent views, we can try out different categorisations and see how they work -- see which categories get too small or too big, which ones overlap too much, etc. etc.
Is this something which could be done on scratch.drupal.org?
--
Hilde Austlid, Drupalchick
--
Hilde Austlid, Drupalchick
Content administration I
Content administration I wasn't sure about. I was thinking about modules like modr8, taxonomy_manager, workflow etc. - maybe it could be split though. Site building - stuff like cck, views, panels - these are well known as the 'core modules that aren't in core' so maybe it's not such a bad fit?
A separate category for module groupings sounds good.
Navigation - yes!
Comments - definitely.
Forum is already there ;)
A test site sounds good - there's a drupal.org testing profile but I don't know if it's got real projects in it, probably not.
I can't believe I didn't
I can't believe I didn't look for this sooner, but I opened an issue to add a category a while back that I think is going to be necessary soon, if not already: http://drupal.org/node/218885
I put 'games' in,
I put 'games' in, 'amusements' would be better though, edited in to the first post.
This sounds exciting! I am
This sounds exciting! I am big fan of taxonomy!
Netlink Technologies Ltd
http://shyamala-drupal.blogspot.com/
Shyamala
Unimity Solutions