I am wondering what features are being considered and what features people need or would like to see.
I am wondering what features are being considered and what features people need or would like to see.
Is somebody going to take the lead on this? Jon?
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...
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?
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:
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.
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.
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.
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.
More details are forthcoming.
<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>
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.
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?
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:
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?
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.
Michael, I just wanted to clarify this aspect of what I'm doing, as that seem to cause people the most trouble understanding.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.)
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
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.
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?