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

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

Denis,

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.

Tammy,

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.

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.

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

I really like Danielle's strategy here. It seems like a good plan.

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 openacs.org 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.

Carl

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.

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.