How does one explain to a web developer that document assembly is more than just throwing up some web-forms with fields tied an SQL database? Sometimes, the hard way, by letting them try it themselves …
Related Link: For more information
Document Assembly is more than “merge templates”. A merge templates takes “defined fields” and replaceS the field codes with data from a data source. Anyone who has worked with a document assembly program, like HotDocs, GhostFill or DealBuilder, knows that “field codes” are just the beginning.
And yet, on countless occasions when talking to prospective clients (particularly large corporate IT or big firm legal, and even smaller law firms) they view document assembly as just a bunch of fields that can be filled in by any Tom, Dick or Harriet paralegal off the street, with little or no training. They view the “coding” of such systems as beneath them in its simplicity.
To corporate IT, it is a matter of laying out the fields in a database, tying that database to a series of web forms, and then pushing that data through a Word/RTF engine to produce the final output. To them, there is no problem that a few days of coding can’t solve; a smart team of web/database specialists can build this stuff in under six months, piece of cake.
Now if my clients gave me funding for a team of programmers to work full time for six months, I would be laughing … No I wouldn’t say no, but with the current state of the art in document assembly tools, what my team could accomplish with that funding vs. what the IT group would build, would be quite different. Don’t get me wrong, the IT group would produce a system that would be polished, beautiful objects and data flow, sculpted buttons, drop-dead graphics, the works.
However, the laugh would occur when the “content managers” half-way through the project changed their mind. Everyone knows that law is as much an art as a science. It is a series of balanced judgments and competing interests, and how the balance comes out on any given issue will change over time. Where document assembly tools shine (apart from rapid development tools) is when the “author” changes his/her mind; wants to change phrases in the template, add a new rule in a dialog, remove irrelevant questions (or hide them under new rules); or simply wholesale change the help text because the users keep asking dumb questions that can be best explained in the system.
When I have talked to the web developer about my “requirements” … they say piece of cake. They see fields, dialogs, databases… Basic stuff. Then I tell them, that I want the data structure to expand and contract (at whim). That I want to add conditions and rules to the content of help text on particular variables. That of course, there should be a seemless navigation system that lets me answers questions in a non-linear fashion (but still only show me relevant questions based on the answers I have given to the interview).
Only after have they have invested substantial days in the project will they come sheepishly to admit, this stuff is REAL HARD to do … you are going to have to settle for less. To which I laugh: Why should I settle for less? I can do all of this, without your fancy programming with DealBuilder Server; GhostFill Server or HotDocs Online Server. These systems take the desktop template systems that many of you use, and let you “publish to the web server”. The publication process automatically converts the pages in the case of GhostFill to DHTML, in the case of HotDocs, to Javascript; and in the case of DealBuilder to ASP pages.
So … if you still think programming document assembly forms on the web is easy. Go ahead. For the rest of you, go take a look at these products, see if they work for you. It could save you a lot of money in the long run.