dont know if this is the best place to post this.
i am usually a joomla user but i gave drupal a 2nd look and it seems a better option as a possibility for an intranet site; but while checking out the contributed modules list, two things come to mind:
1. for a cms which prides itself on the ability to categorise, i feel the list could be categorized a bit further. i am certain there could be some subdivision of the 160 "3rd party integration" modules to make it easier to sift through that lot, for example.
2. and i wish that developers would be required to have a working demo of their modules somewhere. perhaps an official "module showcase" site. as it is now, i imagine that i will have to download and install every one of the forum integration packages to pick just one. a demo would really be nice.
otherwise, good stuff.
Comments
A comment on demo's
While a demo of a module would be nice, it is not always meaning nor pratical. Many modules have an administrative component that in some cases is a large part of what the module provides. Two module that come to mind are the Content Construct Kit (CCK) and Views module. In both cases a large part of what they do is administrative (create content type or views) and it is not generally practical to open administrative interfaces up to the world.
Other modules (like LDAP) provide interfaces that strength of the module is hidden by the code.
So while it would be nice to have demos, I don't think requiring them is practical.
I think the documentation,
I think the documentation, isn't always the best.
I have found that I can get the information I need through several ways.
I can use the Search/Advance Search on this site.
I can click on the Handbooks and find everything from groups, to videos.
I can also search Google - I enter Drupal and then the module name.
The Google search has turned up some darned good results more often than not.
----------------------------
Demos would be nice, and some are provided.
I think if the module developers are as busy as I am, we're lucky to get what we do get.
Requiring things is always a way to say "Take your business elsewhere".
come on now...
there are module showcase sites for joomla. it shouldnt be impossible for drupal. perhaps one or two modules may not be suitable for "showcasing", but the majority should be, i imagine.
in fact, i confess, i was half expecting someone to say "of course we have a module showcase at www.etc..". too bad. perhaps when i get my head around the intricacies of drupal i should do it myself. i feel it is necessary, at least for good "customer service."
but the sub-categorizing of the module list is beyond my control. i am suggesting that someone with authority look into this. a flat list of 200+ modules is simply ridiculous. for good "customer service."
-------------------------------------------------
Always be nice to people on the way up; because you'll meet the same people on the way down.
Wilson Mizner (1876 - 1933)
I would like to see a demo
I would like to see a demo (or, better still, a site collecting all demos) of modules too. And while I agree that many Drupal modules cannot be "demoed", because they don't show any 'visible' results but only work "in the depth", many other modules' activities could definitely be demonstrated.
Or, if that is not possible or feasible, the Very Least many contributors could do is write a Readme.txt, in which they explain what it is that their module actually does, With real-life, practical, reproducible ways of how to actually use them, in non-developerese lingo. I'm quite sure many modules remain widely unused because nobody understands what they are meant to do in the first place. Wouldn't it be nice if the CVS contained some routine preventing the upload of a package which does not contain a readme.txt of, say, at least 5 K? Obviously, there is no way to make this into a hard rule, but it could at least be strongly recommended.
I know, I know, the main interest of developers is, umm, to develop, but writing a readme.txt only takes 15 minutes. Pleeeeeeaaaaase...?
Good news: You don't have to wait for a developer
You don't have to wait for a developer to do it. You could take your favourite undocumented module, write a description of what it does and how it does it (15 minutes, right? :-), and post it as a page under http://drupal.org/handbook/config/contribmodules. (Please take a look at the Handbook style guide first.) Then post an issue for the module, asking for a link to the new documentation page.
And how am I going to write
And how am I going to write a description for a module which I don't understand?? The problem I hinted at was that quite a few modules appear to be doing "something", but there is no way of knowing what exactly - until the developer (not me, unknowing bystander) takes the time (about 15 minutes...) to write a decent Readme.txt. I know I can contribute things myself, and I do, but I still feel a developer is far better placed to explain in humanoid language what it is that his/her newly-born is doing and how to implement it.
Ah, but the beauty of it is that you're not alone
If you describe a module you understand, and I describe a module I understand, and some small percentage of those who read this do the same, we can read each other's descriptions and all learn something. And the developers can do what the developers do best, and develop even better modules for us non-developers to enjoy.
Hm, that reminds me, I still haven't turned the notes I made when I crashed headfirst into Editable fields and after much gnashing of teeth and some testing finally figured out that there was something buggy going on into a handbook page. Say what, I hereby promise to make that page, or a page on another module if someone else beats me to Editable fields before (um, counts on fingers, looks on to-do-lists) New Year's Eve. And I hereby challenge everyone who's ever cursed under their breath about missing module documentation (that should cover most of us, I think :-) ) to do the same. Surely there are some undocumented modules that you do understand, or can understand with a little testing?
Of course you're right,
Of course you're right, Zirvap, and it would be ever so nice if all of us would contribute what we know or what we find out after lots of trial-and-error.
Still, it's a weird kind of logic: developers spend weeks or months to design something incredibly useful, and then the very final step, which to them is an absolute no-brainer, i.e. writing a very short descriptive text and some practical examples of what it is that they have done, that step they omit. Weird. It's like buying a new car, which has been painstakingly designed, assembled, exported, marketed, sold etc., and then the garage-keeper doesn't tell you where the key is. "Let all customers look for the key, and let he who finds it write a description." Hmm, I dunno. To me it sounds simpler that the garage-keeper simply tells you where the key is :-) I'm not starting an argument here, you know. I truly respect the developers, and I know the energy it takes to produce something decent. But my point is that all this energy could yield sooooo much more result and cause soooo much less confusion if they included some readme stuff, and some practical hints, or, if it makes sense, a working demo.
The last step should be the fun one! Hey everybody - it works!
This is actually a fair comment. I've (internally) lamented much the same situation with the themes but that's now being taken care of - YAY
If I was looking for excuses, I'd put it down to the hacker psyche. Most contrib modules started as someone wanting to scratch their own itch. Then they get it through proof-of-concept, or to the point where it does what was needed. Some of those go as far as then tidying up the interface and releasing/contributing it. But the actual explanations, or heaven forbid "documentation" sorta gets left out. The devs did it for themselves, and they know how it works.
As the hackers handbook says "If it was hard to write, it should be hard to read".
unset($cheek['tongue'');I however make a pretty heavy commitment to my docs, inside and out. Usually starting with a what, why, and how text overview.
Demos are actually a big pain to set up, as often the interesting stuff requires certain admin rights (I tried once) and a stand-alone sandbox setup that's secure and non-dangerous.
I usually go with a screenshot of the interface. That's a good step towards letting the downloader know what to expect.
Anyway, we Discussed documentation guidelines/requirements a little while ago and I came up with this page of Best practices for module developers documentation
... however, nobody seems to have taken much notice ;-)
Maybe some enforcement (which I poo-pooed originally) is in order!
Feel free to add/comment on that handbook page.
Or simply raise an issue against your favorite module and point them to that page as a 'task', like 'coding standards' is.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards