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.

Maybe it is good to share with you want I think are the best features in the design of teamsite, and sure I'll also include the design area where teamsite should improve in a next blog.

But in this months issue the good teamsite stuff:

1. This must really be the branching and versioning system of Teamsite. What they did, or what it looks like they did, is taken the idea (and maybe even the code) of cvs and build a web-gui around it. This versioning can't be beaten. It gives you a detailed history of every file and roll-back options at both the file and full website level. Using the branching structure multiple websites (or releases) can be managed on the same server without any dependencies.

2. Runner-up must be the workflow system. It's strong, robust and very flexible. And it offers a wide range of different tasks: for user or group actions, to execute a command or cgi, to submit or update files/folders. However, what I deeply miss is easy support for email-notifications and unlocking (not by an external task as is the current use)

3. Another award must go to the complete openness of teamsite in every sense: input, processing and output. Any content can be uploaded via a file-mount, processing is open via command-line tools, java-api, soap and output can flow to every OS and web-technology (html, xml, jsp, php, asp.net, ruby, database, what ever you want)

4. And finally we should not forget the customisation options on offer. One can define custom cgi, workflows, scripts, templates, deployments.

One of the most useful features for a Teamsite administrator could very well be the flexible Teamsite groups.

These teamsite groups, which are equivalent to groups at the os-level, have two major advantages over these os-groups:

• they are controlled by the teamsite administrator
• they have to option to add a group to a group, empowering a hierarchical set up

The first is important because the os-groups are normally managed by a far away department that is usually slow to react. Adding or removing a user from a group could easily take days, leaving the end-user without proper access to Teamsite.

The second is maybe even more important because this, once set up right, enables the teamsite admin to easily add new users the proper rights by adding the user to 1 group only. Example: a basic group division would be 1 group of global adminstrators, 1 group of developers per 'teamsite-project' and a group of content-editors per 'teamsite-project'. Normally the developers have the same rights as the editors and some more and the admin's have all rights of the developers but IN EVERY PROJECT. This can be done by creating these groups:

• a group for the editors which contains all editors and the developers-group (per project or branch)
• a group for the developers which contains all developers and the admin-group (per project or branch)
• a group for the admins

Does using these ts-groups also have disadvantages? Sure:

• The iwchgrp clt does not work recursive where as chmod -R does
• In the os-level privileges all you see is the iwglobal group