Forum OpenACS CMS: ACS CMS 4.x Analysis

Collapse
Posted by Cristian Petrescu-Prahova on
ACS CMS 4.x has some strengths which make it very appealing. At the same time it has some serious flaws which bring it close to unusability - I have to admit it took me a few weeks until I truly understood how it works and from what I saw on this forum and on arsdigita cms forum I am not alone. Since it may be that openacs 4.x will have a new CMS, I would like to present my thoughts on the acs cms.

What is your opinion on ACS CMS 4.x?

Features

The CMS has a reach set of features. Besides basic editing/publishing tasks, it has a few other nice things. Probably the workflow feature is the most powerful (and a little bit underused ?).

What I feel is lacking a little is the ability to categorize content. Keywords are good, but not enough.

Data Model

The CMS may be regarded as an data processing + ui over the acs- content-reporistory data model. I think one of the biggest strengths of the CMS is exactly this data model.

It is simple, yet powerful, offerring a good basis for future developement. There are very few things I can think of, which cannot be supported.

One minor thing I find lacking at this level is a proper support for multiple languages.

Data Processing

The data processing is as good as it can get. It consists of a series of scripts & procs which update the database. Sometimes some abstractions may be missed, sometimes the abstractions get lengthy, but using this paradigm one cannot do much better.

User Interface

Here the cms team failed big time. It is nice to hear 'the cms is very good, you just have to customize it to make it work'. In real terms, this means you are likely to recreate almost all of the cms scripts and reuse some procs if lucky.

The most blatant error: the lack of separation between metadata and operational interfaces. It is very confusing when the ui puts item editing and content types editing at the same level - items are operational, types are metadata and it may take sometime until one figures that it will never see a content type on the site, rather altering a content type will have subtle reflections on the process of item editing.

Having tasks instead of goals is again a little bit troublesome. I am still wondering sometimes 'what should I do next ?!' or 'where do I find this function ?!' even if I have come to know a lot about CMS and its internals.

I find the clipboard and rather unfortunate metaphor - it is debatable if it's widespread desktop usage is based on its intrinsic value or is just a habit (I feel draganddrop much clear). In a web environement we don't have drag and drop, but we may do a lot of things with 'select object select action' paradigm if information flow is well organized.

And yes, frames are bad.

Documentation

Unfortunately, the documentation of the CMS is plain bad. It is very hard to figure out how things really work and often one have to read tons of code to understand how simple functions may be accomplished. If you don't believe me, try to figure out how to add custom mime types handlers...

I also find that the examples (cms-news-demo) are a little bit too simplistic and definitely insufficient.

The data model (acs_content_repository) documentation is much better. I would probably like to see a more clear separation between metadata and operational levels.

Implementation

Well, we are in front of a typical case of schizophrenia. Even if cms (and acs-templating) are built as parts of acs, the team designed them as independently as possible, building their own interfaces which often duplicate main acs functionalities. For instance, I feel very strange mixing two db interfaces, the db_??? of core acs and template::query (pervasive in cms) of acs_templating. I could handle that, but my experience tells it can lead to subtle db bugs, like beginning a transaction with a db_transaction, call some cms proc and find out that the latter one uses a totally different db handle.

Another complain is improper design of functions - I have seen some procs which are required to perform three different things and find out which one to do by a mix of command arguments (again that mime type handlers).

Also some functions sometimes get lenghty. To write a small variation may lead the programmer in a big mess of code duplication. I could suggest some study of proper oo style with extremely thin methods.

Another bad design practice is to mix at some points the ui procs and the data processing procs. I feel very stupid when I have to populate a dummy form (ui element) in order to call 'item add_revision' (data processing proc) which takes its parameters from a form, not from normal arguments.

ACS Integration

The good news are at the data-model level. Everything is subtype of acs_object, acs_type & friends.

As I already said, at implementation level the integration is bad.

Another bad thing is the CMS is a singleton, making hard to delegate a part of the site to an independent publisher. If we remember where all started - web collaboration - we may feel that the 'co' part is somehow getting lost in the shadows.

Conclusion

  • Features are good
  • The datamodel is good
  • The ui is very bad.
  • The documentation is bad.
  • The acs integration is medium.

Collapse
Posted by Don Baccus on
That's a very good analysis, I don't think you'll find much disagreement here.  Thanks a lot.

On the integration side, the kind thing to say is that the CMS was developed separately from the ACS and lived as a standalone piece of software.  This explains the different db api, etc.

The unkind thing to say is "isn't that about the stupidest thing you've ever heard?".  After all, it was developed by aD and the aD philosophy has been to integrate everything with the ACS.  Such integration should've been planned from the beginning, and there should've been agreeement on a standard db api.  Also, the use of namespaces within the CMS and the pseudo-OO programming style is very different than that followed within the ACS.  The only real justification for this would seem to be that it was an interesting academic exercise.

Do I believe in the kind statement, or the unkind one?  I'll never say .  But I do expect us to rewrite the CMS to use the common db api at some point.  It is really unforgivable to have two separate db api's in the ACS.

Collapse
Posted by Michael Feldstein on
Is anybody working on an as-is port right now?
Collapse
Posted by Dan Wickstrom on
I've already started looking at, and it's possible that Roberto might help out.  I haven't heard back from him yet...
Collapse
Posted by Michael Feldstein on
Excellent. Thanks, Dan. I expect we'll have a better handle on the
issues that Don and Cristi raise once somebody has actually
done the port.
Collapse
Posted by Karl Goldstein on
Cristi's overall assessment of CMS for ACS 4.x will receive no major objections from me.  UI and ACS integration were both sore points for that release.

I would actually discourage OpenACS developers from doing an as-is port of the UI.  The 5.0 version of CMS will have a completely redesigned UI, reflecting the lessons we've learned in the past 6 months.  Even though we're building it in Java I hope that there will at least be some opportunity for collaboration with OpenACS on UI.

After working through some delays, within a week or so we should have design docs and wireframes of the new UI ready for review.  I'll post then.

Collapse
Posted by Dan Wickstrom on
I think that we'll do the as-is port anyway.  There's probably quite a few people like Michael, who would like a frame of reference for discussions on CMS, and porting CMS to postgresql will make it more accessible to a wider audience.

The extra feedback could prove to be quite valuable.

Collapse
Posted by Michael Feldstein on
It seems to me that the OpenACS team needs to get to know the
tcl layer and the data model even if the UI is going to change. A
straight port should be a good way to do that. Also, as Dan
points out, we may be able to get some more insights by making
the system more accessible. That doesn't mean that we're not
up for a collaboration with the aD team on UI; it just means we
need to do some homework first.
Collapse
Posted by Don Baccus on
Cristi's overall assessment of CMS for ACS 4.x will receive no major objections from me. UI and ACS integration were both sore points for that release
And as the manager of the project, you share a certain level of responsibility for that fact.

So you'll pardon us if we read your comments with interest but not necessarily with agreement?

I'd love to hear a justification for your:

  • Using a totally different db api than the rest of the ACS. Even though you were building a standalone CMS in the beginning there is absolutely *no* excuse for ignoring the ACS db api design development that was going on at the same time, and *no* excuse for spinning your own solution.

    This was compounded by developing the CMS in a pseudo-OO style which is foreign to the rest of the ACS, and stupid UI differences like, for instance, requiring ACS users to set up a screen name to log into the (original non-integrated) version of the CMS.

    With all due lack of respect, Karl, in many ways the CMS truly and undeniably sucks.

  • The UI problems didn't only exist in the integrated version of the CMS, but rather in the released standalone version that's been out for, what, a year? Exactly what's the excuse for this?
  • My advice - don't pontificate until after you deliver good software. You're not alone at aD in writing condescending, "follow us to the promised land because we're so *bleeping* on top of it", posts to the OpenACS forums.

    Belay the condescending tone and write code that doesn't suck.

    *maybe* we'll listen to you then. You'll still have to drop the condescending tone, I'm afraid. I personally don't do well with condescending words unless I'm writing them.

Collapse
Posted by Karl Goldstein on
Don,

I have never intended to pontificate, and am certainly not trying to force you to agree with my point of view about anything.  I apologize if anything I've written comes across that way.

The reasons I have posted here have been to own up to the shortcomings of the current version of CMS, and to seek some feedback on our plans for the next version, with the hope that you'll find it more usable.  That's all.

Karl

Collapse
Posted by Don Baccus on
OK.  I'm sure there are folks here who will be more than glad to review the new UI design, and to share their opinions and ideas.
Collapse
Posted by Michael Slater on
I've built a couple production sites based on the AD content repository.  It has been my experience that the 'CMS UI' is really a developer's and sys/dba administrator's interface, rather than something a client's daily production managers will use.

There is lots of extraneous detail that a production manager doesn't need.  But a developer, when debugging his repository design, finds very convenient to have everything be in one place.  An admin, when needing a quick, 'root' sort of access to the content repository, to correct something, or grant/revoke user privleges to the CR, also finds this interface useful.

Our solution for the production-level manager's needs (a limited, simplified set of steps regarding a specific few content types) has been to build a very lightweight framework (a 'wizard') that allows the person to move through each step.  The ATS form-manager makes this something of a breeze, and it is still eminently customizable.

As for categorization, we've tried a couple options.  One is to use the simple, flat 'keywords' functionality.  The other thing you can do is define a "Category" content type.  This works well -- you can use cr_item_rels to connect the categories, and the content items they taxonomize.  As well, since they are content items, you can add extra attributes to them, so that you have a richly detailed category description.

It is hyperbole that the 4.x TCL content repository is so flawed.  It has proven successful on both a multimedia content site (WGBH) and a very large ecommerce catalog site (Worldbank), and certainly other projects which I haven't been involved with.  Of course the next version will be improved, but it's always better to get something written and functioning than waiting for perfect nirvana-code.

Regards

Collapse
Posted by Talli Somekh on
"Our solution for the production-level manager's needs (a limited, simplified set of steps regarding a specific few content types) has been to build a very lightweight framework (a 'wizard') that allows the person to move through each step. The ATS form-manager makes this something of a breeze, and it is still eminently customizable. "

This sounds great Michael. In keeping with the open source software tradition, can you please show us the code, or post it somewhere?

talli

Collapse
Posted by Don Baccus on
It is hyperbole that the 4.x TCL content repository is so flawed
You are absolutely right. However, given that no one here has claimed that the content repository is "so flawed", this is a red herring.

Are you by any chance confusing the content repository with the content management system, which is one of several *clients* of the content repository, not the content repository itself?

Or did you not notice that this forum's the OpenACS CMS (Content Management System) forum?

Whatever...

Collapse
Posted by harold arce on
Hi Don Baccus

My name is Harold Arce. im from Nicaragua.

I need a help with the use of CMS (content management system).

I want to active the email alerts.
how can do?

please send me your answer to the following email too.

mailto:portal@cadin.org.ni

thanks