Forum OpenACS CMS: Top Ten (or Five?) Features you want in an OpenACS CMS

To nail down a target for exploration of CMS that could be included with OpenACS, I want to define some features.

We have had higher level discussions about what a CMS is, and low-level implementation discussions, but no realy user-level, what-should-it-do discussion.

So what are your top features you would like to see in a CMS product?

After discussion, I will pick a few that can be implemented in a reasonable timeframe, and see where we can go from there.

Posted by Dave Bauer on
Here are some ideas:

Web based content editing.
Upload of HTML content.
Upload of binary content for download (images, word processing documents, PDF, etc...)
Upload of other formats, converted to HTML.
Web based assignment of templates based on content_type, folder, or other criteria.
Web based editing of ADP template fragments.
Upload of ADP template fragments.
Integration with other packages, ability to add ADP fragments to add content fromm other packges such as forums, lars-blogger, news, and others.
Categorization of content. (I would prefer to wait for the new and improved categorization package. Is there any timeframe on this?)
Compound content types. Building up a page from multiple pieces of content.
Integration with workflow to allow assignment and notification of the content publishing process.

Well that's a start. I think that the content repository has at least some support for all those features. I am pretty sure that the current CMS code also supports most of these features in some way.

We know that user interface and page flow will have to be customized. I want to do two things with CMS features. Support easy implementation of CMS user interfaces with a tcl library/service pacakge. Provide one or more default, easy to use, attractive user interface options to be shipped with OpenACS (not openacs core, but rather OpenACS based applications.)

Posted by Denis Barut on
Maybe the CMS should also able to work with different language (Internationalization of OpenACS Project).

also with .adp (i.e. index.en_US.adp and index.de_DE.adp)

maybe there is a link with the project above ?

Posted by Dave Bauer on

Internalization is a good goal. Are you referring to the content or the templates for the content. OpenACS already has a good effort on i18n of the templates.

The content repository also has a concept of i18n, but it is not quite in line with acs-lang and the i18n of user interfaces.

So this is definitely a goal, luckily we don't actually have to design this into the CMS, but into the content repository so it can be reused by any package.

Posted by tammy m on

I will just list some of the features that other CMS's I've been reading up on offer that sound useful...

Some sort of check-in/check-out for co-authoring of documents.

Document/page caching and writing to file-system (import/export).

Extensive search support; generate multiple search indices for different languages +/or content areas of site and content types. Search PDF, Word, Excel, etc format documents.
Search metadata so can add, edit, version and search to locate content based on content type, data types, categories, language, keywords, etc.

A lot of CMS's now integrate with CVS or some such and provide versioning and parallel development. I think it would not be trivial to work CVS into the current CR/CMS setup though.

Ability to do versioning of sections/areas of the site in CMS versus single content items only. e.g. compare, and rollback single components, site sections or whole sites.

There is a visual annotation component for managers. I don't know if workflow provides this already... to enable managers to provide comments and easily mark-up pages from a browser to provide feedback for authors.

GUI for template building.

GUI for workflow.

"XML object model for element level asset collaboration, reuse, management, versioning and search." Sounds neat! Might be so abstract as not to be of much practical use but thought I'd point it out. Seems to be a marketing plus anyway;)

Then there's LDAP (security) and WebDAV (desktop integration) support, etc.

Some sort of content aggregation and deployment like distribution and sychronization between mutiple servers (clustering, load balancing, whatever). This is more a server function.

Personally, I think extensive search support is kinda critical in a CMS. Probably checkin/checkout for co-authoring too.

Posted by Dave Bauer on

Search support is provided by the search package. The improvements you suggest, if made to the search package would improve search sitewide, not just for CMS applications.

I am not quite sure how a GUI for template writing or workflow definition would work.

WebDAV support is somewhat in the works, with an effort to get webDAV support into AOLserver. Its not quite ready for integration with OpenACS yet.

is the idea to refactor the current CMS package or are we starting from scratch? Does the current CMS package actually work? I'm helping Greenpeace with workflow support so I could provide some assistance in that area.

Personally I would like to see an ultra simple CMS package with workflow support in a simple admin UI, a user UI that allows browsing of content folders in say a left menu, and the content items (articles) just appear in a list. Shouldn't take long to build such a package.

Posted by Dave Bauer on
The goal is to build another package. CMS works, for the most part, but is not really usable. It also uses the old acs-workflow, and exposes the wrong bits in a programmer friendly way. It is almost a nice user interface to the content repository pl/sql apis.

There are two goals. One to build a nice cms framework package, and two to build a nice CMS user interface package to include as a sample with OpenACS. We know that people will want to customize or build their own user interface, so we want to move as much common code out of tcl/adp pages and into  a tcl library. The current CMS package contains much of the logic inside the pages.

Posted by Dave Bauer on

The goal is to also reuse as much existing code as possible! So code will be borrowed and reorganized to make CMS into a more of a service package. Another source of good ideas is the BCMS package in contrib.

Dear Dave,

So I'm sitting here thoughtfully chewing a cheese and tomato roll and one word is solidifying in the front of my mind... Strategy. With this in mind, we could set out what a top ten would be for the people intended to use the end product. Then we could add a top five that all our people would see as absolutely necessary for the future. But it all depends on what we want to do down the road, which means - you guessed it - a strategy is key.

For example, perhaps we could build this CMS thing by doing this: first we build a simple version - it's easy to install, easy to set up, and darn pretty! We actively grow a user base for this version. A good mini website would help, with documentation. And pictures! And a person we can email… perhaps a forum. Then, when we've grown the base of people using it - built up a community of users and testers - we move into making CMS Lite into a Delight version.

Now, when I say a user base I don't mean people that we sell our services to, and sites we make for them on their behalf! No! I mean we set up a situation where people come to us and download the product and install and configure it by themselves. More power to the people!

What kind of 'first stage' person would want to play with and stay with a CMS? I think we can learn lessons from the PHPnuke/Postnuke communities here. Overwhelmingly, what they want is:
Something easy to install
Something instantly intuitive to use - good user interface
Something that they can make look like 'their site' within a few minutes

A community based web toolkit should really look at the latest killer techniques in building communities online. Which is why I'd say that in this strategy what we might want to do is build in a way to take content from other people's sites, just as you can with most blogs these days. Let's use the most successful part of the blogging phenomenon and build it into the basic product - keeping our sites firmly set building a user base.

So I think that the initial emphasis really has a strong visual element. The user interface has to be great - extremely clean, pretty and intuitive. And to make a site 'theirs' in minutes, we're going to need to look at creating skins and setting up the visual look of a site design through the web. (By that I mean the design as in the way it looks - colours, headings, font sizes, position of pictures on the page etc.)

Posted by Dave Bauer on


Ok. I think your strategy ideas also reflect back to the entire OpenACS product. We already have a package that can consume RSS feeds, news-aggregator. We need a way to be able to output the data into another page via an include.

We already have the ability to produce RSS output, more packages need to take advantage of it.

Similarly, making it easy to change the look of a site extends to more than just the CMS product. Perhaps a CMS product could be an example to be used in the other pacakges.

So I agree with this strategy, and definitely my goal is to make sure, that regardless of the number of features, the product always looks great and is easy to use.

I really like Danielle's strategy here. It seems like a good plan.
Posted by tammy m on

A GUI for template building would basically let a user create content-types and basic/default associated templates from a web-based form. The content-types + templates would be usable immediately like in ETP. But instead of programmers creating content-types in code like

etp::define_content_type howto_article "HowTo Article" "HowTo Articles" {
    { author Author Authors string "cols=80" "" }
    { category Category Categories string "cols=80" "" }
    { desc_title "Description Title" "Description Titles" string "cols=80" "" }

Users could create content-types from a web-based form with pulldowns for each field/attribute that could be added, a text field for the attribute name, a pulldown for the associated default widget for the auto-generated basic template, etc. The content-type created is then available for all users to created pages from. Then the basic template generated could be copied and altered for more advanced users.

I have seen this functionality in other CMS's but of course now I cannot remember which ones.

There are lots of workflow UIs we could look at for examples. I know Stellant and Hyperwave have them but probably so do Midgard, OpenCMS, Typo3, etc.

Here's my "top five" RIGHT now:
  1. Use/improve file storage (simplify the permissions interface, upload of zipped files, get webdav to work, support multilingual versions of same content, etc.). File storage seems to be all we have right now to deal with any content other than text in forms (or where do you upload a file you want to publish on if you do not have an account on the box itself?).
  2. Add Edit-This-Page to file storage. Adding an edit button that calls up a polished ETP UI for text/html content types would go a long way.
  3. A way (e.g. publish button) of creating a static copy of a file storage instance ("site") in the file system (so AOLServer can deal with things like the Slashdot Effect and users have a VERY portable static copy of their content). We could even provide some "pretty demo sites" as Danielle suggest, that could be included with the package and published "at the press of a button".
  4. An easy way for users to add additional metadata (attributes in ETP?) and get them to show up in the content (stuff like created, published, last edited, abstract, authors, keywords, etc.). Something like what Tammy suggests (UI for adding content types and attributes in ETP)?
  5. An easy way for users to add workflow to the equation.

I would like to wrap OpenACS packages and ".LRN groups" around content publication. Examples: list of links to content in file storage an author/editor/publisher needs to edit/approve/reject/publish today (workflow portlet), author invites a coauthor to work on a document (.LRN group), a discussion evolves around a piece of content (group forum), deadlines are set for publication (group calendar), log for time spent on specific jobs (group logger), etc.

Hope to make the CMS chat in a couple of hours.


Hey Carl,

starting with file storage is not such a dumb idea - in fact it's a fantastic idea! It gives us hierarchical structure, versioning and mime base file typing...

#3 kinda scares me though - makes me nostalgic for Userland frontier ;) it would not work for complex templates that change, but maybe not such a bad idea. I would think more of an automated caching system to cope with the slashdot effect.

if i stay awake see you in irc

16: Gooey editing (response to 1)
Posted by Guan Yang on
I would like to see integration with the GUI editing control in Internet Explorer (with a filter to convert its output to proper XHTML), as well as Mozilla. This is pretty important if you want a CMS to be used in real-world environments that use CM. Users don't really want to learn HTML.
Having thought more about this in the shower, I whipped up the following page:

the first item is an etp page with my file-storage based cms thoughts. registered users on my site have edit permissions, so feel free to add comments or improvements!

Posted by Dave Bauer on
We really do not want to base a cms on file storage. The interesting bits are in content repsitory. The CR supports assigning templates, including combining the templates with content to the filesystem if desired.
Posted by Jun Yamog on
Hi Mark and Carl,

Its not my current interest.  But surely some others will have interest to in creating a fast solution.  I am sure we have different interest.  What would be great is to group people with the same interest and hopefully put some cooporation.  For example Carl and Mark is interested in making a quick cms based from file storage and etp.  We can then meet on it, and have you guys assign to do it.

Me and Dave is interested on longer term stuff, we can work on it together.  But that doesn't mean, camp A and camp B.  We need something like Team A does project A, Team B does project B.  We can also meet and assign task that may have dependecy from project A and project B.

You might also want to look at my old work on modETP.  It already does the things you have listed.