Formats for module comparisons

choster's picture

We have a lot of different formats for the similar module lists and tables in this group— I've experimented with a few different ones myself. I wonder if we as a group should identify an idealized format and the data points about each project we should strive to provide. To summarize my observations on what we currently use:


Annotated List
Examples: Dashboard modules, Node limiter modules
Pros: Easy to write; easy to read
Cons: Lengthy when there are multiple items being compared; difficult to do side-by-side comparisons
Comparison Table
Examples: Image crop modules, Booking system modules
Pros: Easy to read; easy to compare multiple projects; easy to edit if using wikitable markup
Cons: Depth of information shallow due to space limitations; comparisons not so easy for lengthy tables
Narrative Review
Examples: Wysiwyg API vs various textarea enhancers, Libraries support
Pros: Allows for highly descriptive and specific text that provides background as well as points of comparison and contrast.
Cons: Is a presentation of one author's opinion; difficult to do side-by-side comparisons other than that used in the text.
Unannotated List
Examples: Image upload modules, Tabs and slideshow modules
Pros: Super easy to create and maintain; quickly gives an idea of the scope of modules involved
Cons: Lack of in-depth data makes it useless for a true comparison

Comparison table layout

With the exception of Third Party Video Integration and one or two others, all layout tables place the modules in rows and their features or other data in columns. The number and type of columns varies greatly beyond the name and a link to the project page, which are invariable in the first column. Beyond that we may have

  • Dependencies/Integrations
  • Description/notes
  • Domain feature support - For some types of modules, one or more columns list support for features specific to that type, e.g. whether the module provides a block, supports a certain standard, or when a confirmation is sent (see e.g. Send email modules).
  • Info as of - Date on which the module information on the comparison post was last updated
  • Last commit date
  • Last release date
  • Links to comparison - Whether the project page links back to the comparison page or not
  • Maintenance status
  • Pros/Cons
  • Usage - Number of reported installations
  • Version - either a list of active versions, y/n in separate columns for D5/D6/D7/etc., or a version number in those columns

I have more or less settled on the format I used for the Comparison of reference/relationship modules, though I do think usage statistics are useful.

If there were an easier way to retrieve module data directly, say an input filter that could ping d.o and retrieve version numbers, dates, and usage, it would be far easier to maintain these tables, but of course I'd rather any spare energy be put into better consolidation and cooperation to obviate the need for this group :).


two level discussion

doublejosh's picture

This topic lives at two levels...

  1. How can ad-hoc comparisons be created as effectively as possible:

    Let's at least quickly answer this and present a "template."

  2. How might d.o enable more complete comparisons beyond "Related Modules?"
    • % Automation and/or % curation?
    • Part of main site?
    • Efforts required?

    This seems like a natural growth of meta resources and transparency as the project continues.

Merging ideas

scottrigby's picture

Hey @doublejosh - great idea!

I'd really like to see this discussion get fleshed out into a new succinct feature request issue summary in the d.o webmasters queue.

IMO automation like what you're suggesting could be paired with an idea @janusman suggested on another thread - to modify the d.o project categories into a multi-level tree:

If these ideas were combined, a lot of the above information could be automated into a similar module navigation (personally i'd like to see that on d.o, maybe as a tab on each project page, but with services initiative this could happen anywhere in advance of an idea like that getting approval).

The only thing we can't automate are the pros & cons. Something like that could be moderated by the community, but not sure the best workflow to suggest - maybe it's enough to discuss here whether such an idea is desirable, and if so, develop that new issue summary in the webmasters queue to see where it goes?