Printmonkey

Kiss with Dialogue

mike@printmonkey.net — Wed, 16 Jun 2010 12:28:22 GMT

A basic principle I always try to stick to with Dialogue is to keep things as simple as possible (Keep It Simple Stupid). If something looks too complicated to easily explain then it probably is. Take the following example (using word Mergefields to define the content) from an insurance document I have worked on recently:-

The spec says:-

{ IF { MERGEFIELD Policyholder_Type } = "SINGLE" "I" ""}{ IF { MERGEFIELD Policyholder_Type } = "JOINT" "We" ""}{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "I/We" ""} agree to you asking any doctor { IF { MERGEFIELD Policyholder_Type } = "SINGLE" "I" ""}{ IF { MERGEFIELD Policyholder_Type } = "JOINT" "we" ""}{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "I/we" ""} have consulted about { IF { MERGEFIELD Policyholder_Type } = "SINGLE" "my" ""}{ IF { MERGEFIELD Policyholder_Type } = "JOINT" "our" ""}{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "my/our" ""} physical or mental health to provide information so you may assess { IF { MERGEFIELD Policyholder_Type } = "SINGLE" "my" ""}{ IF { MERGEFIELD Policyholder_Type } = "JOINT" "our" ""}{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "my/our" ""} proposal. You may gather relevant information from other insurers about any other applications for life, critical illness, sickness, disability, accident or private medical insurance that { IF { MERGEFIELD Policyholder_Type } = "SINGLE" "I" ""}{ IF { MERGEFIELD Policyholder_Type } = "JOINT" "we" ""}{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "I/we """} have applied for. { IF { MERGEFIELD Policyholder_Type } = "SINGLE" "I" ""}{ IF { MERGEFIELD Policyholder_Type } = "JOINT" "We" ""}{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "I/We" ""} authorise those asked to provide medical information when they see a copy of this consent form. This allows you to gather medical reports within six months of the start of the plan, or after { IF { MERGEFIELD Policyholder_Type } = "SINGLE" "my" ""}{ IF { MERGEFIELD Policyholder_Type } = "JOINT" "our" ""}{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "my/our" ""} death, to support any claim made on the policy proceeds.
This information can also be used to maintain management information for business analysis.
By signing this declaration { IF { MERGEFIELD Policyholder_Type } = "SINGLE" "I am" ""}{ IF {MERGEFIELD Policyholder_Type } = "JOINT" "we are" ""}{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "I am/We are" ""} allowing you to process { IF { MERGEFIELD Policyholder_Type } = "SINGLE" "my" ""}{ IF { MERGEFIELD Policyholder_Type } = "JOINT" "our" ""}{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "my/our" ""} application using the information that { IF { MERGEFIELD Policyholder_Type } = "SINGLE" "I" ""}{ IF { MERGEFIELD Policyholder_Type } = "JOINT" "we" ""}{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "I/we" ""} have given. You may also use this information to process any claim made on this policy.

There are about 30 conditions in that block, each of which needs to be coded and maintained, however if you look closely you'll see they are all one of the following:-

IF { MERGEFIELD Policyholder_Type } = "SINGLE"
IF {MERGEFIELD Policyholder_Type } = "JOINT"
IF { MERGEFIELD Policyholder_Type } = "OTHER"

Rather than coding all of the variations separately, it is much simpler to separate the three different versions of the paragraphs as shown:-

{ IF { MERGEFIELD Policyholder_Type } = "SINGLE" "I agree to you asking any doctor I have consulted about my physical or mental health to provide information so you may assess my proposal. You may gather relevant information from other insurers about any other applications for life, critical illness, sickness, disability, accident or private medical insurance that I have applied for. I authorise those asked to provide medical information when they see a copy of this consent form. This allows you to gather medical reports within six months of the start of the plan, or after my death, to support any claim made on the policy proceeds.
This information can also be used to maintain management information for business analysis.
By signing this declaration I am allowing you to process my application using the information that I have given. You may also use this information to process any claim made on this policy." ""}

{ IF { MERGEFIELD Policyholder_Type } = "JOINT" "We agree to you asking any doctor we have consulted about our physical or mental health to provide information so you may assess our proposal. You may gather relevant information from other insurers about any other applications for life, critical illness, sickness, disability, accident or private medical insurance that we have applied for. We authorise those asked to provide medical information when they see a copy of this consent form. This allows you to gather medical reports within six months of the start of the plan, or after our death, to support any claim made on the policy proceeds.
This information can also be used to maintain management information for business analysis.
By signing this declaration we are allowing you to process our application using the information that we have given. You may also use this information to process any claim made on this policy." ""}

{ IF { MERGEFIELD Policyholder_Type } = "OTHER" "I/We" ""} agree to you asking any doctor I/we have consulted about my/our physical or mental health to provide information so you may assess my/our proposal. You may gather relevant information from other insurers about any other applications for life, critical illness, sickness, disability, accident or private medical insurance that I/we have applied for. I/We authorise those asked to provide medical information when they see a copy of this consent form. This allows you to gather medical reports within six months of the start of the plan, or after my/our death, to support any claim made on the policy proceeds.
This information can also be used to maintain management information for business analysis.
By signing this declaration I am/We are allowing you to process my/our application using the information that I/we have given. You may also use this information to process any claim made on this policy." ""}

In Dialogue terms, these could then be coded as three individual table rows with a single rule on each row making it much easier to understand, maintain and test. Admittedly there's a slight maintenance overhead in that any change to the paragraph text would have to be made three times instead of once, but the benefits of simplifying the rules (from thirty down to three) far outweigh this.

Of course an even neater way to handle this is to replace the variable elements of the text with user variables which can be set at customer timing depending on the value of Policyholder_Type. That way you eliminate the need to have multiple versions of the same paragraph but also reduce the complexity of the code.

Making Testing Easy On Yourself (Testing Part 5)

mike@printmonkey.net — Tue, 30 Mar 2010 10:11:36 GMT

Of all the aspects of testing, preparing test data is probably the most time consuming and tedious. It is however, one the most important parts. If your test data isn't correctly prepared and doesn't tie in with your test plan then you are immediately at a disadvantage. Valuable time can be wasted examining code for bugs, when in fact it is the data that is at fault. So how can you make life easier for yourself?

More...

Structural Testing (Testing Part 4)

mike@printmonkey.net — Thu, 04 Mar 2010 12:53:31 GMT

Apologies for the delay in publishing the next part of the testing series, it's been a busy few months It's finally here though and the next parts should be coming soon...

Whereas Functional Testing test plans are generated from the Requirements documents, Structural Testing Test Plans are generated from the application itself.

Whilst there will always be a significant amount of overlap between the two test plans(Functional and Structural), both should still be created as there are differences in the types of errors captured by each.

More...

Writing A Functional Test Plan (Testing Part 3)

mike@printmonkey.net — Tue, 20 Oct 2009 15:00:24 GMT

We've already discussed how a lack of an effective test plan is one of the the major reasons why your implementations fail and discussed effective testing techniques so now it's time to get into the nitty gritty and discuss testing techniques in detail. We'll start off with Functional Testing which, whether you know it or not, is probably the testing technique you're most familiar with.

More...

How To Keep Control Of Your Variables in Dialogue

mike@printmonkey.net — Wed, 14 Oct 2009 09:17:13 GMT

If you routinely set all of your variables to a reset time of “automatically” and your formula variables are all set to calculate “as needed” in Dialogue you could be creating a maintenance nightmare for you and your Colleagues. Take your Dialogue knowledge to the next level and take control of formula calculation timing and variable reset timing.

More...

Effective Testing Techniques (Testing Part 2)

mike@printmonkey.net — Tue, 13 Oct 2009 09:29:46 GMT

Last time we talked about the impact leaving testing to chance can have on your implementations (and it’s not good), this week we’re going to look at the different types of testing that you can use to give your testing the best chance of catching the defects it’s supposed to.

More...

Why Your Implementations Fail (Testing Part 1)

mike@printmonkey.net — Wed, 05 Aug 2009 07:57:00 GMT

How many of your implementations are painless exercises in moving files? In my experience not many and a major factor is the lack of an effective testing strategy. Testing has been well documented in other forms of application development but for some reason the document industry is still catching up so how do you make sure your testing gives a good return on time and effort?

More...

Application Migration

mike@printmonkey.net — Tue, 30 Jun 2009 10:06:37 GMT

Changing your toolset can be a headache at the best of times, but when you’ve got multiple tools and potentially multiple platforms, handling large amounts of critical customer communications getting the migration right can become a juggling act of monumental proportions.

More...

Don't just design for your clients

mike@printmonkey.net — Thu, 18 Jun 2009 11:43:00 GMT

Given that we're generally up against tight deadlines, often we're completely focussed on what the client wants rather than what we need. However a little thought upfront can often save a lot of time later in the development and maintenance cycle...

More...

First steps

mike@printmonkey.net — Sat, 07 Mar 2009 14:18:00 GMT

Well this is going to be a short post. Just want to make sure everything is working properly and that I can post away. Most of what you'll read here will be technical tips, shortcuts, and anything else I think will be useful. I hope you enjoy reading and feel free to comment to let me know what you think.

More...