Untitled

frank.en.form noun

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.

There’s one thing that all organizations have lots of…and that’s forms.  Forms for employees coming, employees going, customers buying, customers complaining, vendors looking to get paid, and more.  The forms come in all shapes, sizes, and formats.  Some are process-enabled, others not-so-much.  Some are in formats that are not easily digestible into digital formats or converted to another format while others are bound to point solutions where the forms and data behind them are difficult to reclaim/repurpose if that point solution is ever retired or the solution provider goes out of business.  And then you have the web platforms that promise speed, agility, and more…but you still have another solution to support, another solution that needs branding, and another solution that is likely siloed from the rest of your organization.

And this is the challenge we’re helping customers overcome with Vines.  We started with Uniform™.  The idea was essentially to have a universal translator and model that was verbose and flexible enough to describe virtually any form format.  We believe we’ve largely achieved that given the growing range of connectors we currently support…not going to have a roadmap discussion today, but there’s a lot more coming.  Around Uniform we built a robust connector framework which supports the reading/writing of forms and the data behind them.  So we can read an InfoPath form from SharePoint along with the schemas and data associated with any SharePoint list(s) that back the form.  Then turn around and write that out as a K2 SmartForm linked up to the same SharePoint list(s) or somewhere new…a SQL table or tables for example.  We could then write it out as a PowerApps app and even a fillable PDF.

Kind of sounds like a pretty powerful forms conversion/migration tool.  While that is a good starting point, it’s much more.  It also serves as a means of future-proofing your forms development efforts, by preserving your forms in a model that can be re-used to author forms to new platforms as they become available in the marketplace and supported by Vines.  Future versions will surface additional capabilities (…no sneak peeks today) that will further simplify and in some cases remove the challenges associated with managing forms in an enterprise.

We’re also focused on accelerating ideation.  As a starting point we developed a very robust connector for Balsamiq…a leading ideation/mock-up platform.  This is important because while most form technologies have robust authoring tools, they require at least some understanding of form construction.  It would be like a builder asking a home buyer to draw up some blueprints for them with no knowledge of building code and hope they produce something useful.  Now the builder could hand them a piece of paper and pencil and say draw it for me, hand that to an architect who does understand building code, and have them transform it into something the builder can use to build the house.  Along those lines, you can hand Balsamiq to a non-technical user (…what do we call them today, Citizen Developers?), let them “draw” the form, then flip over to Vines read it in, and write it out to your target.  Imagine taking what amounts to a drawing from a business user and being able to show them a working form wired up to data objects in a few clicks.

So what did we learn today?  Organizations have forms.  Managing those forms can be expensive and problematic.  We’re delivering a solution that can help.

Take a 4-letter word and add ulator: A recipe for success?

10 years ago I was the CTO at Bluethread Technologies, the folks behind StoragePoint. While I don’t remember the exact date, we launched StoragePoint at the SPTechCon in Boston in July 2009. That launch was accompanied by a tool I coined the BLOBulator. It was just a windows app that scanned your farm, analyzed content databases, and told you how much smaller they would be if you externalized the BLOBs. It was a huge hit. People loved it, it gave them numbers they couldn’t believe, and challenged them to try the software to validate them. And validate them they did!

Fast forward 10 years and I’m working with a new group of folks on an Enterprise Forms Management solution that among other things can convert a whole bunch of source form types, including InfoPath, to K2 SmartForms, PowerApps (prototype), and other target formats. We’ve honestly been a little challenged getting it in the hands of folks that could benefit from it without creating a pre-sales support nightmare. We’ve had partners and some customers just flood us with forms and asking us to convert them and send back the output…or just even a screenshot.

So, I thought to myself, can we just take a scaled-back version of Vines and publish it as a quick and easy way for someone to upload a file and see a preview of what it would look like in our Uniform™ model. It would also be great if it presented some findings and scored the form based on well-defined criteria for success…in other words will it work for me.

With that, my team set forth on building the FORMulator. Yes, I went there, but you probably figured that out already given the lead-in. I figured it worked extremely well once, so why not try it again. Besides, the FORMulator is A LOT prettier and does a lot more.

There’s no sign-up or giving us a bunch of information here. Try it, as many times as you want, and if you believe the results will benefit your organization then reach out to us…helpful links provided with the results.

We also encourage you to share it within your network…we made that easy too.

And to be clear, it will tell you if your baby is ugly, so be prepared for that. We just don’t see much point in giving you some sugarcoated response that encourages you to try the product and then have you disappointed with the actual result. You’re going to have forms that it handles very well and you’re going to want to get your hands on the product as soon as you can. Other forms, not so much, and you’re going to click that Try Another Form to see if that form was an outlier or not. I’m betting that you’re going to see enough value to reach out to us…the same bet I made with the BLOBulator and StoragePoint a decade ago.