We got the demo yesterday of Sungard/SCT‘s Luminis Content Management Suite (sales video). I mentioned previously that the sales rep thinks Pima Community College and Edison College show it off well.
Here’s what we learned in the demo:
It started with the explanation that data is stored as XML, processed by JSP, and rendered to the browser as XHTML according to templates, layouts, and “web views.” It was later explained that the product was “web server agnostic” and could run under Apache, IIS, SunOne, or others. This works because the only relationship between the web server and LCMS is on the file system. LCMS works up the pages, then spits them out onto the filesystem to be picked up by the webserver. LCMS does not dynamically generate the pages, and it has no features to support dynamic content.
LCMS supports three modes for admins and content authors to view and edit content: in-context, “site studio,” and some other mode that wasn’t demonstrated. WYSIWYG editing was via the Real Objects editor. They were proud of the editor’s ability to accept content, including a table, pasted in from MS Word, but a look at the code revealed some of the same ugliness that we’ve seen from an export directly from Word.
The software is workflow heavy and our demonstrator had to “manually promote” content with every example. He assured us this would not be necessary under production circumstances, but the product had the appearance of having been designed to slow or prevent changes to web content rather than streamline the process.
From now on I’ll be asking the following question at all demos:
The library is hosting an exhibition next week. Please walk us through the process of creating a new page to describe and promote the event and then integrate that page in the library’s site taxonomy.
I mention this because the demo didn’t show us anything like that. We saw only the editing of pages and it looked frustratingly cumbersome, with one example requiring several return visits to the site studio to promote an edited page from in-progress to approved to live (three is the minimum number of steps, but we were told we can have 15 or 20 or more if we wanted). If the content author didn’t have promotion authority, then the process could require the involvement and coordination of two or more people. It’s easy to imagine days passing before page corrections went live and weeks passing before new content could be put online.
That said, the site admins have it a little easier (if only because one assumes they have supreme permissions for everything). The templating didn’t look bad, but because the product doesn’t generate any dynamic pages, it couldn’t take advantage of some automation opportunities (the demonstrator was excited to tell us the footer text — “copyright 2005” — could be globally changed by editing a singe file, but we were curious why the copyright date wasn’t dynamically generated).
Permissions can be assigned per object by user or group. These details are stored in the Luminis LDAP, but they’re not shared with or based on any group or permission we’re already managing. That is, we’ll have to pay attention to provisioning (and de-provisioning) specific to the CMS. It’s amusing that vendors claim LDAP integration but remain ignorant of identity management issues.
There are seven levels of permission for each user or group on each object:
- none
- browse
- read
- relate
- version
- write
- delete
And then there are these extended permissions:
- exec
- change location
- change state
- change perms
- change owner
It’s worth noting that the product maintains versioned copies of each content object, making it very easy to revert to any previous saved edit or simply review prior content.
Somewhere along the line we were told “at its core you get a document management system.” And then we saw a demo of the product working as a document repository. The demos showed a content author “checking out” a Word file via the browser, downloading it for editing, then checking the edited version back in, entering metadata and version info, and viewing the changed document in the repository.
APIs?
- Web Development Kit
— Java apps that create the content authoring/management interface - Documentum Foundation Classes
— C++ API that runs the show
There are no SOAP or other webservices-based APIs, and it didn’t seem like there was much movement toward them.
Implementation?
A claimed three to six month implementation process including four or more weeks of service from SCT.