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)
I rely heavily on delicious bookmarks to find known modules, so I like the idea of allowing users to tag module descriptions.
Honestly, I think that drupalmodules’ beautiful ajax search is the way to go. Having the ability to quick search for terms with the title of the module, or the body allows me to quickly find modules that I need. Finally, having the ability to sort by a variety of different attributes such as number of downloads, reviews, last commit… all help in this process.
What I really need, is a way to bookmark, store and organize all the useful information that I find in Drupal.org.
This is especially true for Modules, but can be true for doc, issues, people, etc…
Today I use a bookmarking tool to do so (diigo and google reader). And when I find a module that sounds interesting to me, I bookmark it, associate some keywords so that I can come back to it later.I do the same thing for doc or issues or other stuff.
We could build something similar within Drupal and add extra power by combining your own bookmarks with the ones of the other members of the community. Being able to do “best of” or topic lists, to refine by content type (module, doc, theme…) etc, etc…
So this is for free tagging. I know i did not answered your question for a controlled vocabulary. You could have a :
* Site type vocab : community, wiki, blog, multimedia, geomapping
* Object type vocab: node, user, taxonomy, admin, theme, menu, block, query, context
* Process vocab : building, administering, navigating, theming, searching
I agree with Matt. I like the module search at: http://drupalmodules.com/module-finder
ditto ineation’s request for bookmark and annotate abilities . . . also sharing, rating, and tagging would be nice.
All support “refinding” and also discovery.
Especially rating which helps if you want to see the “best” modules.
Also searching by # of times downloaded, people who downloaded this module also downloaded this, etc.
Don’t know how possible all this would be – but that kind of info might be really useful.
I have been using Drupal for about a year and everytime I start a new site it is like starting all over with modules. I have done a newspaper, an working on a record label site, a musicians site with a deep catalog, and a concert locator site. All have very different needs when it comes to modules.
I would love to see a “recommended” section with things like CCK, Views, and other items that pretty much are used on almost every site. I would love to see a media area. Something that pulls out the items that support audio, video, and their assorted options.
A rating system or an “I used this plug in for…” would be really nice.
But mostly I just want to put in some keywords and have a useful list come up.
Depending on the timing of the project, I would be willing to work with you on a ‘controlled vocabulary’. this can be supplemented with tags/keywords entered by the module creator/maintainer.
Hopefully this helps. Because I have a folder full of modules on my desktop and can’t remember what half of them are for anymore.
Please take some hints about the Firefox modules page.
https://addons.mozilla.org/en-US/firefox/
The Drupal module landing page should offer:
0- A main Drupal version switch (All, Drupal 6, Drupal 5) to filter the content.
1- Prominent search with a main filter.
2- Alternate search with advanced settings.
3- Landing page recommendations (list 5 (or x number) of recommended modules).
4- Provide a menu to reduce the scope of shown modules (from all to, for example, CCK modules). This menu should list all module categories.
5- Format all list to let the user switch to date order (new or updated), alphabetical order, rating order or popularity order.
6- In list view, show a subset of the module information. A collapsible arrow should expand to the module teaser text.
7- Let user comments on modules. Currently on Drupal modules can’t be commented on.
Keep up the good work.
Cheers.
That’s an important observation. Something that tried to measure this and display the reality on the project page would be good. I’m not sure if “lines of code” is a good enough metric. Maybe some measure that the project admin could use.
We often see “This is a lightweight module” or “this is a huge combination of modules” on a page. Having a standardized way to describe that and display it would be good.
I started using Drupal for a large website redesign 60 days ago. I am an experienced web dev that has used numerous cms systems. Drupal is so remarkable it has almost become an obsession, the documentation/website/etc is so horrible I am frustrated daily.
Drupalmodules.com has been a lifesaver. I am using 6, so that is easy to filter. I can see new, popular, the presentation is quite easy to read, there is minimal scrolling. The wizard is pretty nice as well.
The design comp didn’t do it for me at all, I felt like I was drilling down into categories and not seeing a whole lot.
I totally agree with ineation in #3.
Multiple vocabularies would make sense and would help to define/refine a search by different scopes:
* Site type: community, wiki, blog, multimedia, geomapping, …
* Object type: node, user, block, taxonomy, page, admin, theme, menu, database, context, …
* Process type: building, administering, navigating, theming, searching, …
Taking greggles in #8 into account:
* Size type: lightweight, helper, API, collection, integration, full, …
Hey, not sure if this is still of much use, but about a year and a half ago I wrote up a working draft to an improved module categorization. It didn’t get very far back then, but here’s the link anyways: http://groups.drupal.org/node/3447
Drupal has definitely reached the stage where paid full-time technical editors should be tasked with organizing and writing documentation about both core and the more important contrib modules.
A controlled vocabulary to facilitate identifying modules is just one task that such a staffer should be put on.
And allowing voting/ranking like the drupal modules site would also be helpful, not only for modules but for the community-generated doc content. Ideally combined with a credibility ranking system for the contributors, whose votes would then count for far more than random visitors.
I second Jacques – the firefox add-ons site could be a good place to take inspiration.
It would definitely be a clever move to interview John about his Experience on drupalmodules.com, he will also have very valuable statistics on how people use his site most, what terms are mostly searched for, which way (most downloaded, module finder, newest) ist mostly used and so on.
The Ajax module finder is very helpful I also believe, but it has some weaknesses maybe inherited from the actual d.o. issue queue: why is the default search setting in “starts with” for the title? When I search for a module, I want to type in a term right away, that describes what the module does, which may not be reflected by its title. As the search could easily be weighed by popularity of modules, this could be rather exact. Here a list of terms I’d find sensible:
image, rich text, forum, gallery, seo, google, search, points, multimedia, video, audio, design, templates, structure, menu, tagging, taxonomy, access, wysiwyg, profile, community, image gallery, comments, blocks, youtube, shop, ecommerce
I agree with most of your assessment. It is a good overview regarding the state of Drupal’s module presentation.
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
Type your To guage the importance of a module maybe you could look to dependencies. If there was a way to show which other modules are dependent on the module then this could indicate the relative importance of a module?
Just a thought anyway.comment here.
Just scanning the list of comments, I noticed a couple regarding Drupalmodules.com (DM). I would second this option. DM’s pretty good at finding the most popular and highest rated modules. However it falls short of allowing users to find modules based on task. Fort that, maybe a short term solution would be to allow the community to tag modules with tasks. For example CCK could be tagged with “create custom fields”.
So, I have been following this conversation by e-mail, and it occurs to me: I realize you are probably just looking for ideas regarding a new taxonomy for modules, but I think the best way to make the modules more discoverable is to create an extensible “faceted search” search interface using any/all available fields related to each module (with the ability to add more in the future).
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.
Re #18: I don’t know how you are searching for new modules that you do not know yet, but from all options on your faceted search list, only “related”, “category” and “tag” would make sense to me.
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
Re: Sun
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.
I’m going to throw out something totally wacky. It may or may not be a good idea, but it’s a different angle to consider.
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 agree, faceted search may be the way to go. Users should be able to find by task by just typing in a keyword relating to the task. For example, “create forms.” any module that contained forms would be returned, and the user can continue to take on, or click until they find what they are looking for.
Post number 1 already says what I was thinking. Allow people to freely tag each module after they’ve logged in.
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.
Two suggestions:
1) A ‘canon’ of modules – i.e. a privileged group of modules which the community thinks every new Drupal installation should (at least) consider using when setting up. Maybe a voting system would work best here.
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?)