In this Brasil Module Pack Thread they list over 100 XOOPS modules, and it is not even all of them. (Some on the list are blocks, not modules, but I'm not sure users care).

As the number of modules increases, I find it gets harder and harder to keep track of them all.

So, I took a stab at trying to create a categorized list. I would like others thoughts on this... better category names, modules belong to another category, etc.

Here are the categories I've come up with so far:

Administration - Helps you administer your site
Application - Integrates XOOPS with an application
Banners - Banner Ad management
Calendar
Chat
Contacts - Allows storing of additional user data
Content
Content : Articles
Content : Wrappers
Content : Management
Display - Shows the user auto-updated information
Display : Site Info
Display : Syndication
File Tools - Tools to upload, manage, or manipulate files
Forum
Mail
Navigation - Helps visitors navigate the site
Picture Gallery
Shopping/Commerce

This is what a categorized list might look like (first draft). I don't know if this is worth doing... and keep in mind, this is just the list from the the Brasil pack... there are tons of other modules (which I would be happy to track down and try to categorize if anyone finds this useful).

Administration - Helps you administer your site
antidos
backup
errorhandler
estadisticas
meta
optimize
phpmyadmin
phpsysinfo
statistics
sysinfo

Application - Integrates XOOPS with an application
cdbase
mantis
wsproject
wsproject-beta-v.0.7.2.s

Banners - Banner Ad management
phpads

Calendar
agendax
eCal
tinyevent
xCal

Chat
irc
msn
shoutbox
xoopschat

Contacts - Allows storing of additional user data
addresses
adresses
contact
contact_plus
visitors2

Content
blog
glossaire
gsdownloads
spotlight
wffaq
wfquotes
wfsnippets

Content : Articles
tutorials
wfsection
wakka

Content : Wrappers
cjaycontent
easyweb
freecontent
tinycontent

Content : Management
relations

Display - Shows the user auto-updated information
analogclock
quote4xoops
randomquote

Display : Site Info
count
counter
lastposts
Popularity
userinfo
userpoints
uservisit
whosonline

Display : Syndication
agnitioVirusInfo
babe2
comics
horoscope
RandomBabe
vlweather
worldtime
xoopsvirus
xp_syndication
XP-Weather

File Tools - Tools to upload, manage, or manipulate files
filemanager
uploader

Forum
IPB_module_1.1.3

Mail
sqmail
webmail

Navigation - Helps visitors navigate the site
dropdown
iMenu
multiMenu
mymenu
treemenuxl

Picture Gallery
magalerie
myalbum
uskolaxgallery
xoopsgallery

Shopping/Commerce
pricelist
shop

Uncategorized so far:
altern8news
anni
avantgo
blockies
c-html
citas_daten
couleurs
Detente
dms
ecoTut
evennews
fetedujour
formulaire
google2
googlestats
historias
icontent
impressum
incblocks
Inconnue_reference
khat
liaise
lykos_blocks
lykos_reviews
metacat
meteo
meteoconsult
mrbs
myAds
myquiz
page
PP-News
prensa
radio
rightklick
sample_module
team
theaterman
tv
utstats
wfsRPC
whatnews
xdirectory
xonline
xp-radio
xp-ref

sunsnapper:

In fact this will indeed be useful. There's in the horizon a thing called the module registry, where we'll keep track of every module we can find and its features, and certainly having a nice, uncluttered organization will ease things for every xoopser around. Thanks for this draft and for the time it required to do it.

Cheers.

Hopefully I've identified the correct category for these, and others will comment with suggestions for new categories or placements.

When you get ready to roll on the registry, I'm happy to help.

The other thing that would be nice in a registry would be to not have it cluttered up with old versions of the same module. Perhaps old versions could be available in a version history instead.

You are correct. In fact, this could be a good moment to ask the XOOPS community about ideas for the registry. So far:

1) All modules available could be stored in a central repository. This would allow translators to provide language constant files in order to make them available with as many languages as possible.

2) The modules would be organized by categories.

3) The registry would show only the latest version of each module.

4) Each module would have maybe a page describing its features and limitations, and also links to historical versions.

And of course, we'll be needing all the help we can get if we want to succeed in taking XOOPS where no other open source CMS has gone before . Any more ideas?

Quote:
I agree with all the above, just one thing to add: compatibility to core systems. If a module need to be changed because of the core changes, then we'll need to add older versions for older core systems. For instance: 1.3.x, 2.01-2.03, 2.05-2.1 those kind of ranges. That way when people have a site up and running on an old core, they still can get their modules to work on them

Herko

I reckon you need to add a block category (as the only way to deliver blocks is in a module)

Also an email category (for both mailing lists and pop3 plugins...

Herko, do you favor one organizational view over another? Example:


Though in looking at it, it is probably easier for the average user (and easier to maintain?) with the following organization:



From the point of view of the module, sometimes the only reason a new version of the module is released is for compatability with a new XOOPS core.

I guess it just depends whether the presentation should be XOOPS version centric or Module centric. Since the information will be in a database, I guess both views could be available to the user.

In any event, regardless of which presentation is chosen, the registry will be a great step forward.

Sunsnapper,

I looked through the list and could not see:
Headlines/RSS Feeds & Syndication

Cheers,

Gamut

Quote:

I personally prefer the one I included in the quote. At the moment it is not yet possible to have multiple categories assigned to an item (which is needed to have both presentations), but the devs are working on that.

Herko