CMS Shootout, the book (deprecated)

pnijjar

Part of the book: CMS Shootout, the book (deprecated)

This tree is deprecated. We chose Drupal.

CMS Shootout!

The contenders:

  • Joomla!: A fork of Mambo. Up and coming in the business world.
  • Drupal: popular in the open-source community.

Shootout summary

Please add information/properties as you see fit.

Property Joomla! Drupal
Must haves
Easy to update content Yes: web interface Yes: web interface
Timely security updates ?? ??
Post meeting information Yes Almost: issues with formatting front page
Post maps/photos for meeting Yes Yes
Highly desirable
Mailing list/forum integration ?? Yes
Match meeting topics and presenters ?? Maybe -- event module
Dynamic library page ?? Yes -- steph's plugin
Professional appearance Yes Sort of: (all Drupal sites look similar)
Easy to upgrade Yes (?) Yes (?)
Easy to customize look and feel Yes Not really: there are themes, but we do not know how to
customize the structure
Calendar support (website events) Yes Yes: event module
Code quality Does not validate Validates as XHTML strict
Nice to haves
Easy input syntax ?? Yes: bbcode plugin
User blogs Yes Yes
Modular design Yes Yes
Text-based browser support Almost: Front page Javascript Yes: tables w/CSS
RSS feeds for content ?? Yes, but not for specific forums.
Wikis ?? Sort of: book module
iCal support for calendars This should be a wash. phpicalendar will install most anywhere. All built-in calendars seem to have a high degree of "suck." --richard
Private Messaging yes IIRC Yes
Group mailouts Yes ??

CMS decision

Include your vote and any supporting evidence you would like to give.

marko votes: Drupal
marko says:

  • Drupal has the superior coding structure.

richard votes: Drupal

richard says:

  • Joomla looked to offer better control over ordering entries in a sensible way for the front page. This was an incorrect impression.
  • Forums in Joomla don't show up when people first log in

john votes: Joomla
john says:

  • Placement of content is easy to modify (module-based or template-based) in Joomla
  • Joomla is my choice for its attractiveness, functionality and
    modularity.

Website Details

Front page

What should the front page contain?

Meeting details: next meeting, future meetings.

Feed of what is happening on the mailing lists/blogs/forums.
(I liked the feed in the old PHPNuke site -- pnijjar)

I like the front page very sparse. Like a good business site. Just who, what, where, when, and why in
the most common form. Everything else should be linked below that. --richard.

Links to other content: library, forums, meeting location, about us, site map

What should other pages be?

  • Library
  • Forums
  • Meeting location
  • Minutes/past meeting topics
  • About us: who we are, what we do, how you can participate, what we charge, who we thank for making KWLUG possible
  • Site map: so we don't need to put all links on the front page.
  • Calendar of local and regional LUG events

(Also see: Child page)

What access rights should people have?

pnijjar votes: not everybody should have admin access, but every member should be able to post content to wikis/blogs/forums. Non-members should be allowed to read everything but not post everywhere.

richard votes: concur. Except the wikis. I don't like wikis. I don't know why. Perhaps because the remind me of clowns.

Forums

Do we need forums?

Maybe a web interface to mailing lists is good enough (see, for example, the Linux Kernel Mailing List frontend.

Counterpoints: the LKML interface is one-way, I think. People cannot POST to the list using the web interface.

Newbies tend to prefer web forums to mailing lists. Integrating the two would allow experienced people to have more interactions with newbies.

Should forums exist independently of mailing lists?

pnijjar votes: no. It is better to have no forums rather than forums that are ignored. Integration or death!

richard opines: Let's consider that then. Whack the forums. Use that front page real estate to point to the mailing list only. Less maintenance required. No tricky integration required. Just use a nice mailman (or whichever) page to access. Make the archives prominent, too.

What forum categories should exist?

pnijjar votes: keep it minimal -- announcements and discussion, both tied to the mailing lists. If we need further forums then we can create them later.

richard votes: Okay. Announcements and Discussion is fine. Topic / thread separation by Subject: line seems a natural addition and an easy filter to apply with existing tools. But let's keep in mind that we can get rid of the forums too.

Library module

The library module will keep track of what books/media are in the LUG library, and who has checked what out. The purpose is to make the library more accessible so that it gets used more.

What capabilities does it need?

Should library entries support comments?

steph votes: yes, so that people can post reviews of the books.

pnijjar votes: undecided. Maybe people could post reviews to the forums? Maybe to their blogs?

richard votes: no. I like the library. I appreciate the work that went into making the module for us. I haven't heard members asking to review books. I think it will go unused.

Categories/Tags

Drupal deals with taxonomies and categories. It may soon have support for tagging. What categories should we have?

Type tags

These tell us what type of posting the person has made.

Items: "review", "howto", "question", "announcement", "event", "meeting", "job posting", "cry for help", "editorial", "rant"

Next attempt: "howtos and tips", "LUG related", "employment", "reviews and editorials", "help me!", "buy and sell", "links and resources", "other events"

This is not perfect but it does have 8 items and not much overlap. It is not clear where politics and ranting would fit in. I am tempted to put something about "announcements" but that should not overlap with "LUG related".

Non-items: "tip" (same as "howto"?)

pnijjar says: we probably would like these to be disjoint if we are making a vocabulary set -- there should not be much overlap between the words.

pnijjar says: we can combine related terms into one category. Maybe we could arbitrarily say we want between 8-10 categories total? Keep in mind that we can create new categories as we go along.

Somebody posted the following list (I think it was me --richard): "business", "expert", "for sale", "hobbies", "howto", "link", "member announcement", "meta LUG", "newbie", "play", "presentation", "regional", "tip", "wanted", "work".

richard throws the list of distros in pnijjar's direction: While we at KWLUG are distro-agnostic, apolitical and care not at all for the whole vi vs. EMACS fracas, is not the ability to search for things related to a specific distro important to our members? From Newbie to Wizard, distro choice implies many things about how you will do things. One taxanomy must be distro. It can be ignored for non-distro posts. And multiple items can be selected when overlap is appropriate.

richard continues; it's a caffeine thing: Taxonomies will also offer guidance to members / posters. Is it possible to select both "Wedding announcement" and "For Sale" on the same blog post? No? Then perhaps I should reconsider offering my new spouse for sale on the LUG.

Content tags

These tell us what the content of the post is about.

Items: "hardware", "server", "desktop", "distro", "application"

pnijjar says: I don't know how useful these will be.

richard asks: hunh. Is this that tagging thing again? Like taxonomies / categories this is useful if it makes searches easier. If it is only for those infinite font collection tag clouds, I think we can leave it off KWLUG.

Book Module

richard asks: should we allow grandchild pages?

pnijjar says: When pages are getting very long maybe it makes sense to have granchildren. Until then why not keep things on a single page?

richard replies: I think that was posted to see how the grandchild page / comment displayed. I have nothing against many levels of heirarchy when it makes sense.

pnijjar asks: should we use the book module or the wiki module?

pros of book: it comes standard, it supports revisions.

cons of book: it doesn't have Wiki-syntax, it does not have nice hyperlinking abilities.

pros of wiki: it may allow wiki-syntax, easy linking, it's called a "wiki"

cons of wiki: it is an external module, it is not clear what the advantages are over book.

richard says: Pros of book module. It's not a wiki.

Now pnijjar says: I was wrong. The book module wants every new header to be on its own page, I think. That implies we need lots and lots of grandchild pages.

richard can't shut up: That's okay. Shorter pages are easier to keep the paragraph tags straight.

Things to Do/Fix

Add to this list as you see fit, and sign up to do things!

  • Get an IMAP account so Bill Traynor can set up forum/mailing list integration.
  • Fix the favicon.ico for the page
  • Come up with some KWLUG-specific theme that does not feature Marvin
  • Put this book into proper book format, I guess.