Over the past decade, document assembly systems have come and gone.  Some, like HotDocs 4.2, HotDocs 5.x, CAPSAuthor, WinCAPS, SmartWords, Agility, FastDraft, Form Bank, MasterDraft, MillRace, NovaDocs, PowerTXT, Scrivener, ThinkDocs, and WorkForm, are no longer supported.  Some like GhostFill, ProDoc, WinDraft, and Perfectus have only a small developer community that provides limited support. Others, like WordVBA and Wordperfect have macros tools that require dedicated technicians to support and maintain. Yet other systems, like Pathagoras, D3 and qShift lack support for traditional programming techniques like repeat loops, nested IF statements, and variable scripting.

At root, all document automation systems are the same.  They address the same fundamental issues: which documents, paragraphs, and phrases to include in output document and what data to use to fill in the blanks.  The hard work in document assembly programming is NOT the programming, but rather crafting the business rules which govern whether to include or exclude text and how best to fill in the blanks.

It is for that reason that we have developed a universal approach to marking up documents and document automation interviews that can work with any document automation system.  This approach allows us to take templates in legacy document assembly systems: (1) identify and catalog all the conditional rules, (2) identify and fully describe all the variables (by function, type, prompt and defaults), (3) identify all the dialog objects and scripts, and (4) extract all the text objects, clauses and subdocuments.

From there we structure in Excel a prototype interview in HotDocs, GhostFill or DealBuilder) that mirrors the functionality of the legacy system.  In describing each new variable, object, script in the new platform, we maintain a reference to the comparable object in the legacy platform.  Once the interview and datastructure is completed in the new platform, we turn to the text objects, clauses and subdocuments.  Where possible, we have preserved the markup of the legacy platform in the text documents.

We generally consolidate the text objects into master templates so that they are more easily edited as a whole.  Where text objects are used in multiple templates, we keep them separate and use INSERT or INCLUDE commands to bring in the text where appropriate.  As part of the process, we also strip the text of all formatting and then carefully apply a Word style sheet using outline schemes, paragraph styles and character styles to handle ALL text formatting, spacing, letting, kerning, outlining, numbering etc.  This allows use to use the stylesheet pro grammatically to change the document templates and the assembled documents.

There is a tendency to want to “throw out the baby with the bath water” when a firm decides to adopt a new document assembly system.  While the process described above TAKES time and planning, it does preserve the MOST valuable part of the automation process, the attorney time and workproduct.  If you have a system that WORKS, but is old and dated, it is best to use that as a base for the new system, rather than to scrap it entirely.  That gives you a result that will WORK when delivered.  And then, you can have fun, spend money, adding in the new features and enhancements that the new document automation platform offers.

LEGACY DOCUMENT ASSEMBLY PLATFORMS

HotDocs 4.2 & HotDocs 5.x: LexisNexis no longer supports these early Windows versions of HotDocs.  Hundreds of thousands of licenses to HotDocs were bundled with WordPerfect Legal Edition. Early HotDocs had limited scripting and presented questions in a series of popup-dialogs as the document was assembled from within Word or WordPerfect. With HotDocs 6/2005/2006/2007, HotDocs transitioned to a single interview object and moved the assembly outside the word-processor into an RTF-Assembler.

CAPSAuthor & WinCAPS: Once the best and most advance document assembly platform for MS-DOS.  CAPSAuthor still runs in a DOS-window.  WinCAPS is the assembly environment, built to run in Windows 3.1 on a 16-bit platform.  There were hundreds of systems built with CAPS, including several that were sold commercially.  We were responsible for converting one CAPS system, Drafting Wills and Trust Agreements (“DWTA”) from WinCAPS to the GhostFill platform.  We have also converted a document lending system that had over 5000 CAPS objects into GhostFill. The process of extracting the business rules, text and variables used for those conversions, could just as easily been applied to converting those systems to HotDocs.

SmartWords: Built on bTrieve and Xyrite, a very sophisticated engine. When the owner went out of business, the software was taken out of circulation.  Two years ago, Basha Systems converted Wealth Transfer Planning, the one commercially viable product built on Smartword, to the HotDocs platform.  That content is now owned by Interactive Legal Systems, which built a custom wrapper around the HotDocs templates that expanded on the document and answer management features of the original software.

Agility, from RealWorld Solutions, was a DOS-based product most suitable for offices using pre-Windows versions of WordPerfect.  The program had a deliberate strategy of simplicity.  Agility included most of the basic features one would expect in a document assembly tool, including nested logic and repeat loops.  But as there is no Windows version, non integration with any word processor, and no math functions it lacked viability for search document assembly applications.

FastDraft, from Interactive Professional Software, allowed a user to select a type of document, choose from available clauses and then fill in the blanks in the selected clauses.  The user could reorder the clauses and easily back up to previous steps in the process.  In this way, it was similar to the more powerful qShift.  FastDraft lacked features that make sophisticated rule-based practice systems, such logic, math functions, and validation of dates and numbers.

ThinkDocs started out as a graphic forms engine, which applied the concept of data stored in a database and hooked “live” into the assembled document.  It used DocVariables in assembled documents to retain a live-link to “answer data” stored in a database after the document was assembled.  As such, the system lacked any support for conditional logic on text in the template, unless the text itself was stored in the database and used to set the value of a DocVariable in the assembled document.  ThinkDocs appealed to users because of the “live” link—but in practice such live links worked only with simplistic documents – those templates lacking any complex embedded logic.

Form Bank, from now defunct ExperText Systems Ltd, was developed by Doug Simpson.  It made clever use of an automated teller metaphor, with developers depositing materials into the system, users withdrawing them, and a :”bank manager” determining who can do what.  It depended on Microsoft Access for a database of clauses, questions and other components that could be shared across multiple forms and managed by a group of cooperating users.

MillRace, from Old Mill Software was designed to allow attorneys to build documents by combing through annotated collections of forms and clauses, based on client requirements and negotiated issues.  It rejected the “QUAIL” – question, answer and imbedded (sic) logic – approach of most document assembly system. Development was ceased in 1997.

NovaDocs, from Novation Corporation in was conceived by James Conger.  It provided the basics of document assembly in an easy-to use and attractive package that exploits such features as collapsible outlines and drag and drop. Clauses and questions could be edited on the fly while assembling documents and making for little distinction between developer and user modes.  However, it lacked conditional logic, repeat loops, answer validation and other features standard in most document assembly engines.

PowerTXT, from Intercon Associates, Inc. was a feature rich, and easy-to-use program that evolved from FlexPractice, a popular DOS-based document assembly program in the 1980s.  In PowerTXT, model documents showed up as graphical outlines on the screen.  After users point and click thyeir way through necessary decisions, questions are asked that gather the details needed to assemble the desired documents.  The program did not support traditional programming techniques like repeat loops and nested IF statements.  Those who liked the outline and document-model structure of PowerTXT, would like IXIO.com’s qShift document modeling software which places clause libraries and document models on a privately hosted and secured web-server.

Scrivener was created by Dan Evans.  It was distinctive in being build on a true rule-based expert system engine and was among the first document assembly products to make good use of outline representations of document structure.  It provided support for incremental model revision as you use the system in everyday practice.

WorkForm and Visual WorkTool, developed by Analytic Legal Programs, Inc. was a powerful set of document assembly tools was a dominant player in the 1980s.

DOCUMENT ASSEMBLY PLATFORMS LACKING TRADITIONAL PROGRAMMING TOOLS

Pathagoras: Developed by Roy Lasris as that “alternative” to programmed document assembly. This system supports “quick and dirty” clause based assembly with rudimentary variables. If you want to build a library of “snippets” for reuse and throw some fields in, this software can save you time over traditional word processing. But to call this software document assembly suggests that this software is in the same league as HotDocs and DealBuilder (which it isn’t). That said, there is a lot of good forms built by lawyers with Pathagoras that could be made better in HotDocs.  The markup and structure of Pathagoras would make conversion fairly easy, and give users much more power and flexibility.

D3 Documents. MicroSystems SQL-Based clause manager and form filler is a great tool for fitting into the workflow of simple documents.  As a replacement for WordVBA and macros, it is a major improvement, serving as the glue for all those communications and simplistic documents.  What D3 does not support is traditional programming techniques for nested IF statements, loops, repeats and while statements, as well as script objects.  However, it represents a good start in that it forces the user to identify the data necessary for assembling templates and actually choosing and structuring the model language that will form the basis of the template.

qShift.  IXIO built a system that I would have loved to use when I was practicing law a decade ago.  It automatically takes a well-structured agreement, and breaks it into its constituent elements and presents a document model to which you can then apply automation rules.  We have reviewed it elsewhere.  It is great for choosing and crafting and dynamic form which will then be customized to a particular clients needs in a word-processor.  However, it lacks support for traditional programming techniques used in document automation software: multi-variable conditions, nested IF statements, computed variables, variables that share the same data source but are displayed differently, and full string and arithmetic manipulation capability.

WinDraft, from Eidelman Associates, was innovative and powerful when it come out in the 1990s.  It accomplished, inside the WordProcessor a level of dynamic automation that it took the other document assembly software years to catch up to.  However, the website (www.lawtech.com) hasn’t been updated in several years.  It’s business logic works with a simplified document markup and structure that did support nested logic and variables.  As such, the systems can be easily converted to HotDocs and DealBuilder.

CONTENT SYSTEMS:

DL Drafting Libraries: This proprietary form set, originally in DOS, but now in Windows, represents the “TurboTax” for
LawGIC
WealthCounsel