The InfoPath Conundrum

InfoPathFormsQuoOnce upon a time, when InfoPath was the “new kid on the block”, you could almost taste the excitement in the air.  “Workflow” was the hot topic, and the industry was abuzz with possibilities.  The whole idea of managed content lifecycles and controlled information pathways through an enterprise really captured the imagination and suggested a fundamental shift in the way we deal with information.

I must admit I was hooked on the fundamental architecture of the InfoPath form designer.  The notion that one could define a detailed schema that prescribed the precise rules that govern a given set of data elements was truly compelling.  Using this approach, one could then wrap the schema with a design layer that could capture the rules governing how users would ultimately provide that data.  You could then take it a step further and wrap that with an abstract processing layer (i.e. SharePoint) that would govern how the data would be used.  Wrap it again with a server-side presentation layer (i.e. SharePoint) that would govern how users provide the data through a browser.  Wrap it yet again with a storage layer (i.e. SharePoint) that would govern how the data should be stored, and again with a security layer (i.e. SharePoint) that would govern who could access the data, and so on.

The point is there are many “paths” that information follows as it flows through the real world, and there are equally as many layers of technology that must be applied to the core set of data elements defined in the schema before we finally arrive at a reliable (more importantly, manageable) set of components we can actually work with.  But the basic concept is still viable.  Define the schema, and then use it to capture, distribute and process information.

So, are we still talking about “forms”?  After all, we must still deal with data capture, data storage, data presentation and data processing in order to build real systems.  But the technologies involved within each stage are constantly evolving.  They are changing so fast, in fact, that even Microsoft couldn’t respond quickly enough to meet the challenge.  Hence the demise of InfoPath.

So what does this mean for the whole “Forms Services” paradigm?  Now that Microsoft is officially deprecating InfoPath forms in Office 365 (see the Update on InfoPath and SharePoint Forms), what will the “information pathway” look like in the not-too-distant future?  Will we have to revert back to Web forms?  Probably stuck with them for quite a while.  What about Access Web Apps?  Interesting, but no workflows, and issues with publishing and security.  Excel surveys?  Limited functionality.  FoSL (Forms on SharePoint Lists)?  Platform specific.  Structured Documents?   Same.  Cloud-hosted forms processing?   Is there still a need for a standardized form designer application at all?  I’m still a huge fan of schematized XML for building solutions.  I like the idea of focusing on the underlying data structure and then letting the tool generate the scaffolding needed to capture the data and move it through the workflow.  Wait.  There’s that word again – “workflow”.

So why did InfoPath fail?  The answer lies in the basic reality that inspired the product name in the first place.  Information flows through an organization and follows different paths, depending on how that information is processed and consumed.  The problem is that there is an ever-increasing number of ways to capture, process and store information.  And it’s not just about form-factors.  It’s about people and processes.  It’s about reporting and BI and content generation and security.  In short – it’s about nearly everything we do.snowballstuck

I like the approach that Nintex, formotus, FormsQuo and other vendors are taking with their centralized, cross-platform forms engines.  But we’re still waiting to see what direction Microsoft takes with Azure and Office 365.  Ultimately, we’re going to need a new paradigm.  One where the data capture mechanism (i.e. the “form”) is synthesized automatically from the context in which the data is produced and consumed, and the data already captured.

Imagine a snowball picking up people and data and metadata and content as it gathers momentum on its relentless trek through your company.  Like that, every packet of information we encounter as we work through our inbox starts out small and then acquires more and more detail and significance as it moves from one context to the next, igniting various processes along the way.

Maybe the future isn’t about forms at all.  Maybe its all about function.

My 2 cents.

7 comments

  1. good stuff John and you are on money about the future its all about the functionality. I’ve heard of even simplicity of word forms with Azure integration to FoSL. We’ll see @lmundia

  2. Great, thoughtful piece John. One of the raps against InfoPath is that it became too broadly used for too many things. Because it could do so much, it was made to do too much. I recently saw this termed DGWHID solutions (Dear God What Have I Done?). The whole forms services and browser forms thing in 2007 may have been the fatal mistake.

    Appreciate your positive mention of Formotus. With regard to your metaphor of the growing snowball, think of Formotus as the the tool for forming that initial tightly packed ball of data/snow that gets the whole process rolling. Our forms shine at capturing rich fresh data out in the field and delivering it to the top of the enterprise hill to begin the journey of growth you describe.

    Glen

    1. Agree totally, Glen. Forms Services (Admin Form Templates, etc) was way to complicated to gain any traction. Couple that with the fact that the InfoPath team never seemed fully integrated into the SharePoint product cycle, and you have a pretty effective recipe for disaster, market forces aside.

  3. I really embraced InfoPath in SP2007, 2010 and 2013. I have built many great solutions and became quite knowledgeable with the product. My users embraced it too and asked for more which I was able to deliver rather quickly using this tool. I’m disapointed that I will eventually have to forget this knowledge and move on but, that is the life of a developer isn’t it?

    Bismarck

    1. @Bismarck, I feel your pain. Although there is some attention being given to converting legacy InfoPath forms to newer technologies, the problem (as Glen pointed out) is that IP tried to do too much. Similar to migrating heavily customized SharePoint solutions to a different farm, they consume too much time and effort. My approach is to extract the XSD and start simple, refactoring as much as I can along the way.

  4. It’s also worth looking at K2 Smartforms – they have a new offering called Appit – cloud based offering that is very affordable that has very strong forms, data, workflow and reporting capabilities.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.