Forum OpenACS CMS: Response to Status of comtemplation on CMS module

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.