2) Encourage the community to mark up modules in terms of the kind of site they’ve used them on. You might want to separate this kind of markup from the standard list (which does and should aim to describe the module itself). When I think about it, this might work best as a special kind of comment on the module. (An ‘I can haz…’ comment?)

So that if I need something for LDAP for instance, I might only type in “access control” or “authentication” and any of the LDAP or Shibboleth or other such modules float to the top.

tagging allows the community and the module owner to set up what the module should be catagorized as. and reduces the level of admin time spent catagorizing things.

Fundamentally what we have is a large collection of elements. One element (user) is trying to find another element (module) based on what they’re looking for. “What they’re looking for” is rather ill-defined.

Guess what I just described? Dating sites. Guess who has a LOT more experience than we do in matching up one element with another based on vague and hand-wavy criteria? Dating sites.

Now naturally we can’t borrow the UI directly from dating sites; Whether or not a module likes pina coladas or getting caught in the rain is not particularly relevant to whether or not it will help you build a real estate site, but could the interaction model (on both the module author’s side and the searching user’s side) of a few major dating or social networking sites be a useful model to study for ideas?

I am liable to agree with you, Sun: Most of the “narrow by” options I listed would probably not be very useful. (I just listed all I could think of . . . )

So . . . let me revise/clarify my point to say that “faceted search” in general is the best way to go, regardless of which fields you use as facets.

If I were designing it just for me, I would probably just list every available facet with the more useful facets at top (e.g. your “related”, “category”, and “tag), but I can definitely see the “less is more” approach as well.

The thing is, though: Facets allow you to ‘test’ out categories or fields to see if people find them useful. You can always take them away if they are not – or if they are, you can change the way they are displayed.

For instance, “related modules” (if it turned out to be a popular way to browse modules) could be broken into “Required by”, “Dependent on”, and “Often used with.”

I also have no problem with adding more detailed taxonomies, e.g. “site type, object type, process, etc.”, but in my opinion, the best way to see if these would be used would be by listing them as facets.

(*Personally, I might find them a bit overwhelming, but in some circumstances, I could definitely see them as useful.)

And of course, “tags” could be the true ‘catch all’ allowing users to organized things how they wish – and possibly providing fodder for additional fields, taxonomies, etc.

All good ideas, really . . . I guess I was just thinking how “I” would like to search/browse modules, and faceted search would be at the top of my list.

As far as the modules you mentioned (like Flag, WYWSIWYG API, etc.) not showing up in a faceted search, they would only not show up if people used the # of downloads narrow by option.

Personally, I agree w/ you that these modules are awesome and I would probably rarely use “total # of downloads” as a facet myself, but in some cases, I might want a way to judge how “well-established” a module is – although maybe “# of downloads this month” would be more useful for this purpose.

Really, that’s what we should have learned from drupalmodules.com – popularity only helps modules and their developers, not users. Based on their current stats, modules like Flag or Wysiwyg API wouldn’t appear in your search, although they are frickin’ awesome and will radically change how users work with content in Drupal.

When I am searching for modules, I usually search directly on drupal.org, starting with the keywords of related objects, f.e. “breadcrumb”. If there are too many search results, refining the search by adding another object keyword of the feature I want or imagine, f.e. “breadcrumb menu”. That, and only that will let me find “Menu Trails” for example, another core-worthy module in contrib that has not seen much popularity yet.

Also, given the amount of new CVS account applications we receive each day, and the number of new modules published a week, all the release and statistical data isn’t that meaningful.

Admittedly, I’m an advanced user and I’m searching for “Drupal internals”. However, that’s the reason why I’d like to see multiple vocabularies that categorize a module in various ways, but still build on a structure.

P.S.: You can already see modules by maintainer this way: http://drupal.org/project/user/sun

So, for instance you could do a search for “tabs” or “video” or just leave the search box blank (for browsing) and be presented with a list of search results with a left-hand “narrow by” menu, e.g.:

by user rating

5 stars
4 stars
3 stars
2 stars
1 stars

by downloads

10,000+
5,000+
2,000+
1,000+
Less than 1,000

by compatibility

6+
5+
4.7+

by maintainer

JonBob
KarenS
merlinofchaos
No maintainer

by release

dev only
official release
alpha
beta
release candidate

by date of creation

2008
2007
2006
2005
2004
2003

by latest revision

November 2008
July 2008
October 2007
September 2007

by related module (parent, child, etc.)

CCK
Date
Calendar
Project
etc.

by category

evaluation/rating
cck
administration
event
mail
etc.

by tag (tag cloud?)

ajax
jquery-related
cck-panels-plus
acquia-related
well-maintained

# of bug reports, # of feature requests, documentation?, demonstration?, etc.

I also love the idea that others have suggested that in addition to rating and tagging modules, that drupal could somehow track those that you download and ask you to mark them as “tried”, “using on _____”, etc.

That way, you could eventually build some type of intelligent recommendation engine based on people’s personalized download and usage habits, e.g. “people who downloaded this module also downloaded these …” or “based on your downloading habits, you may want to check out these modules . . . ”

It’s an idea – I know all of this is likely not possible right away, but they are just ideas.

Just a thought anyway.comment here.

I would recommend that you check drupalmodules.com. The searching on that site is significantly better, and ever for me, and advanced user, I get much better results.

You can also rate/review modules and put them in your favorites, which quickly shows what the important modules based on popularity. This is something I would like to see on Drupal.org.

I want to point out that I’m in no way associated with drupalmodules.com