The Ugly Truth About FrankenformsĀ
an electronic form that has been over-engineered to the point where it is largely unusable and/or impossible to maintain.
an electronic form that makes use of platform features and/or functionality in ways they were never intended to be used.
an electronic form built without the ājust because I can doesnāt mean I shouldā sanity check that a trained and experienced IT professional possesses.
Iāve used the term once or twice (ā¦ok, probably more) to describe this type of form, specifically a class of InfoPath forms, that we would likely never be able to convert/transform with Kudzu Vines. Ā Of course, the Sales & Marketing folks picked it up and ran with it. Ā As part of that, they tasked me with writing this blog post so theyād have something to reference whenever a partner or customer sends us their worst āFrankenformsā for conversion.
And just to be clear, for every Frankenform we see, there are dozens more that are ideal candidates for conversion with Kudzu Vines, along with just about every PDF (ā¦blog post coming on this soon) and an increasing number of other source form types.Ā Ā
Itās also important to note that, despite the best intentions, these Frankenforms are often born out of citizen development efforts. Typically, an experienced IT professional would not construct something so complex as to make it difficult to maintain, migrate, and transform in the futureā¦i.e. āfuture-proofingā. Ā And just to be clear, this isnāt a problem with citizen developers per se. Ā Itās a problem with the tools and platforms we make available to them and how they are marketed, and/or positioned to corporate IT shops. Ā You hand these citizen devs the keys to SharePoint, Access, InfoPath, and now PowerApps (ā¦all tools/platforms where you can do harm) and are surprised when poorly constructed, difficult to support, and a burden to maintain solutions are suddenly employed in the management of mission-critical business processes.
An example of this was a particularly nasty InfoPath form we received in the last month or so. Ā It was a deeply-nested (sections within sections within repeating sections) form that had hundreds of rules that would show or hide sections and fields based on radio button selects or checkbox clicks. Ā It had hundreds of data fields, lookups to dozens of different SharePoint lists, and more. Ā It was either a nightmare or a work of art depending on your perspective. Ā Iām reasonably confident it wasnāt built by IT because (the creativity employed to construct it and the use of InfoPathās full breadth of capabilities aside) it would be seen as poorly constructed by any experienced IT professional. Ā And unfortunately, thatās a root problem that often has to be managed with citizen development. Ā It puts a great deal of responsibility on the author to understand the construction principals of the tooling/platform they are using, or the tooling has to make it so they donāt need to careā¦the latter being no small task because you ultimately have to give up capability and/or speed in order to deliver simplicity.
Back to my favorite (so far) Frankenformā¦
After I take time to process what Iām looking at, understand how it works, and get around the SharePoint warnings (because youāre not running it in the partner/customer environment), I realize that the builder of this form essentially created a fully-functional instance of ServiceNow (Now? now? NOW? ā¦personally liked the last oneā¦shouted it in my head whenever I saw it) all wrapped up in a single view InfoPath form. And Iām not really exaggerating that too muchā¦it was a full-blown service request application with flow, state and even some basic process management logic built into it. I envisioned them clicking that Preview button on the toolbar, the lights in the room dimming, maybe a popping circuit or two, and the developer (ā¦again, with all due respect, probably a Citizen) proclaiming āitās alive!ā when it finally loads.
And while forms like this can live and function in the environment theyāre built in, theyāre probably going to die there too. Thereās simply no good way to take a form that āheavyā and move it via an automated process to another platformā¦and frankly, you shouldnāt try to. The reality is, this is the type of form you will want to break up (refactor) into smaller, UX-specific units and then wrap it in a workflow to show those discreet user experiences at different points in the process.
In closing, you probably have a Frankenform ifā¦
It relies heavily on scripting or code-behind to create an interactive (dynamic) user experience. Ā Put another way, you customized what the platform and/or tooling provided out-of-the-box. Ā Kudzu Vines simply makes no attempt to interpret customizationsā¦and likely never will.
It makes heavy use of rule and/or function types that are not supported on the target forms platform. Ā This may or may not be an area of concern depending on the type. Ā Youāll know if you read the form into Vines and the Rules gauge is orange or red.
Deeply nested repeating sections/tables. While Vines can recognize and record them in our Uniform model, most target formats donāt natively support them. Ā As a result, that capability can be lost or at least limited. Ā There are cases where Vines can synthesize this capability on the target. Ā K2 SmartForms and PowerApps are good examples of this.
It has a large number of non-repeating sectionsā¦letās say more than a couple dozen. While this is not an absolute indicator that you have a Frankenform, itās usually a good one. Ā Itās indicative of a form that has probably been over-engineered. Ā You will probably find lots of rules to show or hide those sections.
It has 100ās of fields. Can Kudzu Vines read and record all those fields in Uniform? Ā YES! Ā Does it hurt us to do so? Ā YES! Ā Why? Ā Because the form likely ignores the best practices associated with building a quality user experience. Ā Itās probably time for a refactor.
And finally, it uses more than 5 colors. OK, thatās a jokeā¦6 is actually fine.
