I've written before about major teamsite design goodies & badies. Today let's have a look at some major day-to-day annoyances of teamsite. A simple "Interwoven Teamsite Wish list". Because these items are not so much tied to the design these should be easier to fix for Interwoven. ;-)

1. I think some major entry-field types are missing in Teamsite Templating (oeps sorry, "Formspublisher" we should say). Most important is a proper date-time field type with date-picker. I know there is a workaround in which you download a calendar-cgi which you call in a callout. But that sucks because it's features are very limited (date formats, time, ...) and once downloaded it's YOU who must maintain the code. And that is not why you bought an expensive cms, did you?
Another field type missing is a read-only field. Again the workarounds here are not good enough. Using the read-only field type leaves you with a field that is too large, using form-api is too complex and sensitive for such a simple wish. And also, you want to be able to create read-only dropdowns & checkboxes.

Last field type worth mentioning is the hidden-type that would take a default value.
2. The 'custom menu items' should be made sensitive to branch or workarea the user is in.
3. The current file-browser that you can use in Teamsite Templating should be extended. First of all it should be enabled for cross branch browsing, fully configurable of course. Second, one should be able to call the import-function from within this browser. So, in case a user is browsing an image file and find it missing, (s)he call upload it with 1 click.
4. Some sort of link manager should be included within the Teamsite gui. It should be able to list all broken link on a page and/or website. But also it should warn you when you (re)move file that is referenced. (In an ideal world it would then update the references but maybe that is too much to ask for)
5. Teamsite services should use log rotation. This would prevent this ever growing log files under <iw-home>/local/logs/iwui. Unfortunately, one can not rotate the logs via a script when Teamsite is running.
6. Email tasks in the workflow engine is cumbersome. You can use the email-script that are supplied by Interwoven as part of the installation, but they are poorly written, error-prone and once you use them it is, again, you who must maintain them. The better solution would be, for Interwoven, to add a attribute to a user/group-task 'email-task-owners-on-activation' that would trigger the workflow engine to send a email to the task-owner(s) when the task becomes active. This email should be send by a process that is completely maintained be Interwoven (and thus when it fails you can call iwov-support). Clearly some extra custom-configuration is required for this, like smtp-details and a user-to-email-mapping.
Let's hope some Interwoven employee reads this and add these useful enhancements to their product. It would really help us all. :-)

I found out that my cms-blog was not very high up in the google-rankings. Even if you would search for the exact blog-item title you could still only find me on the 4th page or so. We can do better then this.

So to improve my ranking I wanted to change two things to the default install of the Typo3 WEC Discussion Forum. I wanted the blog title to show in the page title, I want to have the item title in the url and, while we are at it, I want the home-link to link to '/' instead of something like '/Home.2.0.html'.

Here we go:

1. Add the blogitem title to the page title

Add this code to the page template of your page that contains the wec plugin. NOTE: do not add this to the root-page of your website!:

config.noPageTitle = 2

page.headerData.20 = TEXT

page.headerData.20.value = Your site title

page.headerData.20.wrap = <title>|

page.headerData.30 = TEXT

page.headerData.30.value = Your Blog title

page.headerData.30.noTrimWrap=| - ||

page.headerData.40 = TEXT

page.headerData.40.value = Overview

page.headerData.40.noTrimWrap=| - ||

page.headerData.50 = TEXT

page.headerData.50.value = </title>



[globalVar = HTTP_GET_VARS|tx_wecdiscussion|single>0]

page.headerData.40 = CONTENT

page.headerData.40{

  table=tx_wecdiscussion_post

  # wrap the whole element

  wrap=|

  # the SQL-Query

  select{

    max=1

    selectFields=subject

    pidInList = 21

    andWhere.data = global:HTTP_GET_VARS|tx_wecdiscussion|single

    andWhere.wrap = uid='|'

  }

  renderObj=COA

  renderObj{

    5=TEXT

    5{

      noTrimWrap=| - ||

      field=subject

    }

  }

}

What this does, in short, is, if the url contains the 'single' get-variable, if queries the wec-table for the item title and add this to the page-title. Simple enough, isn't?

The inspiration for this trick came from Infohit

2. Give our blog a pretty url (in the single item view)

First install and enable the realurl extension, if you haven't done so already. The manual describes this well enough.

Then you need to add this code to your existing realurl configuration (in localconfig.conf):

        'postVarSets' => array(

            '_DEFAULT' => array (

                'view' => array(

                    array(

                        'GETvar' => 'tx_wecdiscussion[single]',

                        'lookUpTable' => array(

                            'table' => 'tx_wecdiscussion_post',

                            'id_field' => 'uid',

                            'alias_field' => 'subject',

                            'addWhereClause' => ' AND NOT deleted',

                            'useUniqueCache' => 1,

                            'useUniqueCache_conf' => array(

                                'strtolower' => 1,

                                'spaceCharacter' => '-',

                            ),

                        ),

                    ),

                ),

                'archive' => array(

                    array(

                        'GETvar' => 'tx_wecdiscussion[show_date]',

                    ),

                    array(

                        'GETvar' => 'tx_wecdiscussion[archive]',

                        'valueMap' => array(null => '1'),

                    ),

                ),

            ),

        ),

This code above will give you a url like '/cms-blog/view/top-6-of-badly-designed-teamsite-features/', just what the doctor ordered.

3. Make your home links link to '/'

This is not so easy with realurl, unfortunately. You'll need some php code. :-(

First you need to add this class to an existing (or create new) php-library file, normally located under /fileadmin:

class user_tweakMenu {

    function replace( $I, $conf ) {

        $I[ 'parts' ][ 'ATag_begin' ] = preg_replace(

            '{' . $conf['searchFor'] . '}',

            $conf['replaceWith'] ? $conf['replaceWith'] : "",

            $I[ 'parts' ][ 'ATag_begin' ] );

        return $I;

    }

}

Then, in your template (at the site root level) you'll need to add this code (customise it to your situation and needs):

includeLibs.include1 = fileadmin/my_include.inc

temp.menu.1{

      IProcFunc = user_tweakMenu->replace

      IProcFunc.searchFor = /home/"

      IProcFunc.replaceWith = /"

}

This trick is well described by Hannes Schmidt

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.