Let's respond the the points in Jerffrey's post:
"Make it easy to install" - Ok, we probably lose more than any other CMS package on this one. If we can get RPM/DEB/etc packages this could work. We do have a web based installer, although somehow the config.tcl needs to be edited to reflect the few settings required, but a pakcaged installer could use a default for ip address and database name and get something running quickly.
"Make it easy to get started" Here Openacs and all the existing CMS like packages fall down. There all special tasks that need to be done, I guess a preconfigured CMS install.xml would be the thing here.
"Write task-based documentation first" Good idea. Figure out what someone using a CMS might want to do, and then write the code to let them do it.
"Separate the administration of the CMS from the editing and managing of content" This is also a good idea, and I think most of the content focused packages that exist do provide the content management interface and allow content editors to not also be site wide admins.
"Users of a public web site should never -- never -- be presented with a way to log into the CMS" This assumes that the contnet management system has no comment or other interactive features. Sorry, if you have a totally non-interactive web site, don't use OpenACS.
"Stop it with the jargon already" Ok, this is a good criticism. A good UI would make sense to the kind of user who is a content editor, not a web nerd.
"Why do you insist Web sites have "columns"" Well. None of the existing content apps for OpenACS has any sort or restriction on how to setup templates for content. We win on this count because all the templates needs to be coded, most of the built-in ones just have one "slot" for the main page content, the user can add anything they want anywhere they want.
So, it looks like OpenACS is a very flexible framework to address these user interface issues in a content management system, and they will be good ideas to keep in mind for anyone working on such an application.
