[support] navigating through Drupal modules

Thu May 7 13:11:33 UTC 2009

This is an amazing presentation of modules.

Here's a few suggestions if you don't mind.

1) I think one of the right nav boxes should contain the entire list of
modules because one feature you offer is (if I could quickly narrow the
group to a select list of modules) the dependencies.

2) I think you can tell a great deal about a module based on it's number of
downloads, latest revision date, number of issues posted about the module,
last date of that issue and whether (or when) the last issue was closed.

Your presentation method would take module discovery to a new level.

The only other thing I would ask is for someone to offer a place where
module users (like myself) could go to, relative to a specific module, and
post how the module was used by me. What I achieved and how I did it. It
would create be a self documenting project area of sorts.

-----Original Message-----
From: support-bounces at drupal.org [mailto:support-bounces at drupal.org]On
Behalf Of Annet de Boer
Sent: Thursday, May 07, 2009 1:16 AM
To: support at drupal.org
Subject: Re: [support] navigating through Drupal modules

Well actually I found the test site you made very usefull at first
sight! If there are too many modules to keep it on one page, there's a
possibility to make your visitors do a first selection to narrow down
the number of results, right? It's not an "all or nothing" case here.
I like the fact that you can see in just one line what the main target
of the module is. And the "Most popular" and "Most downloaded" tags
(which are used in most websites) are a bit obscene since they only make
the most popular more popular.. I was actually waiting to find a site
which would handle the information more like you did in your testsite.
So, don't let them stop ya ;)

Regards,
Annet

John Callahan schreef:
> Thanks Larry.  Had a feeling that was the case.  I've seen some Exhibit
> based sites perform OK with 800 - 1000 items and hoped that would fit
> here.  4500+ and growing is definitely out of range.
> I do like the Apache Solr faceted search much better than when d.o was
> at D5.  More metadata about projects would help.  Possibly less
> information returned per project to make it easier to scan.  Searching
> through all of the modules and finding the ones you need is a problem
> that I hope gets easier, especially for those new to Drupal.  I'm
> looking forward to the new design and trying it out.
> - John
>
>
>
> Larry Garfield wrote:
>> No we can't.  There are over 4500 modules.  A page listing all modules
>> and providing anything even resembling useful data would be several
>> megabytes in size just to view, to say nothing of the processing
>> costs.  We used to have pages like that.  They didn't scale. :-)
>>
>> The in-progress site redesign includes much more metadata on projects
>> and ways to search projects, in addition to the new solr faceted
>> search that was added recently.  Searching large data sets is not an
>> easy problem.  But simply dumping the entire dataset to the page is
>> not a solution at 4500 modules, and it certainly won't be a solution
>> as the number of modules continues to rise.
>>
>> On Tuesday 05 May 2009 11:13:50 am John Callahan wrote:
>>
>>> Yet another potentially extremely useful module I didn't even know
>>> existed!
>>>
>>> Can I make suggestion?   Can we have a simple, one-page listing of all
>>> Drupal modules, with appropriate tags, to allow for easy navigation and
>>> visualization?  Users can sort the list as they want.  With a few
>>> additional tags/facets (like core version supported, date, author,
>>> etc..), imagine how fast you can find what's available and start digging
>>> further.
>>>
>>> Here is a test I quickly put together for a subset of modules:
>>> http://geo42.com/sites/drupal-modules.html
>>>
>>>
>>> IMO, an automated list like this one is more helpful than any rating
>>> system (almost always fraught with problems) or the current d.o module
>>> lists (page-based, too much information, hard to quickly navigate.)
>>> Ratings systems, blog posts, projects like drupaltoughlove.com, usage
>>> statistics, etc..., are all great but only should be considered as part
>>> of the whole.  For me, they simply help direct where to look deeper.  A
>>> list like the above would make things simpler, faster.
>>>
>>>
>>> We all know that finding modules to use with Drupal is a difficult task,
>>> one with real consequences. There are no easy answers yet.   It's a task
>>> that turns some first time users away from Drupal and continues to
>>> frustrate some current Drupal practitioners. It's especially frustrating
>>> when trying to convince others in your organization (like the IT
>>> department) to go with Drupal; they start to delve into it and get lost
>>> in what can be done practically and securely via Drupal.  It's a great
>>> development design but difficult in practice.
>>>
>>>
>>> - John
>>>
>>> **************************************************
>>> John Callahan
>>> Geospatial Application Developer
>>> Delaware Geological Survey, University of Delaware
>>> 227 Academy St, Newark DE 19716-7501
>>> Tel: (302) 831-3584
>>> Email: john.callahan at udel.edu
>>> http://www.dgs.udel.edu
>>> **************************************************
>>>
>>> Justin Gruenberg wrote:
>>>
>>>> On Mon, May 4, 2009 at 8:20 AM, John Callahan
>>>> <john.callahan at udel.edu>
>> wrote:
>>
>>>>> 1) batch upload, even if only one directory
>>>>>
>>>> http://drupal.org/project/image_fupload
>>>>
>>>> That module provides a pretty nice way for you to upload images.
>>>> Probably not 11k at a time nice, but it does work well and does allow
>>>> you to fiddle with some attributes per image when you upload.  It
>>>> works with ImageField (CCK) and image.module.
>>>>
>>>> If you go the image.module route, theres some other batch upload
>>>> modules that can work with a directory on the server.
>>>>
>>>>
>>>>> 2) reading EXIF/IPTC image metadata and mapping them to taxonomy terms
>>>>> and/or CCK fields. 3) syncing attributes (i.e., edits to raw image
>>>>> EXIF/IPTC can update/reimport the node fields/tags and edits to node
>>>>> fields/tags can update the EXIF/IPTC metadata.)
>>>>>
>>>> I haven't done anything this complex with image galleries, but I can
>>>> say... expect to do a good amount of fiddling and possibly writing
>>>> some custom code to get what you want.
>>>>
>>>>
>>>>> I'm using Gallery2 right now (http://gallery.menalto.com/,
>>>>> http://drupal.org/project/gallery) and it does some (item #1 and
>>>>> partially #2) of what I need.  It even integrates nicely with
>>>>> Drupal for
>>>>> users and display of images and albums.   However, I use Drupal for
>>>>> many
>>>>> other sites (and I'd like to use views, lightbox, tags, etc...) and
>>>>> wondering if I can bypass Gallery altogether.  Any thoughts or
>>>>> experiences out there?   Thanks.
>>>>>
>>>> I'd say if gallery2 works for you, stay with it.  That's a package
>>>> thats built for hosting images.  If you're not afraid of getting your
>>>> hands dirty, drupal might meet your needs closer.
>>>> --
>>>> [ Drupal support list | http://lists.drupal.org/ ]
>>>>
>>
>>
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.325 / Virus Database: 270.12.18/2096 - Release Date: 05/04/09
17:51:00
>

--
[ Drupal support list | http://lists.drupal.org/ ]