OneSet was a short experiment based on utilising the obvious advantages of using e-form automation and a centralised database of (legal) client details to expedite the laborious chore of completing Family Court forms.
The Family Court, like most Courts for that matter, require litigants to file a litany of separate forms and other documents at various stages of litigation. Whether litigant or lawyer, you quickly realise that 70-80% of the fields in said forms are asking you for the same information… for the 10th time.
Though one can understand why certain pleadings need to be ‘stand alone’ and include all details pertaining to the party and case filing it in isolation to other documents/forms already filed, it would be nice if the answers to questions/fields already submitted to the Court were pre-filled when drafting subsequent documents.
OneSet, then, was predicated on the notion that a client would provide ‘one set’ of details… once… and thereafter 90% of their Family Court Forms and pleadings could be automatically rendered from that database of detail. The details contained in a Form 11 (Application for Consent Orders), for example, a common but very detailed form, could be used to complete more than 76% of the fields in 15 of the Family Court’s other most popular/common forms. Although some forms may require supplementary details and, of course, the moving-feat that are pleadings, would have to be updated, the majority of the laborious and time-consuming aspect of most forms could be ‘pre-filled’.
Not sure of the eventual platform or interface, I initially kicked things off using a WordPress/PHP/MySQL setup. Later, using Electron, OneSet had a short life as a cross-platform PC executable. MySQL was, in retrospect, probably overkill and understandably a little slow for what I was trying to achieve, particularly when running in a non-local environment. If I had my time again, I would probably try a similar setup with a No-SQL database system, perhaps MongoDB, I’ve heard good things.
Form validation was interesting. Usually the huge range of good (and bad) JQuery/Bootstrap plugins out there will do the job and for the simple stuff and Smoke did just that. However, it was not long before I realised that getting the most out of the ‘concept’ of turbo-charging form completion with pre-filling/auto-calculations and the like was a bit beyond those plugins. No fault of the plugins I tried, of course. Validating the input of Western Australian legal details in the context of Family Court litigation is obviously kind of specific.
So, after completing the 20th custom validation function in VanillaJS and still finding myself on page 1 of the Form 11, I resigned myself to that fate and ditched Smoke in favour of custom JS. I was asking too much of a one-size-fits-all solution. The results were good, however, despite progress being more than a little slower than anticipated.
Once the details were in the DB, I had to get them out into the Forms. For this I used a combination of DBtoCSV and Poi-Mail-Merge. Hacky, yes I know, but OneSet was (and remained) an experiment and those worked for me well enough and coding some bash was a nice break from the non-stop JS and PHP the front-end was subjecting me to.
As I mentioned above, I then transplanted some of the functionality of OneSet into an Electron project that ran quite nicely as a native PC application. Of course, this was an ‘after-thought’ and not a well-planned endeavour given OneSet was built around PHP and a relationship database, neither of which were easy to translate to a pure JS implementation.
Although (local) client management software like FilePro and LEAP do mail-merge forms/precedents and do them quite well, the level of complexity (and hence utility to the user) is understandably limited. You could (and I did) spend literally months on a few pages of a common Court form thinking of the ways you could shave a few seconds off the end-user’s input time. If the ComCourt Portal rolled out an API (or the Tax Office or… someone *cough*) and we didn’t have to rely on client instructions for some of the asset/liability side of property settlements… well, you could do incredible things, frankly. But that is a pipe dream at this point.
A free, open-source and farr better executed version of OneSet integrated with ComCourts and constantly maintained would be of immense utility to both the Courts and litigants but, I suspect, might be less than warmly welcomed by Solicitors/Firms for obvious reasons.
As I have not yet had a chance to scour the code and remove all sensitive info, the OneSet code has not yet been uploaded. It will be, however and shortly. If anyone is desperate in the meantime, please do not hesitate to contact me (various options in the top-bar above).