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
- 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
- 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 :).