Revisiting Microsoft Forms: InfoPath (and XForms)

In this third part of my series on Microsoft Forms solutions. You can find posts on WebForms here and WinForms here. In this post, I want to look back at InfoPath, and more specifically, the lost opportunity in forgoing the W3C‘s XForms recommendation.

Microsoft introduced InfoPath in 2003 as part of Office 2003. InfoPath became the primary means of exposing forms within SharePoint and could even be hosted in a browser through a SharePoint Form Library. Microsoft discontinued development of InfoPath after the 2013 release in 2015. Power Apps is considered the successor to InfoPath.

As far as forms solutions go, I thought InfoPath was alright. I liked it, and I appreciated the visual aspect to building forms. It seemed to have all that I needed for the forms I needed to build at the time. However, aside from the visual designer, I didn’t understand the benefit to someone that could build forms in web pages with a bit of JavaScript. Indeed, if you did need to code up some additional behavior, InfoPath was little better, as can be seen from this post from Micah Dubinko, author of XForms Essentials.

Had it not been that I discovered XForms first, I likely would have found InfoPath quite a good solution. Unfortunately, I discovered them the other way around. Microsoft’s early efforts on InfoPath referenced and appeared to be an attempt at implementing XForms. If only they had done so! Perhaps we would have been writing windows apps with SVG + XForms rather than XAML all these years. This feels like a missed opportunity.

If you never encountered XForms, then you may wonder why I’m lamenting them. XForms was an XML document specification (not an application specification, a document specification) for laying out forms with a spreadsheet-like reactive dependency graph using a declarative notation. This StackOverflow answer does a nice job of laying out its uniqueness. XForms did not get any major browser implementation due to its being considered too difficult to implement, despite there being numerous plugins available. What this really means is that Google and Apple, who were working on what would become HTML5, decided to stick to the status quo and rely on JavaScript rather than adopting a new standard. Ajax was still relatively new at that point, and most scripting for form interactivity was still pretty minimal.

Back to the missed opportunity. While Google and Apple were pushing “web standards” and taking back ground from Microsoft, Microsoft was still building their own walled gardens of formats. InfoPath was one, and XAML was another. Imagine if, had Microsoft consented to engage with the standards at that time, how we may have seen adoption of better technologies. SVG was rolled into HTML5. Why not XForms?

Although the W3C XForms charter was discontinued in 2015, the community has continued work on it and is currently working on XForms 2.0. They’ve even added ways to interact with datasets in JSON rather than just XML. You can find current XForms implementations in XSLTForms and Orbeon Forms. XSLTForms allows you to render XForms as HTML5 forms using an XSLT stylesheet and provided JavaScript library in an XHTML document. Steven Pemberton’s “A Game in XForms” is a fun demonstration of XForms in use. Orbeon Forms is a solution that appears quite similar to Power Apps but with XForms as its internal engine.

As for Power Apps, I really like the platform, though I don’t love that it is still within the walled garden, this time Dynamics rather than Office. The Power Platform as a whole is a really nice suite of tools, and the Excel-like formulas for hooking up actions feels very similar to the design of XForms. If you are looking for a way to quickly build out forms and even apps, Power Apps is a pretty great solution, though it’ll cost you.

I enjoyed reviewing and remembering these tools. I spent a lot of time in the mid-2000’s working with XForms and ultimately InfoPath before finally getting into .NET at the end of the decade. The only loser here seems to be HTML Forms which remains merely a document layout format requiring another tool, i.e. JavaScript, to make it do anything. I’m surprised modern UI frameworks have never done more with these. Maybe there’s still an opportunity to improve the HTML Forms space for web developers.

Did you ever use any of these tools? Would you like to see improvements in HTML Forms interactions? Leave a comment, and share your thoughts!


One thought on “Revisiting Microsoft Forms: InfoPath (and XForms)

Comments are closed.