HotDocs, DealBuilder and GhostFill all work with RTF Templates. On occasion, a template may include an image for a watermark, a logo, or some other purpose. Thanks to an ingenious feature of Word, when you some a document to rich-text format (RTF) the images are converted to a useless, but huge windows metafile. This ensures compatability with ANCIENT word processors, but does nothing for you. In fact, a simple company logo can expand the size of a short letter from 20K, to 1,200K (or 1.2 MB). And that is before you start adding text. The solution is a simple change in the registry for WORD on each machine.
For better or worse, the future of document assembly is on the Web. The web offers cheaper maintenance, quicker updates, and a more consistent look and feel. The web is also the most cost-effective on total cost of ownership (“TCO”). The catch is that startup costs are much greater for web deployment of automated templates. Particularly since most law firms wish to “dip before they dunk”, the presence of desktop or networked document assembly solutions is critical to the development of automated content. In the past five years, millions of dollars have been invested in innovative web-delivery of automated document creation systems. By contrast, the investment in client/server based document assembly software has been minimal.
The sole exception has been LexisNexis’s continuing development of the HotDocs platform. Korbitec, once the leading rival to LexisNexis, has ceased further development of its powerful GhostFill document assembly engine. No other viable vendor has stepped up to fill the gap and compete head-on with LexisNexis. LexisNexis deserves real credit for investing resources in building an ever-more powerful version of HotDocs. They should be encouraged to keep up the good work and rewarded with license sales. As I have written in my review of HotDocs 2006 posted in Technolawyer, the HotDocs platform has been transformed into a toolkit that can do some amazing things to manipulate data and forms. However, in the absence of a viable direct competitor on the client/server space, there needs to be a clear reason for LexisNexis to continue to innovate.
Before I talk about the future, let me talk about the present. Let’s look at the pricing of document assembly software. HotDocs Standard desktop costs $300 and HotDocs Professional costs $850 per license. What that means is that for a small user base (1-10 users) your software investment is very small. As the user base increases beyond 50 users, the cost of software starts to become a factor. The reality is that most document assembly installations start out as departmental efforts (under 20 users) or occur where the firm purchases a form set (in which case the “player software” is free). By contrast, online software starts at $12,500 and goes up to $100,000 for the server software. These fees do not include the server hardware, the consulting services configuring (and securing) the webserver, or the usage fees charged by a number of vendors.
It is this GAP which forces many users to look at the “cheap” software and get locked in. This benefits LexisNexis which offers both cheap HotDocs desktop software and a much more expensive HotDocs Server product. The cost, however, is that the web-based developers (Business Integrity, iXio, Exari, Perfectus and others), have template development environments that offer alternative design philosophies some of which may be better suited to your firm or company. But because the startup (or prototype) costs are so high, such software is only available to the AmLaw 100 law firms and large corporations.
The FUTURE of document assembly.
Microsoft, with the release of Vista and Office2007 has closely aligned its software with the web through Sharepoint webservices, integrated throughout. The 2-ton gorilla in the room is Microsoft which is starting to move into the “vertical” space and recognize the needs of legal. Microsoft Legal is currently using Business Integrity’s DealBuilder product, which means that they have had an opportunity to evaluate closely a very power and flexible automation system. It is only a matter of time before some of the features of DealBuilder show up in future versions of Office and Sharepoint.
Exari has announced the conquest of the “holy grail” in document assembly—The ability to assemble a document, send the result out for comments and editing, and then to bring the document back into the automation environment so that the variables and business logic continue to function on what is now the “customized template”. They offer a feature which previously was only available in Smartwords (now defunct) and Rapidocs via a proprietary word-processor. With the advent of WordML (a new open file format of XML files packaged together) it is possible to “safely store metadata” about the rules and structures of a word document, separating content, structure and format. All of the web based developers are looking at what can be done with WordML to allow the “round tripping” of templates and documents.
Word currently allows you through macros and forms (including InfoPath and Taskbar data entry) to do much of what document assembly software does. The catch, is that building such system requires specialized expertise in programming. That means, to do court forms, form agreements and other automated documents requires hiring an experienced programmer. The strength of the document assembly software is the “easy markup” which can be understood by the lawyers and managers who work with these forms, and the ease of deploying updates. Also with the separation of “business logic” from the word document, such document assembly systems allow the templates to run on multiple versions of Word (and WordPerfect) without recompiling macros.
LexisNexis is continuing to explore new options for its HotDocs platform. A while back, it built into HotDocs Professional the ability to “Publish Templates” for HotDocs Server. This means that for a very low investment, you can develop templates for internal use, and when the templates (and users) hit a critical mass, then invest in HotDocs Server. We at Basha Systems, now work with Accudraft and offer HotDocs Online hosting services for our clients. We offer our clients NO STARTUP COSTS and NO HARDWARE COST hosting. For a nominal monthly fee, plus ongoing document automation consulting, we can put a law firm or company online.
So the future is ONLINE … it is just a matter of time.
When you open your Inbox it may appear to take up to several minutes to load. Time Matters will seem like it is not responding. Time Matters inbox is “personal” to each user. The inbox contains both Internet Email and Time Matters emails, as well as attachments. The mailbox can quick get overloaded, even when you appear to have been keeping the list of items in your inbox to a manageable roar. In fact, your mailbox is most likely overloaded. There could be hundreds of emails in the Deleted Items folder. There could be emails in subfolders. All take time to load.
The solution lies in regular dilligence on managing your inbox.
- Keep the number of items in your inbox folder to under 50
- Set your mailbox settings to show on email list (not inbox) any records that have been associated with a Contact or Matter
- Create a folder for List-Server mail and set a rule to automatically move the incoming email to that folder
- Empty the deleted items folder (right-click on folder and choose empy bin)
You want to control the number of lines that appear on a dialog that displays in “Spreadsheet” style. Quite often, the default number of lines visible on a spreadsheet style dialog are aesthetically offensive. We need to control this for two reasons: 1) its ugly; and 2) screen real estate is quite often at a premium.
Basha Systems use a CNT prefix for specific purpose number variables, to differentiate between a “true” number variable used in document assembly templates, and those number variables used for tracking, counting & limiting. Lets presume we are dealing with a spreadsheet to enter in children’s names and DOB’s. In the dialog PRIOR to the spreadsheet dialog relating to children, create a variable something similar to Var_CNT. The prompt should be something like “How many children do you wish to enter?” In the script of the spreadsheet dialog, place the following:
This will ensure that the spreadsheet is LIMITed to the number of lines that the user has indicated are required. You may wish to REQUIRE the Var_CNT variable, so the user must enter a number to gain access.
If the spreadsheet dialog is actually “Spreadsheet on Parent”, you should script the dialog so that it doesn’t even appear until such time as the Var_CNT variable has been answered. Using this approach, the REQUIRE option is redundant.
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.
The result is that thousands of legal templates are locked in poorly supported legacy systems, representing hundreds of thousands of hours of programming and invaluable legal workproduct. This article explores a process of identify and extracting the business rules and workproduct from these legacy systems and moving them to more powerful and better support platforms such as HotDocs or DealBuilder.
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.
DL Drafting Libraries: This proprietary form set, originally in DOS, but now in Windows, represents the “TurboTax” for