On of the first things you will notice when you start to use Teamworks Authoring environment is that every window pane is too small.  You can maximize the too-small pane but then it takes over your entire window at the expense of the other panes.  So everytime you want to look at something, the process basically goes like this:

• Restore current pane to normal size
• Go to new pane of interest
• Maximize new pane

 

This means you can only look at 1 window at time.  And since there are no hot keys (that I can figure out), it is very slow to switch between these views. 

Probably the worse offender is the Data Mapping tab in the Property Pane.  The image below shows how you map data into and out of an embeded component.

 

 

To reference local variable in a service you specify the variable name with a "tw.local." prefix.  So to reference equity-in-property, you must type in tw.local.equityInProperty.  Due to the design of the Data Mapping pane, all you see is the "tw.".

So essentially, in the normal view,  you have no idea what is mapped to the component.  This makes the Data Mapping view nearly worthless in its normal size.  The only way to get anything done is to maximize the pane and sometimes you still need to click into the field and press END to see what’s in the edit box.

A better solution would be for the Data Mapping pane to have 1 column and we can scroll down to see the output mappings.  At least that way, we wouldn’t have to maximize the window just to see what’s mapped to what.

Trying to work with the Data Mappings tab/pane is like trying to tie your shoe with only one hand.  It can be done but its a lot harder than it needs to be.

 

 

 

 

I’ve been monumentally dissappointed with Teamworks Authoring environment for a long long time but this one really takes the cake.

You can embed items inside BPDs and services.  When you embed something there is a tab that allows you to map data from the higher level item to the lower level item.   

For Services, there is a check box for every parameter that allows you to "Use Default".  This is good and natural behavior.

But for BPDs, there is no visual indication that there are any defaults or not.  To use the default value, you must first know it exists, then leave the data mapping blank.

Why is this so incredibly WRONG? 

1) Because we have 2 different Data-Mapping interfaces that behave differently.

2) You can’t tell if a mapping will generate an error or not without openning the embedded item.

3) If an item is set up to use defaults and the default is later moved, there is no indication from the outside that it will crash.

 

Lombardi Tech support finally explained this to me.  I pity anyone trying to develop a process that doesn’t understand how this works.