Making Modules Findable

Events happening in the community are now at Drupal community events on www.drupal.org.
leisareichelt's picture

cross post with: http://www.disambiguity.com/drupalorg-redesign-making-modules-findable/

One thing I’ve learned on this project so far is that if you’ve been using Drupal for more than about ten minutes, chances are you’ve had a look for a module or two.

Research participants are rarely unanimous but I think I can safely say that every single Drupal user I have spoken to has told me how difficult it is to firstly find and then evaluate the usefulness of modules.

So. That’s one thing we’d really like to help to fix in this redesign.

In the latest iteration, you can see where we’ve gotten to so far with the modules landing page - it’s a start but it doesn’t really begin to address the really difficult questions which are:

* how do people look for modules? and
* how do we design the interface and information architecture so that people can find the module they need?

Frankly, I could really do with your help.

Here’s the current version: http://drupal.org/project/Modules

And, here’s what we know:

* most advanced users will use Google search to find a module on Drupal,org using keywords that they think are likely to be in the module name
* advanced users refinding a known module are likely to use the URL (remembered or bookmarked) to get to the module page
* everyone finds it difficult to find a module from the current list of categories
* in some cases, the category names are not sufficiently descriptive or specific to be very helpful (3rd party integration is an example of this I think)
* in some cases, the category names are in ‘drupal-ese’ and meaningless to new users (new users don’t know what CCK is, or what Organic Groups are)
* modules can live in more than one category (this is not a bad thing)
* you can only order modules by category, date or name (check this)
* it is difficult to distinguish between a ‘big’ or important module ad a small, very specific module
* categorisation is very much about what a module actually does, rather than what you can do with it (for example, to use an example given to me the other day, if you’re looking for a module that will let you do listings for an estate agents site what module do you want?)

Here’s what I’m thinking

* we need to better support people’s desire to search for modules (hence the emphasis on search on the homepage and the associated massive improvements to the search capabilities of search for this site when it is relaunched)
* we need different ways to ‘cut through’ the modules to support different scenarios such as: I’m new to Drupal and I want to know which are the most important modules, or I’m building a site for an estate agent and I want to know what module would be best for making property listings, or I want a module that will automatically resize images depending on where I put them in my news site.
* we *could* try to do this with a controlled vocabulary, but would we ever be able to agree on what it should be. Unfortunately, I don’t have the time on this project to be able to complete it, and I suspect it would be extremely challenging to undertake this task as a community…
* we *could* harness the scale and diversity of the community and focus more on tagging in a less structured, more Folksonomic way - but this isn’t going to help guide people through the scenarios that need more support as outlined above…
* we probably need to do a combination of the two - with some broad, fixed ’structural’ categories, and categories that go beyond just describing an aspect of what the module does or how it does it, supplemented with community driven tagging, to help enhance the findability via search and possibly generate new additions to the controlled vocab.

So, assuming you’re with me on this (and that’s quite an assumption I know) - here’s what I need some help with… I could really do with some help compiling some list(s) of categories that would help people find modules in the usage scenarios I’ve suggested above. Also, if there are other important scenarios I’ve missed please let me know!

We should probably do this on a wiki, or something similar. But perhaps lets start with some ideas here and I can compile them into something more comprehensive.

Anyone got any thoughts on this? (Don’t feel you need to be comprehensive, whatever you've got is good!)

Comments

taxonomy and site showcases

catch's picture

I wrote up this a while back, have held off trying to implement any of it to see what comes out of the redesign. Project taxonomy revamp proposal.

I think we need both a structured vocabulary and a freetagging vocabulary (although that freetagging vocabulary might need to be restricted to module maintainers and other roles unless we make some better management tools for taxonomy). The categories on the past couple of iterations - specifically having sub-categories is nice (haven't compared the lists to the one I drew up earlier to see how they compare yet), and I think people expect that. The existing categories we have have grown quite organically though - and that means a lot of overlap, and some categories with 300 modules in which is no use to anyone narrowing things down.

For your estate agent example, despite hating estate agents, I've got one idea of how to improve that which hopefully wouldn't require too much work.

I think we could make use of site showcases here a bit more - i.e. in showcases, have a nodereference field which points to the modules used for that site. So a newspaper site might use views, cck, panels, workflow, voting API, a multi-media site might use emfield, cdn etc.

If we classify showcases by type of site, and have a proper record of which contributed modules we used, then we can aggregate this into "modules used by showcased newspaper sites", "modules used by showcased ecommerce sites" etc. etc. - the same information could be pulled from Site recipe howtos in documentation as well.

This would link module recommendations to actual Drupal sites that someone's spent enough energy to document putting together - which would mean in general appropriate recommendations of high quality modules. Additionally, filling in a few nodereference fields when posting a showcase shouldn't be too much work. It could also work the other way - when viewing a project, you could get a list of major sites using the module.

great list!

leisareichelt's picture

oh, that's exactly the kind of list I was looking for, Catch - thanks for posting that.
I've set up another card sort and I think I'm going to see if we can get any kind of concensus on maybe reducing the length of that list and using sub-categories - stay tuned.

can you tell me more about why you think free-tagging should be restricted? In my experience, part of the power of tags is that they are a complete free-for-all. this means that its more likely that someone in the Drupal community has described a module the way that I would (as an individual user with my own special vocab, and esp. if I'm new - a non-drupal-influenced vocab) .

leisa reichelt - disambiguity.com
@leisa

free-tagging

catch's picture

The main technical issue is that Drupal's built in free-tagging is restricted to the person who creates or edits content - so in this case the project node author, or someone with permissions to edit that node (about 100 people I think). So tagging of modules would de-facto be restricted to the individual module author and site maintainers. afaik this is similar to something like flickr (as opposed to del.icio.us). If it's just this sort of free-tagging we're talking about, then the built-in restrictions are more than enough.

If we wanted community tagging of modules, then that's a very different issue with a lot more requirements. There's some active work going on for tagging of project issues - see: http://drupal.org/project/comment_taxonomy and there's some contrib solutions, but in that case, a project like views or cck could end up with hundreds of tags, and Drupal.org is also a volunteer-run spam-target. Using community tags for tag clouds/listings etc. might work fine, but I'm not sure how we'd go about displaying them on individual project pages, if at all.

Project / site "recipes"

boris mann's picture

The nodereferences for cases actually extends to "Recipes", and is something I had suggested before. So, I'd like a more general use case that is a "recipe" -- people can submit case studies the exact way, they just select a recipe vs. case study taxonomy (or cck selector, or whatever).

Right -- I was thinking of

kyle_mathews's picture

Right -- I was thinking of something along the lines of "listmania" on Amazon. On almost every search you'll see along the left side lists of books or other products that match your search. These lists are on any and all topics. Here's one, for example, that Jeff Eaton compiled for wannabe Drupal developers.

So what if when someone comes to the module page and searches for "social networks" or "ecommerce" or whatever else, along one of the sides is returned matching recipes or case studies like "modules to build a twitter-clone", or "social learning site module list", or "ubercart for newbies" and so on. This could be really useful.

Kyle Mathews

Kyle Mathews

love it

leisareichelt's picture

i love this idea - the trick will be to decide how/when lists are displayed (where in the site), but I will definitely look into it!

thank you :)

leisa reichelt - disambiguity.com
@leisa

+1

OpenChimp's picture

I like this idea. It would make a good connection between modules and documentation.

People who new to drupal are going to go to the download section with the assumption that it is going to be easy to figure out which module to download to add a photo gallery to their website. Little did they know that there are 23 gajillion different ways of doing this, and that it would be best for them to do a little more reading before they decide on the solution that is best for them.

Better integration between the download section and documentation would definitely help new users in becoming more familiar with what the options are in drupal.

i think i need to know more about recipes...?

leisareichelt's picture

can you give me a quick heads up re: recipes?
does that just mean like a template? or something more specific?

thanks!

leisa reichelt - disambiguity.com
@leisa

recipes

catch's picture

.. are things like "how to make a discussion forum with drupal" "how to make a multi user blog site" - see http://drupal.org/handbook/site-recipes. They include site templates, and stuff which might cover a section of a site - like an image gallery. So it'll show you how to take three modules and configure them to accomplish X task. Similar to some of the more technical site showcases, except with more detail, and not real sites. Both could use the same node references to show which modules were used.

Modules don't rank for their own names

Brigadier's picture

I don't have a complete solution to the problem but I appreciate that you're trying to fix it. The one thing that really drives me nuts is when I use the search on Drupal.org with a specific module name and the search results primarily consist of forum comments using the name of the module (where, for some reason, people never link to the project pages). It'd be nice if maybe the search results were grouped. Or I suppose if the Advanced Search were a little easier to navigate then I'd use that.

definitely!

leisareichelt's picture

yes, we're definitely going to be recommending 'grouping' results so that you can filter for just modules, or just forum posts about modules.
it should make a big difference to findability.

leisa reichelt - disambiguity.com
@leisa

pivots module recommendation system

danithaca's picture

We are working with d.o. on the pivots module recommendation system. It adds a small block on a module page that displays related forum discussions about the module and related modules mentioned in the same discussions. Our next algorithm would be to harness the project usage statistics and display related modules enabled in the same websites. If we can have "freetagging" data, we can also develop recommendation algorithm based on that data.
Any suggestions that we can join force here and make modules more findable?

great news :)

leisareichelt's picture

oh excellent, this is good to hear. It sounds like you are building stuff that we're putting into our designs, which is great.
hopefully once the prototype gets a little closer to finished then all of the 'data' we'll be looking to have and use will be more apparent... stay tuned!

leisa reichelt - disambiguity.com
@leisa

pivots are a cool idea

starbow's picture

but I have yet to get a useful recommendation from them.

These days, when I am evaluating a module, I almost always pop over to drupalmodules.com, and look at it there. Their list of related modules is usually on-target.

I'd love to see a "my module competes with" section on the module creation page, where you can enter in all the modules that you know about that overlap with the module you are creating. It would be a nice complement to the "enhanced_by" proposal that is floating around.

add Version option to module issue filter

wiredescape's picture

Not sure if this is the best place for this but haven't found anywhere more focused...

After you do find a module, it is also difficult to sort through the 'version clutter' when drilling down to version specific issues. Adding a 'Version' option to the module's Issues filter would be a big help.