Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Beatnik (493)

  (email not shown publicly)

A 29 year old belgian who likes Mountain Dew, Girl Scout Cookies, Tim Hortons French Vanilla Flavoured Cappucinno, Belgian beer, Belgian chocolate, Belgian women, Magners Cider, chocolate chipped cookies and Perl. Likes snowboarding, snorkling, sailing and silence. Bach can really cheer him up! He still misses his dog.

Project Daddy of Spine [], a mod_perl based CMS.

In his superhero time (8.30 AM to 5.30 PM), he works on world peace.

Journal of Beatnik (493)

Sunday August 24, 2003
02:25 PM

Survey: Which feature do you expect in a good CMS?

[ #14291 ]
As an attempt to improve the usability of one of my pet projects, I decided to ask what you would like to see in a CMS (Content Management System). Easy access to documents? Calendering? Contact management? News managment or bulleting board features? XML support? GUI client? Speed? Ease of installation? Documentation??

Comments! Comments! Comments!
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Hackability (includes documentation)

    Ease of use (includes documentation)

    Scalability (efficient programming. No needless complex and large OO structures for simple templating, for example)

    Image management (javascripts to insert the images in the html after uploading)

    Almost everything disabled by default (options enabled only when needed, so simple things can stay simple)

    Comment fields for internal use (at least one for every type of storage)

    Integrated version control and easy backups

    A good way to sepa
    • I forgot:

      Mailinglist interface. If the CMS supports news items, it should also support sending the news to a mailing list.
    • What if I provide a very easy way to add both front end handlers (preprocessing certain tags) as back end handlers (adding admin sections) by just allowing module drop-in? :)

      Documentation is always a hard part but I already included POD everywhere.

      Obscure URL bits.. I use mod_perl handlers, for example to fake real HTML files.

      Alternative Interfaces shouldn't be a problem, I barely have any layout data hardcode (except for some form generating).

      I'm not sure what you mean by Image Management...

      Version C
      • Image management ::= the ability for the user to upload an image and have it inserted in the page that is currently being edited, at the location of the text cursor, combined with means of removing images from the server

        Comments for internal use ::= comments attached to pages, images, forms, etcetera, used by the people who maintain the site. I include these things with every project, and people always seem to find a use for them :)
  • Flexibility. Power. Simplicity. Think of it like Lego and you'll not go far wrong. Lots of simple building blocks that I can use creatively to make something more complex. No CMS can cope with all situations well though so decide what situation you wish to aim for and stick with it.
  • Don't do anything that the following three (in reality two) products do: Microsoft CMS, Vignette, Epicentric (now owned by Vignette).

    Don't try to box the developer's / Content Editor's (if existing) in. I.e. Don't allow Content Editor's to write HTML. And if they have to write HTML don't offer any edit boxes that write HTML for them.

    Keep the structure dynamic and allow for a sudden change in design concepts.

    Btw. The above is almost impossible... I konw this because I had to work with all the evil CMSs

  • Less code, less features, less screens, less stuff users don't need. Just about every CMS I've seen is just too big to ever work right. I say figure out what your users really need, build just that and then stop. If some other users need something a little different, build a plugin interface but for heaven's sake don't just add it to the CMS.