Over the years of working with HotDocs we have encountered many issues with the basic design of HotDocs, client requests and what not, that have required creative solutions. And in so doing, we have changed our approach from one that centered around “documents” to one that centers around data and workflow. In so doing, we have substantially changed the way that we code in HotDocs, using methods and approaches that arise from other coding languages and programming principals. We have found HotDocs to be flexible and powerful enough to support, for example, the use of common elements across multiple templates, use of templates as reusable objects, using local and global variables, internal databases, and dynamic indexing and cross-references. Such features are not required for basic template design. However, there use leads to more user-friendly interviews, more dynamic data entry, and the ability to design templates and interviews that reflect and respond to the data input.
Nothing in the typical HotDocs training prepares a developer for this use of HotDocs. HotDocs contains powerful tools, scripting language and capability to support advanced object oriented programming. The functions are documented, but some of the more powerful capabilities are only hinted at in the documentation. Our approach starts with a recognition that documents are not the center of a template system, but merely the output of a system. Documents are the output of carefully crafted data gathering processes that begin even before the document assembly interview. A well designed system understands and mirrors the natural data gathering process, and then guides the user to the appropriate documents.
When confronted with a HotDocs project, many clients and some developers think only of the document in front of them. Code the first document, then move onto the next. Just identify the fillpoints and create a variable. When developers code one document at a time, they focus on the relevance of data to the particular document at hand, failing to recognize that data in an answer file will be reused for multiple templates.
We have been called to rebuild several CAPS Author systems. What is different about CAPS is that it truly was a platform to develop practice systems. CAPS views templates as merely one of several element types that compose a CAPS practice system. As such, a typical CAPS systems could have hundreds of document templates, but actually output under a dozen documents. This model of design is one of the approaches we take at Basha Systems in designing our HotDocs systems for our clients.
The benefits of a modular and systemic approach are many. They include:
- Use of reusable components which can be edited once and used in multiple documents.
- Use of global scripts that simplify template markup, making templates more readable.
- Use of global style design to ensure consisent formatting and numbering.
- Use of common dialog design to ensure familiarity and ease of use in the interview.
- Use of consistent variable naming conventions and schemas across multiple dialogs, templates, and even practice systems.
- Use of party systems to collect data and dynamic lookup lists.
- Use of shell templates that either aggregate templates into a single resulting document or launch multiple documents without running redundant interviews.
Anyone can code a document. Only a few can code a system. In looking at a document assembly project, if you begin from the systemic approach, you will be able to see the overall process and the individual reusable elements. And maybe, you will begin to get better results.