Forum OpenACS CMS: Status of comtemplation on CMS module

Collapse
Posted by Dave Bauer on
Is there any work being done on building a new CMS? It seems like the consensus is to just throw out most of the old one and build a new better one, especially the UI.

I am wondering what features are being considered and what features people need or would like to see.

Collapse
Posted by Michael Feldstein on
Good question. I'm very much interested in CMS and have posted several threads here already on what features I'd like to see. I've spent some time playing around with the existing CMS and it definitely could be better.

Is somebody going to take the lead on this? Jon?

Collapse
Posted by Jon Griffin on
There is a forum setup to talk about this, but I have been analyzing stuff and am looking for more input.

That said, I think the plan (not mine) was to port things the way they are and then fix them. I personally think that is a waste of time, but...

Collapse
Posted by Michael Feldstein on
What are the arguments pro and con for porting, then fixing? Don, (if you're monitoring this board), what's the general MO here, and why?
Collapse
Posted by Don Baccus on
Well, first of all I don't have much first-hand experience with the CMS, and I don't believe Ben does either.  Given that porting a module  typically takes little time (my original bboard port took me one day, for instance, CMS would probably be more like a week) we just take the default position "port first, fix later".

Now ... if people who have worked with it feel like it needs to be junked entirely, including the datamodel, and that the CMS as it exists isn't even a viable interim module ... then some rethinking is in order.

What we need is some *specific* analysis of what's wrong with it.  Not simply from the UI POV but for instance, what's wrong with the datamodel.  Did they get anything right, or does the whole thing need to be shitcanned?  Do we need to shitcan their ideas entirely, or just their code?

Without more detail than "it sucks" it's hard to say that spending a week or so porting a clone would be a worthless activity.

Jon's offered to take the lead on getting more information on other CMS systems, and to turn a critical eye on the ACS CMS.  He's also working on parts of the core (acs-notification and friends) so I suspect it might be awhile before he can find time to do much on this task.  The core work's of higher priority (for all of us involved).

But I don't know, so I'll ask him!  Hey, Jon, any idea when you'll be able to rip the CMS internals to shreds and explain just how it sucks?

Collapse
Posted by John Shields on

I'm anxiously awaiting a response to Don's question about the future of OpenACS CMS... ;)

I'm evaluating the different open source CMS systems that I've found and would like to put OpenACS CMS into the equation. I've narrowed my list to OpenCMS, MMBase, and Midgard. But I like OpenACS and would like to use it's CMS if that will be possible. I need the ability for VERY non-technical people to update pages on a regular basis along with proper workflow, permissioning, and check-offs.

I've looked at http://cms.arsdigita.com/ but I'm still not so familiar with the strengths and weaknesses of the system from a programmer's perspective. So, could one (or several) of the more enlightened members of this community provide your best answers to the following:

  • Is the current ACS CMS going to be ported or re-written?
  • What it the most likely time frame of the first release of OpenACS CMS?
  • Why should I use OpenACS CMS vs. XXX (others listed above)?

Thanks!

Collapse
Posted by Talli Somekh on
The ACS CMS sucks big time. It sucks so badly that it's clear an engineer designed it.

That being said, it does exist. Considering that some of us are really banking on OpenACS 4 to come out, I would like to make a case for porting the current CMS to 4 and then fixing it in later versions because:

a) It may be bad, but with some training and experience it may very well be workable. I haven't used it much primarily because I haven't been forced to and cms.arsdigita.com has no explanation as to how to make it work. I imagine, though, that if it were stuck on PG and I could do some work with it, I would figure it out and find it reasonably workable.

b) Nobody knows how to make it better right now because no one has actually used it. We can't compare it to OpenCMS, MMBase or whatever because we haven't played with it on an actual production site. After a few months of heavy use, I imagine the community will have some really good comments on how to improve it.

c) aD is working pretty hard on improving the current CMS. I know that it will be in Java, but it may be worthwhile to see how they learned from their mistakes and improved the system. Whether the switch to Java makes it nearly impossible to incorporate their fixes I am not qualified to answer.

d) The porting effort is already behind. We need something out, and a bad UI is better than no CMS.

So there are four points I'm offering to the argument. Basically, I'm begging for something to come out ASAP.

tal

Collapse
Posted by Michael Feldstein on
I second Tal's motion. The CMS module does suck from a user
perspective, but it does seem to work. I have no way to judge the
code itself, but I've played around a bit with the news demo and,
for the most part, the crucial functionality seems to be there. At
this point, a bad CMS is better than no CMS.
Collapse
Posted by Dave Bauer on
I looked breifly at the code, there's alot of file in there. I am willing to work on a port so that we have a functioning system. My first goal is to get OpenACS 4 functional. I have alot of ideas for CMS that are not necssarily compatible so after the original CMS is done, I am sure I will work on alternative ones.
Collapse
Posted by Bryan Quinn on
I'm hearing from several people that there are usability problems with the current CMS.  The CMS is being upgraded and feedback is appreciated.  Please post specific problems and requests and we will read them.
Collapse
Posted by Michael Feldstein on
Brian, it's been a few weeks since I looked at it, but here are a few global issues based on what I remember:

First of all, the idea behind the current interface is to stick all the functionality out in the open, even if particular users can't access some of it. It would be enormously helpful if you would just show the features that the person can used, based on his/her role.

Going a step further, try to organize the interface around tasks rather than around features. What do I need to do, for example, if I am an editor? How can you set up the interface so that I can do all my editing tasks in as few clicks as possible? Right now, (based on the News demo, anyway), users have to jump all around the system just to perform basic tasks.

And finally, kill the folders metaphor. The things that you have in the "folders" are too abstract; users don't think of them as documents or items. It's OK to use a multi-level menu, but you should style it after a multi-level web site menu, rather than a file system. You just confuse users under the current system.

I'll try to go back and give CMS a second look in the next week or two--*if* I'm confident that somebody is going to do something with the comments I submit.

Collapse
Posted by Talli Somekh on
Those are very good points, Michael. I would add that the CMS should get rid of the frames. Or limit it somehow. There are few larger mistakes in the design business than the use of frames. I don't think that the benefit of trying to present all the data concurrently outweighs the cost of simple navigation.

tal

Collapse
Posted by Lars Pind on
Michael and others,

Thanks for your comments. I'm charged with improving the user experience of ACS5, and I appreciate your feedback. I'm already working along these lines, in fact, I'm going one step further, and designing a goal-directed UI, as opposed to a task-directed or an implementation-directed UI.

We will have different user experiences for different types of users. The web master needs a different interface than does a "content producer" (I hate that term), an editor, or a graphic designer. I'll give them those.

Michael Feldstein, can you explain more clearly what you're talking about when you're saying "the folders metaphor"?

Are you talking about the fact that the whole UI is structured around a tree-view thing? You can count on me getting rid of that. But if you're talking about the CMS concept of folders, basically corresponding to the slash-separated directory things in a URL (www.foo.org/michael/weblog/), my experience is that a web master, still cares a lot about those, whereas a content producer don't.

I appreciate your feedback.

Collapse
Posted by Michael Feldstein on
Lars, there are two pieces to the whole folders thing: The functionality itself and the metaphors by which the users understand that functionality.

In terms of the functionality itself, I actually don't have a problem with a tree-based design. I agree heartily that the system needs a goal-based interface, but it should probably also have a task-based interface to compliment that. (Think pull-down menus (task-based) and wizards (goal-based) in the same app.)

But there are different ways to represent a tree to the user. The Windows Explorer-like representation in the CMS is one way. Nested pull-down menus in apps like Microsft Office are another way. Theoretically, you can map the same items equally well to either. But the two resonate with different user expectations. When people use a Windows Explorer-like interface, they expect to be looking for files. Things. They don't expect to be looking for tasks or even menus; those sorts of things are to be found in the pull-downs. IMO, folders/Explorer metaphor doesn't work in the current CMS.

I was actually suggesting a third kind of tree implementation. Many web sites have nested left-side menus for navigation. (Unfortunately, I can't think of any off the top of my head.) At any rate, people are used to seeing these types of menus to navigate a web interface. Functionally, they work exactly the same as the folders in CMS do. But they don't have the same strong mental associations that, IMHO, potentially confuse CMS users. It's a fine point, but every ounce of usability juice counts in a complex app like this one.

Collapse
Posted by Michael Feldstein on
BTW, Lars, I'm sure I speak for many here when I say we'd be thrilled to collaborate on specs for functionality, interface, and data models on improved CMS systems for both OpenACS and ACS Jave. This could, in fact, serve as a model for how aD and the OpenACS community might work together going forward.
Collapse
Posted by Karl Goldstein on
I've put up a document [1] providing an overview of the requirements and design for CMS in ACS 5.0; I'm sure it raises as many questions as it provides answers, so please ask away.

More details are forthcoming.

[1] http://cms.arsdigita.com/acs5/overview.html

Collapse
Posted by Michael Feldstein on
<p>Karl, thanks for sharing the design doc for the new CMS. This quote from it pretty much sums up my own private assessment of it:</p>

<i><p>"Over the past six months, we have gained extensive experience using the package on client projects. In all cases, the user interface had to be modified extensively to meet the usability
requirements of the client. In several cases, we resorted to implementing simple authoring "wizards" for content producers, eliminating exposure to the user interface entirely.</p>

<p>"On a more positive note, the package has proven capable of meeting most of the functional requirements of our clients. Its feature list also compares favorably to many commercial CMS
applications. Our primary challenge for the next release is to expose those features in a manner that is easier to use out-of-the-box (or with minimal customization), is more accessible to all classes
of users and is more integrated with the rest of ACS."</p></i>

<p>The CMS in 4.x looks to me like it has most or all of the functionality I need (from a user perspective), but the interface makes it very difficult to assess.</p>

<p>If you're willing to put together some interface mock-ups (static pages are fine), I for one would be delighted to provide feedback. We could use <a href="http://www.useit.com/papers/heuristic/">Jakob Neilsen's heuristic usability testing methods</a> to make sure the feedback is helpful and follows well-tested rules of usability.</p>

<p>Of course, this only deals with the non-programming side. Perhaps if you'd be willing to post the data models (when they're done), the hackers here would be interested in digging into those as well.</p>

Collapse
Posted by Karl Goldstein on
Michael,

We are indeed working on "pseudo-dynamic" mockups (enough to at least give the impression of something happening), and will be making those available for review over the next couple weeks.  Feedback will be much appreciated.

Collapse
Posted by Michael Feldstein on
Fantastic, Karl. I look forward to it.

At the risk of running OT here, I'm going to take this opportunity to get up on my hobby horse again and say that it would be a really, really good thing for the ACS to have heuristic usability testing module. I have a functional spec for such a best floating around on my hard drive somewhere. It could be tied in with workflow and the SDM. It would be highly useful both in testing the usability of ACS modules (such as the CMS) and in testing individual ACS-based client sites.

If I could program, I'd write it myself. Since I can't, is there anybody out there interested in taking up my crusade with me?

Collapse
Posted by Michael Feldstein on
Ugh. This is what I get for not proofreading. It would be a really good thing to have a heuristic usability testing module, and I have a spec for such a beast.
Collapse
Posted by Karl Goldstein on
I've mocked up a default (out-of-the-box) public user interface for how a content section in ACS 5. Please check it out if you're interested.

http://cms.arsdigita.com/acs5/applications/generic/public.html

We will be following with mockups of the rest of the application shortly.

Also, if you're interested in continuing to follow developments with regard to CMS in ACS 5, please sign up for alerts on the CMS Users bboard on arsdigita.com:

http://www.arsdigita.com/bboard/q-and-a.tcl?topic%5fid=815&topic=CMS%20Users%20Group

Thanks,

Karl

Collapse
Posted by Michael Feldstein on
Karl, the out-of-the-box mock-up looks good to me. There's not really too much to say here because (a) this isn't the area where CMS UI really ran into trouble (although, come to think of it, I don't recall seeing any sort of an interface at all for this piece in the existing CMS), and (b) this is a piece that's likely to get changed a lot by clients.

That having been said, it's a pretty clean and clear interface. It would be nice if it also could be displayed in the form of one or more portlets. Is portals integration planned as part of the out-of-the-box experience?

Collapse
Posted by Karl Goldstein on
Michael,

As you note, there was nothing like this in the Tcl CMS package, which was one of the reasons why the out-of-the-box experience was so bad.  Hence the effort to have a default public UI this time around.

As you also note, I fully expect clients to want to customize this a lot.  In an attempt to make this easier, the default public UI pages are constructed from smaller logical components wherever possible.  So, for example, you could just pull out the "featured" component and stick it into a portal, possibly in conjunction with the "search query" component.

Collapse
Posted by Lars Pind on
I said: I'm already working along these lines, in fact, I'm going one step further, and designing a goal-directed UI, as opposed to a task-directed or an implementation-directed UI.
Michael replied: I agree heartily that the system needs a goal-based interface, but it should probably also have a task-based interface to compliment that. (Think pull-down menus (task-based) and wizards (goal-based) in the same app.)
Michael, I just wanted to clarify this aspect of what I'm doing, as that seem to cause people the most trouble understanding.

When I said goal-directed, I meant it in the Alan Cooper sense of the term. Goals are the things that we really want to achieve, and tasks are the things that we have to do to achieve that. The goals will be constant, but the tasks are not. The tasks depend on the available technology and other constraints. If there were easier tasks that still fulfilled my goals, that's good. If there was a way to achieve my goal without performing any tasks at all, so much the better!

A quick example: Say your goal is to get your lawn mowed. Your task may be to go out and do it yourself, but if someone else would do it for you for free, that would be even better. Maybe you don't have a lawn mower? In that case you might have to buy one first. Maybe buy it online, or at a store. Nevertheless, all of these tasks are possible substitutes for each other, but you can only see that, if you're aware of the goal.

That's what I'm trying to do here. Trying to discover our user's goals, so we can find out how to let them do the right tasks at the right time, presented in the right way.

Cooper explains all of this better himself at http://www.chi-sa.org.za/Documents/articles/goal-directed.htm

Collapse
Posted by Michael Feldstein on
Lars, thanks for the clarification--and the link. Cooper's article is excellent. While I had some idea of what you meant by "goal" and "task" simply from the words themselves, I'm definitely much clearer now.

That having been said, unless I'm misunderstanding both him and you, I stand by my earlier comment about needing both a goal-oriented interface and a task-oriented one. Cooper assumes that a goal-oriented interface is always better. This is true if and only if you are positive that you have a solid understanding of the end user's goals. In any richly functional piece of software (and CMS definitely qualifies), there is an excellent chance that you will not always guess right about the goals of all users. In those cases, unless you allow them to fall back on a task-oriented interface, they may be stuck.

Here's one (admittedly weak off-the-cuff) example:

Suppose you (reasonably) guess that users who are going to the trouble of implementing a CMS are interested in getting a large volume of content up as quickly as possible. (After all, Vignette was invented by the folks at c|net.) So to that end, you design your CMS to move the workflow along as quickly as possible. You build in all kinds of reminders. Maybe you create a holding period, taking the content out of a user's hands and sending to an alternate (editor/writer/whatever) if it sits untouched for a certain number of hours, so no articles get accidentally stuck in limbo for two days. Maybe you totally focus the interface on making approval easy.

Well and good. But suppose the organization implementing the CMS is not an Internet news site but a securities trading firm or pharmaceutical company. What they really care about is taking highly regulated documents through a complex approval process and be able to certify who touched (and approved) which version of a document when. In that case, the last thing you want to do is make it easy for a document to get rushed through. You want to make it hard, in fact. You want to say, at every stage in the process, "Are you sure you want to do what you're about to do?" Maybe the goal-oriented interface you designed with the Internet news site in mind presents serious problems for them. Maybe they need two clicks (an "OK" and a "confirm") where you worked so hard to reduce the process to one click. Maybe they need easy roll-back features where you put in push-forward features. And if you worked really super-hard at making your interface completely goal-oriented, maybe you removed (or, at least, hid) exactly those controls that these particular users need. After all, they really are superfluous at best and counter-productive at worst for the goals that you had in mind when you designed the app.

Chances are good that no matter how carefully you define goals, you're going to miss some. In that case, the user needs to be able to fall back on an alternative interface which, although not as clean as the goal-oriented interface, gives more flexibility because it is designed purely to give access to all features of the software. (Again, think wizards vs. pull-downs.)

An ideal system would have some kind of built-in wizard-making function, i.e., a way for non-programmers to build goal-oriented interfaces for themselves. (Think recordable macros.) But having both task- and goal-oriented interfaces programmed in would be a good (and more realistic) start.

Collapse
Posted by Dave Bauer on
Here is the overview of the direction ACS 5 CMS is moving:
http://cms.arsdigita.com/acs5/overview.html

Are our requirements and goals the same or similar?

If so, can we get there with the current CMS and just replace the UI pages? Or do we need to reengineer the insides also?

Collapse
Posted by Michael Feldstein on
From my perspective, the general functionality of the existing CMS works fine for me; I'd like to see see some additions, but I think getting a good port done is the most important. Based on Karl's comments on the aD CMS board[1], it looks like their changes to the data model won't be too drastic. I have nothing to say regarding the tcl code, but it seems to me it would be a good idea to try to keep page flow + data model parity, at least for the initial port. We can add improvements later.

[1] http://www.arsdigita.com/bboard/q-and-a-fetch-msg.tcl?msg%5fid=000dK4