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. 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, 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 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 Kudzu and the Rules gauge is orange or red.
- Deeply nested repeating sections/tables. While Kudzu 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 Kudzu 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 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.