OK, now for some items that c(sh)ould be improved. I've created this Top 6 for you:

1. The biggest design miss is the templating design. I really can't see why Interwoven has not hidden the concept of a dcr for the end-user of Teamsite. Have you ever met a cms-user that cared where his content was stored? Or understood why (s)he had to regenerate a file? Me neither. All they (should) care about is, data entry, approve in preview and submit. The implications of this design flaw are large: end-user are required to name both a dcr and a generated file, end-user need to be trained to always submit a dcr & the generated file together (and still forget to do so), developers need to write the same custom code that generates a file from a dcr over and over and over again, one has to be very careful when merging dcr's and/or generated files, etc. And all this could easily have been prevented if Interwoven would have hidden (or made transparent) the concept of a dcr.

2. a second design flaw is that there is no proper way to define "business rules" for the templating data (except formapi but we all know that javascript is not robust enough to enforce business rules). The only place where you are able to check that f.i. begin-date <= end-date is in the presentation-template, at which point you are far too late to signal this to the user.

3. another design miss is the generic lack for error handling. Consider for instance the (absence of) error handling in the 'command line tools' (clt's). At best these tools will write a user-readable error message back to STDOUT. The problem with this is that these clt's are most often used by a machine, a perl script for instance. And how is a perl script to know whether the return-string on STDOUT is an error? Why doesn't Interwoven use a unified error-messaging in there clt's: either begin all errors with 'ERROR-<id>:' which makes it possible to parse the message in perl? Btw, this behaviour is not restricted to clt's, in fact it is the common norm with Teamsite interfaces.

4. another award should go to the documentation that is often lacking enough detail. Two simple examples:
- where does it explain when a user has access to a branch/workarea/directory?
- for an wft-external task: "owner — specifies the owner of the task", so what does that mean?
The devil is often in the details, well Interwoven documentation is not fit for the details.

5. Before we finish I want to mention that a lot of the Teamsite code leaves "quick&dirty" impression and that the logging is scattered all over the place.

6. But I want ot finish with the fact that Interwoven is completely ignoring the devnet (devnet.interwoven.com) as a input-source for valuable feedback from the people who use Teamsite as a development platform on a day 2 day basis. It could be so simple. Spend an hour or two per week to read the forums and you know in what direction your tool should go.