Over a decade ago we were called in to review a home grown document automation system built in WordPerfect 5.1 (for DOS). The system had hundred of “forms”, organized in a careful hierarchy. Each form was specially coded with WordPerfect FormFields. The templated system has specially-created template forms. The user would create a new document by picking a template from a folder structure, answer a list of questions, and voila, the document would be done.
There was one hitch. The firm had just gotten Windows95 and purchased WordPerfect 6 (for Windows). When they “opened” the templates in WordPerfect 6, the program dutifully compiled their templates and produced a PerfectScript error. Novell/Corel (or whatever it was called at the time) had come up with a new scripting language that made all the prior code obsolete. An experienced programmer could have made the minor fixes to each template to get them to work. However, the original form designer had long-ago left the firm.
The result was for the next few years, the firm ran the templates in DOS-Emulation Box on Windows. Eventually, the form set was abandonned, and the firm, rather than building on the form set, adopted a document management system and created a “forms archive”. Document creation now took twice as long and was riddled with mistakes and metadata from prior forms. But hey, the firm was making money on their hourly rate, so no-one complained.
Lessons Learned (or not learned)
Word Processors change and evolve. They continually improve their feature set. Word used to have a “WordMacro” language. This was replaced by WordBasic, which was replaced by Visual Basic for Applications (VBA), which was supplemented by SmartTags, and is in the process of being replaced by InfoPath/XML based structures. The only thing constant is change. Because of that, there is substantial risk building assembly systems with the native word-processor automation tools.
The firm described above, could have been your law firm. It seems tempting to us the free software that comes with your word-processor. Who needs to speed $300 on HotDocs, when Word/WordPerfect can handle the automation natively. However, before getting into the ease of use of a particular document automation engine, consider one thing. With an out-of-wordprocessor assembler, the situation described above would not have happened. The firm could easilly have migrated from WordPerfect 4.1 (for DOS) to Microsoft Office 2007 without recoding their templates or recompiling their code. In fact, they could have continued to use BOTH wordprocessors.
This is because the markup used by HotDocs/Dealbuilder/GhostFill does not depend on any particular wordprocessor codes. It can work with any rich text formatted (“RTF”) document. The logic, rules, codes and prompts are not stored in a wordprocessor template, but rather in a software document automation engine that exists outside the word-processor. Thus, a change in wordprocessor will not destroy the system. It may require some conversion of the templates to take advantage of new formatting and structuring features of the updated wordprocessor. But it will not require any recompiling of the logic or the interview with the concommitant risk of breaking.
Expertise in Working on Migrations and Conversions of Legacy Systems
Basha Systems has expertise in Word VBA and WordPerfect’s PerfectScript. We also have expertise in understanding the file-formatting structures of both Word and WordPerfect down to their minute details. We even have programmatically editted the raw RTF code output of Word and WordPerfect to achieve results in automation that could not be handled by the scripting engines of these products. There are few Word VBA and Perfect Script code that we could not expose, document, and reverse engineer in a new document automation platform. That is what we do at Basha Systems.
We ASSUME that legacy systems have value. When engaged, the first thing we do is document the structures, content, and rules of existing automation. We do not throw out the baby with the bath water. We build a roadmap that documents the existing rules and uses them as a basis for going forward. We take your existing system, identify the good and remove the bad.
Our approach can save you hundreds of hours on an automation project. We build a core interview for the form set, and then work with the staff and attorneys to consolidate the forms into easilly manageable templates. We then teach the staff how to update and maintain these systems themselves.
Document Assembly vs. VBA/PerfectScript
We have often been asked to compare document assembly to wordprocessor automation. If you look at wordprocessor automation tools today, they are quite advanced. By including VisualBasic as a programming option in both Word and WordPerfect, these programs literally empower an experience software programmer to do ANYTHING. You can create forms, apply dyamic rules to them, embed conditional and calculate text into an assembly, connect to a data source, and in short do some gee-wiz stuff. A software programmer with years of experience can handle this process quickly by drawing on snippets and software precedents, and stringing them together with on-change and on-click events, custom navigation, etc. In the past decade we have seen some amazing things. We once saw a version of DEFENDER (the video arcade game) done with Perfect Script.
The catch is not WHAT YOU CAN DO, but rather HOW FAST and WHO can do the coding. As I explain in more detail in Educating Rita – A Case Study there is a divide between lawyers and programmers that requires the two to work together to produce a usable document assembly system. The typical VBA code can ONLY be understood by a programmer. The reviewing attorney can merely test and check the results. By contrast, with document assembly, the reviewing attorney can easilly edit the underlying content. Moreover, changes in questions and logic do not entail a full system redesign, changing forms, on-click events, and autotext. Rather, with HotDocs, during a test assembly, a field can be changed with a simple Right-Click option. It is the SPEED of document assembly tools that makes them ULTIMATELY CHEAPER, MORE POWERFUL, and simply BETTER.
