This week, we concentrated on improving the creation and output of reports for risk assessment software.
These reports tend to be 60 or more pages long (the PAS 79 2016 report, for example), and so can normally take hours of tedious work for the engineer to fill out. By using FieldMotion, you cut that down to just the click of a button.
We overcame two difficulties this week – the first is that some service management software reports may require a mixture of landscape and portrait pages, and the second is that there can be a lot of repeated sections in reports, where the details may change, but the layout stays the same (header, title, questions, etc).
We already were able to provide mixed landscape/portrait pages when creating reports in PDF format, because the way we created those pages was more like painting than writing – each element on every page was precisely formatted and positioned. But with the newer risk-assessment type forms, we needed a more flexible format, so created a method of report-generation that produces Word-style documents, which are flexible and can be as long as they need to be.
The problem with generating Word-style documents (could be OpenOffice, Word, WPS, or any other similar format), is that they’re not really designed to be created by a server, so we need to generate them in HTML format, and then convert to Word by using third-party conversion software, such as libreoffice, phpdocx, and other conversion methods. There is always a loss in the translation.
In a way, it’s like trying to write a book in German by first writing it in French and then using an online translator such as Google Translate to convert from the French to the German. There will always be a loss in either meaning or nuance.
This week, we found a way of improving the existing Word document conversions so that they retained our instructions to switch to Landscape or Portrait at specific points.
The next big breakthrough this week was in how we are now able to easily create large repeatable sections in custom-formatted ways, in a way that’s much easier for our end users than the previous method we had.
It’s hard to describe in text when I mean by this, but I’ll do my best.
In risk assessment reports, there will be parts of the report where you must itemise each risk, such as fire hazards, doors, combustibles, gas canisters, and must provide some information about each of these, including how the company mitigates risk for them, any expiry dates, etc.
The same is true of other similar industries, such as pest control, where there will be bait boxes inspected, etc., and reports drawn up about them.
This kind of item investigation is predictable – you know that if you have ten fire extinguishers, then there will be ten sections in the report which look similar.
Before this week, we had no way of providing an easy way to enter this into the risk assessment or pest control software such that there could be an arbitrary number of items investigated and reported. Field management software is filled out on mobile devices, which by their nature do not have keyboards or other methods of easy mass-data-input, so anything we could do to improve this was needed.
This week, we came up with a method of drawing up a layout of how the data should be shown, and then telling the report “output the data using that format”, applying the rule to specific tables filled in on the app.
This allows us to have arbitrarily large numbers of items entered into the form and printed to the report in an easily-formatted way.
It was a good week for our workflow management system – two big advances that reduce the work needed by both the end-user, and by the implementation team that generates the report templates