There is a lot to be said on the subject of best practices, and there is absolutely no “one right perfect way” of doing things. This article is intended to give some ideas as you start on your XpressDox journey.
It is most likely not going to be the case that you will be authoring standalone templates which don’t interact with other templates or with databases or other external (meaning external to XpressDox) systems e.g. a DMS or PMS. And as soon as these other interactions are introduced, you are beginning to move from authoring templates to creating systems or applications.
Once you start authoring applications, you have made a quantum leap forward and away from what is really just simple “mail merge”. This article tries to give you some hints and advice on how to go about developing a document-centric application using XpressDox.
Before you begin your planning
Get to know XpressDox a little bit. Test some scenarios, go through the Getting Started section in this Learning Center, click on the “Help” buttons on the commands in the Command Assistant. The Getting Started section on the Learning Center has been structured to take you on a user journey. It is important to note that the Question command is aimed very much at Low Code users, and as soon as you start to build out a system like this, where you would like to re-use code, the Question command becomes very limiting. It becomes easier to insert simple fillpoints and keep Captions, Help and ChooseFromList/RDBList commands inside a code template that can be re-used.
When you are ready to start
Step 1: Consider your implementation
Desktop / Web. And if Desktop, how many Authors / Runners. Are you giving XpressDox Desktop to the entire firm or just a few users? If Web, are you going self-hosted Cloud, or using the XpressDox SaaS Cloud server? Do you want to login with SSO? Remember that all authoring must be in the Desktop version so if you are not outsourcing your template authoring, then at least one person but preferably a precedent team, would require Desktop licenses.
Step 2: Configuration
The configuration is a big topic, but the good news is that any settings you create now can always be changed. Configure your data sources and helper folders specifically. Data sources so that you can integrate with databases, and helper folders so that it will be easy to include templates.
Step 3: Decide on a naming convention for your data elements
There are quite a few chicken-and-egg situations involved here. The names of the data elements might be dictated to you if you are integrating with databases e.g. Aderant or internal personnel databases. Perhaps you are converting from an existing program in which case you will also already have a list of data element names. Or perhaps you are starting a system from scratch. Whichever way you are approaching your project, you can’t really start on a document without deciding on a naming convention for your data elements. It’s important to stick to naming conventions for consistency in your project. This article contains some advice around naming conventions.
Step 4: Create a folder structure
Your template folder structure should have a Development and Live area. Keep a Dev area for testing and move to Live when the templates are ready for production. Each of those folders should contain folders for each practice group. Create folders for Clauses, for Code Templates and Included Templates. Create another folder for your letterheads. This structure is a suggested one, and as you are designing you will understand your requirements and make adjustments. But this is a good place to start. All template authoring will be in Word, but your deployment to users might be on the cloud. It makes sense that as you upload templates you keep an identical folder structure in both environments.
Step 5: Identify the most often used documents in your firm and start there
For the biggest return on investment after purchasing a document automation software, you want quick wins. Identify the most popular templates in your firm as the first phase of your project.
Step 6: Setup your integrations (DMS)
Will you be integrating into iManage, NetDocuments or Azure, SharePoint? Although it is good to consider this up front you can always start creating, and then setup your Foreign File System later. Consider the profiling of documents if you will be integrating into iManage or NetDocuments. There is reading material on each of these subjects. Or you can implement this part a bit later if you would prefer.
Step 6: Template design
Template design looks different to different people. It may look like a conversion from another program. It may look like an entirely new set of templates (documents which have never been templates before). It may look like an opportunity to ‘clean up’ the template library and take the number of templates from > 1000 to < 300. There are always a few things to bear in mind though:
Code and test the document in small chunks.
Resist the temptation to author an entire template without testing it. Especially in advanced situations where you have complicated logic in the template – e.g. nested If commands or Select commands, or complex handling of plurals and wording when there are repeaters.
Rather code up to the end of the first bit of complexity, and test the document, making sure that everything you have coded works, under all the various circumstances (combinations of values which affect the conditional logic or number of specific repeaters). Then continue coding up to the next complex part and test again, and so on.
In some situations it will make sense to create a “snippet” template which contains only one of the particularly complex parts and test that on its own. You may end up with lots of useful snippet templates.
Focus first on the document
The first thing to do is makes sure that the document that is going to be the end product is correctly formatted and worded.
- This includes coding the correct fillpoints and deciding on the names and source of data elements (by “source” is meant whether data are to be typed into the interview by the user or included from a data source, or both).
- Make sure that the document logic is correct – i.e. that the conditional inclusion of words, phrases and paragraphs is in order.
- Assign a useful set of Word styles to the document (this is a huge subject on its own and is not covered here, but that doesn’t mean it is unimportant).
Design the interview.
Using Manage Interview will get you a lot of the way there. But there might be some cases where you will still need the next article.
This topic requires an article all on its own, and so is covered in Implementing XpressDox: Best practices (Part 2).
There is a case for designing the interview before coding up the document(s). Some authors prefer to take that approach because the user (template runner) will interact directly with the interview, and only indirectly with the template and merged document. The reason for suggesting the sequence as “document first, then the interview”, is that the interview is created by XpressDox using the commands/fillpoints in the template as a guideline. In particular, the interview relevance is determined in this way, as well as the sequence of appearance of data elements on the interview. This means that you are going to get an interview created in any case, so if you create the document first with all its document-formatting fillpoints, then interview design becomes an exercise in guiding XpressDox to do it differently, rather than trying to get the interview created in a vacuum.
