Hi Pavel,
Thanks for the response. Here’s what I can give you right now.
Background: my client is a consulting agency which is engaged by its customers to assess aspects of the customers’ IT infrastructure. Currently, the work product of my client is a customized report, delivered both in formal, printed form and as a PDF document. My clients offers a small number of related services, each of which is associated with a defined report.format. Currently, my client builds these reports in Word following what is essentially a manual process, using pre-existing blocks of boilerplate content, Here are some examples of what happens.
Example 1: there is a pre-existing template file containing textual descriptions of each of the possible findings, maybe one paragraph per possible finding. The report building process involves creating a new document from the template, and editing it so that the new document contains only the findings actually encountered in the assessment,
Example 2: there is a pre-existing template file containing explanatory text, and placeholders for formatted content sourced from an external file, which might be XML, or a spreadsheet, or something else. The report building process involves creating a new document from the template, and inserting the formatted external content at the appropriate place in the document.
This report building process is time-consuming and error-prone, and the overall goals of my project are to improve the user experience for both the report creator (my client) and the report consumer (my client’s customer) in basically two ways.
The first way is to allow the report creation to be provided by a web application, If possible, we would like to use an extensible document assembly tool to help in the creation of the customized report from the pre-existing templates. If this turns out not to be feasible from a functionality or cost perspective, we will build appropriate support ourselves.
The second way is to allow the created report to be deployed in a web application, for consumption by the end-user (my client’s customer). This would be in addition to the existing deployment mode, as a PDF document. The report content would be enhanced with controls permitting user interaction with the report. Looking at Example 1 above, each of the paragraphs describing a finding might be associated with a checkbox control labelled “Remediated”, which the customer would click to indicate that they had fixed the problem called out in the paragraph. There might be a file upload control, allowing the customer to upload a file of additional diagnostics.
The result is that we have a report which can be presented in two ways - as a PDF document and, with additional interaction features, as an HTML5 web page.
We are expecting to build the web application using Kentico 8.1. The application and its document repository will be hosted in Azure.
The canonical high-level use cases are something like this: Obviously there any many others.
Assume that there are two Actors - Creator and Consumer.
- Creator navigates to application and chooses :“Create New Report”.
- Application prompts user to choose one of the available report types
- Creator chooses a report type and clicks "Create"
- Application opens template associated with report type and presents it to Creator in a form which permits Creator to make the appropriate customizations (Note: the full set of supported customizations is not yet known. See later)
- Creator edits document following customization options in template
- Creator chooses Publish to Web (Save, Publish to PDF and Preview are optional choices)
- Application generates HTML5 report with custom content and additional user interaction controls
- Consumer receives notification e-mail indicating that report is available, with an embedded link the the report.
- Consumer clicks link and is directed to the published report.
- Consumer interacts with the report using the supplied controls
As I mentioned, the full set of required customizations is not yet known. At least these will be required - there will be more. Some of these are not appropriate for the Document Assembly tool, and we’ll have to build them in the application.
- Enter custom text
- Mark optional content as Included/Not Included
- Include formatted content from external XML file
- Include formatted content from external spreadsheet file
- Define controls to be a
We know that, if we use a Document Assembly tool, it will be critically important that the tool is extensible, so that we can write code to integrate it with our application and integrate it with the external content we’ll need to pull in. So a robust API will be important.
I hope this gives you an idea of what we’re trying to accomplish.
Peter Hornby