GRAY, UNGRAY, SHOW and HIDE

These four commands are essential in presenting user friendly and user-proof dialogs in HotDocs.  When designing systems, it is generally best practice to show only those variables that require (or may require) an answer and HIDE or GRAY those that are irrelevant.  HotDocs provides a rudimentary manner to handle this automatically, but if you are designing complex systems, you may need to use these four commands. All of these instructions are used in dialog scripts only.

GRAY Var //grays Var, prohibiting data entry, but displaying the value (if any)
UNGRAY Var //UNgrays it, allowing data entry
HIDE Var //completely hide the variable
SHOW Var //opposite of HIDE

Here are some examples that should be fairly self explanatory…

//hide the company type, only showing it if relevant.
HIDE PARTY Entity Company Type MC
IF PARTY Entity Type MC"Company"
SHOW PARTY Entity Company Type MC
REQUIRE PARTY Entity Company Type MC
END IF

//calculate a total amount, but gray it so it isn't editable
GRAY SALES Grand Total NU
SET SALES Grand Total NU TO ZEROSALES Amount NU ) + ZEROSALES Tax NU ) - ZEROSALES Discount NU )
//allow them to manually change it if they REALLY want to
IF SALES Grand Total Change TF = TRUE
UNGRAY SALES Grand Total NU
END IF

Instead of using a variable name, you can also substitute the “ALL” parameter….

GRAY ALL //grays everything on the dialog
UNGRAY ALL //ungrays everything

When building a system to really lockdown data entry, you may wish to write a dialog script something like this to force entry of everything in the correct order…

 

HIDE ALL
SHOW PARTY Entity Type MC
IF ANSWERED ( PARTY Entity Type MC//must have a type before we allow name entry
SHOW PARTY Name TE
IF PARTY Entity Type MC"Company"
SHOW PARTY Entity Company Type MC
REQUIRE PARTY Entity Company Type MC
SHOW PARTY Entity Company Number TE
END IF
IF ANSWERED ( PARTY Name TE//must have a name before they can proceed further
//more SHOW/REQUIRE pairs here
END IF
END IF

All of these commands are dynamic as of HotDocs 6, which is a major step forward.  Whilst they may look like eye candy, these instructions serve to produce better and more accurate documents every time, simply by forcing/prohibiting better data entry.  When combined with REQUIRE, you really can obey the rule that “if a variable is visible, it must be answered and if it is invisible, it is irrelevant”.  When your systems can follow this rule, your users do not have to have any knowledge of what they are working with or understand the sometimes complex concepts behind the scenes – all they need to know is that if it CAN be answered, it SHOULD be answered and if it cannot be seen, don’t worry about it.

FORMAT “LIST FORMAT”

Another HotDocs instruction model that does exactly what it sounds like, FORMAT allows you to specify the formattin of a “list style” RESULT.  Rather than explain, I’ll simply provide 2 examples which demonstrates everything you’ll ever need to know about FORMAT.

Lets have a repeating dialog named “Party RPT” that has a single variable on it – PARTY Name TE.  Lets produce some differing results with FORMAT, presuming that we have 3 names in our list:

Example #1

""
REPEAT Party RPT
FORMAT "a, b and c"
RESULT + PARTY Name TE
END REPEAT
//the RESULT is Seth Rowland, Rose Rowland and Ian Burrows

Example #2

""
REPEAT Party RPT
FORMAT "a-b-c"
RESULT + PARTY Name TE
END REPEAT
//the RESULT is Seth Rowland-Rose Rowland-Ian Burrows

All it is doing is specifying the format in which a list style result is accumulated and represented.

FILTER Var

The HotDocs instruction “FILTER” is one that I use in almost every system that I’ve designed.  Its purpose is exactly what it sounds like – to filter (a repeat), based upon a certain criteria, so that the data output from the repeat is reduced – only the repeats that match the filter come out.  Like most instructions, it is best explained by example.

Lets say we have a repeating dialog named “Party RPT” that collects information regarding, well, parties in our fictitious matter. A party can be a corporation or individual (PARTY Entity Type MC), but never both. Throughout our system, we are constantly required to insert a sequence of all party names, as well as a sequence of all corporation names.  While we COULD use REPEAT instructions in our templates, this will not work in repeating templates, nor repeating sections.  So lets use the filter command to meet our requirements AND simplify code (its much easier to pre-calculate such lists instead of coding them in every template!).

Party RPT (dialog)
PARTY Name TE (name of party)
PARTY Entity Type MC (type of entity - individual or corporate).

GEN Parties All Names TE (list of all names of all parties)
GEN Parties Corp Names TE (list of all corporations only)

So lets do our “list of all parties” first – this would go in a computation…

""
SET GEN Parties All Names TE TO UNANSWERED
REPEAT Party RPT
FORMAT "a, b and c"
RESULT + PARTY Name TE
END REPEAT
SET GEN Parties All Names TE TO RESULT

That’s it – all done.  Very simple, and now GEN Parties All Names TE contains something like “Seth Rowland, Basha Systems LLC, Ian Burrows, Routine Automation Pty Ltd and John Doe”

Now, lets use our FILTER instruction to slim that list down to only the companies.  Here is our filter computation, named “fil Party Companies CO”

PARTY Entity Type MC = “Corporation”

That’s it – a straight forward test: is the party entity type a corporation? yes/no.  So lets use this, again in a computation…

""
SET GEN Parties Corp Names TE TO UNANSWERED
REPEAT Party RPT
FILTER fil Party Companies CO
FORMAT "a, b and c"
RESULT + PARTY Name TE
END REPEAT
SET GEN Parties Corp Names TE TO RESULT

GEN Parties Corp Names TE now has a value of "Basha Systems LLC and Routine Automation Pty Ltd".

Filters are absolutely fantastic, as they allow you to eliminate a lot of repetitive code and variables.  Take a litigation system for example, with Plaintiffs, Defendants, Third Parties, Plaintiffs by Counterclaim, Defendants by Counterclaim.  You COULD have a separate repeat for each of these parties.  Alternatively, you could have a repeat for Plaintiffs, with a checkbox to indicate that they are also optionally a defendant by counterclaim – then use filters on this variable.  Taking it one step further, you could simply have a dialog Parties that contains ALL parties in the matter, then use multiple-choice, multiple select variables to specify all the roles that a given party may have.  Another example is real estate documents – a given party may be a borrower, but optionally a mortgagee.  If it is an investment property, they may also be a lessor/landlord.  Occassionally, they may ALSO be a caveatee.

Filters allow you to collect information once centrally and then filter it in various ways to produce exact results.

ERASE Var and ERASE Dialog

The ERASE instruction is one of the handier instructions in HotDocs if you are populating data dynamically more than once, or are using ‘temporary dialogs’ during your interviews.  Use of this instruction will completely erase the contents of a variable or dialog, but be warned: it will erase all iterations of that variable or dialog!

Let’s say we’re doing an Estate Planning matter – you have the client, their spouse, a list of children, trustees, executors and some random beneficiaries.  There’s a lot of entities in there.  If you’re working with a system by Basha Systems, there would likely be a central party list that functions as a contact database.  If you’re not, you have several repeats containing contact information.  Either way, the approach is the same.  The example I will use is a generic letter.  You want to program a generic free-style letter that can be sent to any entity on the matter.  But because you quite often wish to send letters to the same party consecutively (a few days apart), you want the generic letter dialog to retain the information of who a letter was last sent to.  Here’s how you do it.

Create your dialog as you ordinarily would – name, address, salutation etc – lets call our dialog Generic Letter DLG.  I won’t get into the import mechanics – all we’re showing here is the ability to clear an entire dialog easily.  On that dialog, we’ll create a button that points to the computation Generic Letter Clear CO.  The script of that is:

ERASE Generic Letter DLG

That’s it.  If the variables on the dialog are saved in the answer file, then the next time you hit that dialog, the details of your last generic letter appear.  If the user wants to use those details – great!  If they don’t, they simply click the button and everything on that dialog is erased and the user can pick a new entity to direct a letter to.  Be warned that you don’t use this on repeating dialogs, as it will erase the entire dialog and all of its iterations/repetitions.

DEFAULT var TO value (and) SET var TO value

Today’s tip is about the DEFAULT and SET instruction models.  Both of these models will allow you to specify that a variable has a certain value, but in different circumstances and with different results.  This article provides the basics on when and how.

To quote the HotDocs help file, “This instruction (DEFAULT) suggests a value for a variable if the variable is unanswered”.  Unsurprisingly, the instruction is exactly what it appears to be – a DEFAULT value.  It will not, in any circumstance, overwrite any existing variable value, even if that variable value is a single space character, or 0 in a number variable.

Personally, I find DEFAULT useful for exactly that – providing default or “starting” answers to variables that may be overlooked by users.  Typically, its something I use with “fresh” answer sets, at the start of a matter.  The simple rule is to generally not bother with DEFAULT, unless you’re using it in a scenario where the dialog isn’t (or shouldn’t) have (m)any values in it.

SET however, is a completely different kettle of fish.  I use SET wherever I can.  The way SET works is very simple – ask no questions, take no prisoners and absolutely give this variable the supplied value.  It will override anything that previously existed in that variable.  There is one major drawback to SET – if you use it in a dialog script, it will prohibit the user from changing the SET variable.  Even if you wrap it in a conditional statement, there is no guarantee that HotDocs will re-process the condition properly and allow you to edit the variable. A minor bugbear.  The workaround (if absolutely necessary) is to use SET instructions in a button (dialog element, script link) on your dialog.  Because the SET instruction is not run by the script dynamically, but rather, is being run ONCE only on user click, HotDocs will not gray out the variable and prohibit changes. For the price of one click, you can set/clear/change/populate and manipulate your data as much as you want, without worrying about grayed out variables, or processing times (heavy script leads to slow response times.  heavy script on buttons only results in a one-off hit when a user actually clicks the button.  Its far more elegant).

And yes, I ignore all the HotDocs “errors” that tell me I am asking a variable in an interview and SETting it to have a value.  Why do I do this? Because I presume that good code gets you a correct answer, but relying on a user to get it right can get you inconsistent answers.  Lets say that everytime you specify you’re wearing a red shirt/blouse, you want black pants.  If you’re male, you also want a red and white tie.  If you’re female, you want ruby earings.  Without SET, you are relying on a user to know the ensemble and, just as importantly, to key it in correctly, every time.  Mistakes happen. Interruptions occur. And sometimes, people just plain get it wrong; its a part of the human condition.

I rely on human correctness (or, more accurately, avoid human error) as often as possible.  So lets show how SET can be used to automatically calculate answers based upon user data entry.  Here’s what my dialog script may look like:

//hide what we're going to force anyway.
HIDE Pants MC
HIDE Tie MC
HIDE Earings MC

//force the user to answer enough questions to calculate the answers
REQUIRE Gender MC
REQUIRE Blouse MC

IF Blouse MC"Red"
SET Pants MC TO "Black"
IF Gender MC"Male"
SET Tie MC TO "Black and White"
ELSE IF Gender MC"Female"
SET Earings MC TO "Ruby"
END IF
ELSE IF Blouse MC"Black"
SET Pants MC TO "Black"
IF Gender MC"Male"
SET Tie MC TO "White"
ELSE IF Gender MC"Female"
SET Earings MC TO "Diamond"
END IF
ELSE
//its not a red shirt/blouse and its not black either, let the user pick these ones....
//of course, you could specify as many ensembles as you wished.
SHOW Pants MC
IF Gender MC"Male"
SHOW Tie MC
ELSE IF Gender MC"Female"
SHOW Earings MC
END IF
END IF

In the above instance, you may be a little colour challenged, so you’d add this at the top of your code:

DEFAULT Blouse MC TO "Black"

This would thereby ensure that the first time you were presented with the dialog (for each different answer file), you could have your black ensemble, without touching a thing – just let the answers ride.  At the point you specified anything in the Blouse MC variable, the DEFAULT instruction would be ignored forever more.  But the first time round – it would do the job.

Looking at this, its a lot of code to avoid having the user answer a few extra questions.  However, lets put this in perspective – let’s say this WAS a program to get dressed in the morning, and it would get you ready for work in half the time you currently spend.  But a wrong answer would mean that you would have to go back to the start, re-specify your answers and let the program do its thing again. Suddenly, this isn’t “too much code”, but rather “time saving code”, because it calculates 2 answers based upon the answer to the first one.

The real benefit to such an approach (where possible) is that suddenly, your proof reading times are reduced.  Sure, saving your support staff time (and improving data integrity) is great. But saving an attorney an extra few minutes on proof reading (because the attorney only has to check one answer, not three…), now that’s profitable.

Calculate data from existing answers where you can. The LESS questions you ask, the better; so long as your answers allow you to calculate everything you need to know.  It is not uncommon for me to ask 10 questions and produce 13 answers.  SET and DEFAULT will allow you to do this.  DEFAULT will set up your most common answer set, so they don’t have to worry about doing anything at least SOME of the time.  SET will allow you to implement “sets” of instructions, so that one answer produces multiple correct answers.  That saves everyone time.

What should the price be for ONLINE document assembly

If you are reading this blog/blawg/weblog, you get “document assembly”.  You understand its power as a productivity multiplier.  You know how it transforms the practice of law and business.  You see the tangible results in improved work product and faster turnaround.  THAT IS GOOD.  But have you factored in the cost of deployment.  You can have “cheap” desktop software which allows you to make the system available to a limited group at very low cost.  But what happens to that cost when you wish to extend the benefits of automation to a wider group, say 20 to 50 users, maybe 100 to 500 users. It is then that the economies of scale weigh in favor of buying a ROBUST web-server based document assembly system.  There is a middle step of deploying the desktop software through Citrix or Terminal Services, but even such approach requires configuration costs, maintaining profiles and updates and the other consequent costs of an individual deployment and support.

The current price ratio of single desktop client to a server client, factoring software cost only is 100 to 1, assuming a $30,000 server vs. a $300 desktop.  However, one should consider a number of other factors.  (1) Cost of installing software and configuring it on EACH desktop times the number of deployments vs. cost of installing on and configuring a single web/application server. (2) Cost of applying updates and patches to EACH desktop times the number of deployments vs. cost of applying patches to a SINGLE web-server.  (3) Cost of maintaining each workstation with sufficient hardware and memory to run “full client” applications vs. cost of maintaining each workstation with sufficient hardware to run a basic “web-browser”.  (4) Cost of maintaining land updating libraries of templates on each workstation and/or central file server vs. cost of uploading “updated” templates to a single Web Server. (5) Inability to “invite” outsiders who do not have the “fat client” software to use the system vs. ability to invite clients and others to enter their data through a secure web connection.

Once you start factoring in all of these costs into your equation, and once you start looking at deployments of more than 20 users, the case for ONLINE document assembly becomes less a matter of “price” and more a matter of preference.  If you are interested in ONLINE document assembly, please give us a call.  We offer development services in Exari, DealBuilder and HotDocs.

Client Facing Data Entry

Have you ever wished that your CLIENTS could enter their own data.  Sure, you wouldn’t want them to “do their own documents”.  But isn’t it a pain taking hand-written questionnaires filled out by clients, and then having to re-enter that data into your HotDocs template system.  There has to be an easier way.  Why not have a secure “data entry form” on your own website where you can direct your clients to answer the questions.  Such system would notify you when a questionnaire was completed.  You could then “download” their information as a HotDocs answer file and use it for your templates. Such a system is in the “Skunk works” phase at Basha Systems.  If you are interested, please give Rose a call at (914) 827-9173.

The world of web forms has advanced dramatically in the past few years.  Basha Systems will be creating for its clients private portals which can either be part of a custom website or a subdomain. These portals will include, in addition to the client intake forms, custom built to feed your own HotDocs system, areas for firm articles and announcements in a stylish website.  We are looking for early volunteers who understand the value of productivity and want to take their workflow to the next level.

Please give us a call.

Still Using GhostFill

Are you still using GhostFill?  Have you invested a lot of time in building templates?  Are you using Amicus Assembly?  It has been over two years since GhostFill officially stopped supporting the product in the retail software market.  There are still published systems using GhostFill (one of which we support).  So if you wanted to know, what is NEXT after GhostFill …give our office a call at (914) 827-9173 and ask for Rose. We know GhostFill inside and out.  We also know all of the leading document assembly systems, both client-server and web-server based systems.  We are also soon to add Amicus Attorney to our list of practice management software certfications.

We can give you your options and present you the alternative for conversion. Because we know GhostFill so well, we can recycle the code and logic, building equivalents in the alternative document assembly markup languages.

Give us a ring.  Don’t wait for your computers to die of old age before you make the switch.  OR, if you just need a refresher, we can help you extend the life of your existing system.

Off-Shore Word Processing

In this time of economic downturn, a number of firms are looking at making Staff cuts.  And one of the areas they are looking hard at is word-processing.  There has been an aggressive pitch by “vendors” offering to outsource the word-processing department.  With the advent of high-speed color scanners and high-speed internet, it is possible to send your document (or your dictation) around the world, and have it delivered back to you 24×7.  With worldwide networks and hosted document repositories, it is possible to have a service provide with offices in every major time zone.  And so, what is missing in the bid by these vendors for your work. What are some of the choices.

Read more

Sharepoint and Infopath vs. Time Matters and HotDocs – When FREE is NOT FREE

FREE is not FREE.  We in the legal practice management community live in a “bubble”.  Because of our “unique needs” and “limited budgets” lawyers and professional service organizations, have been able to attract a unique set of software tools for drafting our documents and managing our business.  Among these tools are document assembly software packages like HotDocs, GhostFIll, DealBuilder and Exari.  And among the practice management tools are ones like Time Matters, Amicus Attorney and PracticeMaster.  These tools are well developed, with development histories of over a decade or two decades of use.  And these tools are “Rapid Development” platforms that enable developers and consultants to build powerful and highly customized solutions for their clients.

It is true there are OTHER tools that can be used for managing contact information and for automating forms.  These other tools are “free” since many of them are included with the licenses to products many already use.  InfoPath is included with the enterprise version of Microsoft Office; SharePoint Services is included with many versions of Windows Server. And because these tools are “free” and because larger organizations have dedicated programming staff to build solutions with these tools, there is a tendency outside of LEGAL, to use these tools instead. THIS is a mistake.

But Can’t We DO the SAME thing

I have spent time exploring SharePoint and InfoPath.  From my perspective, as a consultant, building solutions based on “free software” is a great sell.  I could build solutions with Merge Templates; or go beyond and set up InfoPath data entry forms to fee the merge templates.  I could offer these forms over a “free” SharePoint server.  I could take the document markup used by a document assembly product like HotDocs, and replace it with Bookmarks and XML objects with rules assigned to those objects.  This would be great for my business, until I asked the client to pay for the development bill.

The reason lawyers and professional service organizations choose a HotDocs for document assembly or a Time Matters for practice management is because the development costs for equivalent level of customization is a fraction of what they would be for building a custom system on SharePoint Service, InfoPath with Microsoft SQL Server.  These solutions are powerful and integrated out of the box.  I was asked by a prospective client how much time it would take to covert a set of 100 lending documents into a series of automated HotDocs templates.  When I replied a conservative 2-3 months, his response was, “That would replace our division of programs in _______ .” These tools are “staff multipliers” both in the efficiency such systems can achieve, and in the efficiency of these tools for software development.

A Well-Kept Secret

Big “IT” is keeping these tools secret.  It is always better to not have to requisition new software for solutions that “could have been built in-house”. The risk of bringing in such software lies both in the cost and the risk to existing staff who could have been tasked to build the solution in-house.  Besides, these systems they say, are just a bunch of data tables and merge fields; what could be so hard.

They say the “devil is in the details”.  In practice management and document assembly, that is true. The goal in document assembly is “RTP” or ready to print. And yet, there are thousands of potential nuances in any given document. The goal in practice management is in the multiple views of the data and the ability to search effectively across multiple tables to mine the data,and the ability to vary the data requirements across different practice groups and different purposes.

The real risk however for big IT is not document assembly software and practice management software (much of which was developed in North America), but rather outsourcing of entire divisions to India, China and Pakistan.  Big “IT” looks at “body count” and lines of code, rather than productivity, suitability of solutions to the requirements, or time from conception to delivery.