HotDocs Developer 11: A developer’s perspective on the new features

One of the perks of being the lawyer retained by HotDocs is that I get to try out their new stuff early. My fellow developers, you are going to like HotDocs Developer 11. Here’s a short note about what you can expect and some tips to get optimal use of the software.

I’m a template developer and a practising lawyer, and I’ve been upgrading my clients’ templates ready for this release. This note assumes you too are a seasoned user. It’s not part of the official release notes, and you’ll still want to cast your eye over the usual ReadMe text and use the new help files.

The biggest impact for me: support for .docx as the native format for templates. The process of rendering documents through the medium of RTF files had inherent issues which are now gone. You’re going to need to use Word to save your current RTF templates as a .docx file because HotDocs isn’t going to do that conversion for you. The first thing you are going to notice, if you have any graphics such as company logos, is that the file size of your template is going to shrink. Some of my templates with client logos have shrunk dramatically.

The next thing you are going to notice is that life is now much easier when it comes to controlling formatting. Now is the time to get a grip of how Word uses Styles, and how to import them into documents, and how to set default fonts in documents. I recommend using styles with custom names so that there’s no risk of them clashing when they reach your clients’ PCs. Particularly with inserted templates, I am seeing an end to glitches with inconsistent paragraph formatting. This is a visible benefit for your template users.

While on the subject of template users, don’t forget they are going to need to be using a compatible version of HotDocs – whether that be HotDocs Server 11, HotDocs User 11 or HotDocs Player 11. Otherwise, they won’t be able to read your templates. You can force Developer 11 to create templates that are backwards compatible, but you won’t want to do that.

When I started upgrading my existing templates, I fell into a trap I had overlooked. I had a variable naming scheme that included some variable names in caps. For example, I might have a date variable called ‘MAIN agreement date’. It seemed like a good idea at the time. I’ve got some template sets that had nearly 2,000 variables, so some form of naming convention was essential. The problem is that I used some words that now happen to be new keywords in HotDocs. Developer 11 includes a host of new math expressions. For example, you can use TERM to calculate loan terms as part of the new financial model. I had some variables which happened to be prefixed with ‘TERM’ and that got ugly. It’s my own fault – the standard advice is that one shouldn’t use capitalised terms because there is always the risk that they will conflict with new reserved words for the software. I did it anyway. Maybe you have too.

I just mentioned the new math expression models, and they will doubtless save some developers having to create their own computations.

After .docx support, my favourite (I’m a Brit – indulge me with the spelling) feature is the support for parameters and local variables. There are critics out there who love to say that HotDocs requires scripts that look like programming – you’re over that debate or you wouldn’t be reading this. However, I expect some of those critics will say ‘I told you so’ when they hear mention of ‘parameters’ or ‘local variables’. You aren’t that simplistic, are you? For any of you who build complex templates, these features are going to make you smile. I find they make it easier to create templates that are easier to follow. I’ve had Developer 11 for a while now, and I find I can go back to a template I haven’t touched for a reasonable period, and it’s easier to remember how my scripts and computations worked.

Parameters and local variables are harder to explain initially, but you won’t want to be without them when you have put them to use. Here’s an example of how I used them recently: I was working on a template for an outsourcing agreement that included a table showing the number of days needed for certain tasks. There were a number of tables that could potentially be included, each with multiple rows. The number of days depended on various calculations. Now, the challenge is that the days were not whole days – we could have 1 ¼ days or 2 ½ days, for example. Obviously, all the computations had to use decimal numbers, but my client wanted them to be output as fractions. I created one computation with a parameter that converted any decimal number to a fraction (which had to be a text format, obviously). I would have needed to repeat the same computation dozens of times with the previous version of HotDocs.

Local variables are really useful in scripts or computations where you need to store temporary results of calculations. Until now, computations could manipulate one internal value, namely ‘RESULT’. That was limiting. Now you can have any number of values in the computation.

The new Template Manager looks identical but is now much faster for me. I had some large component libraries that could upset Template Manager if I made too many changes without occasionally closing Template Manager to force a database update. That’s not a problem anymore, and it’s very fast.

There are other changes as well, and this note doesn’t do them full justice. Instead, I just wanted to whet your appetite for the upgrade. Hey, it will be free for most of you with maintenance contracts. It’s worth the upgrade even just for .docx support, but don’t overlook those new features. Your clients won’t see them, but they will give you that warm glow inside.

I hear that there’s a new forum for developers to exchange ideas for computations. Expect to see some imaginative uses of local variables and parameters. Decimal-to-fraction converter anyone?

Charles Drayson
Charles@DraysonLaw.com