Some people are seeing the “death” of InfoPath as if the sky were falling. Calmer heads aren’t overreacting, but they’re nevertheless starting to look for a replacement. Before going too far down that path, I’d urge careful thought, because I don’t think anyone should be looking for “a” replacement.
“Forms” means different things to different people. I can think of four:
- Structured Documents – There is information to collect and each piece of it must be identified. The form’s contents need to be a permanent document that can be copied/moved/archived/signed, but we want to be able to parse the contents and do things with them.
- Data UI – There is data living in a database table/SharePoint list, etc., and we want to be able to get at each row/item in an attractive, understandable, easy-to-view-and-edit way. The form is basically a nice viewport into the data — the data is the important part.
- Solution UI – There’s an overall app that’s the star of the show. It could be a custom solution, a workflow process, a CRM environment, or really anything. They key is that we need to show the user some things and ask them for other things, and the data could come from and go to just about anywhere. And there are likely to be a lot of these forms that work with both each other and with other application assets.
- Standalone Applications – We have a form that’s a document and a solution in and of itself. It stores some data, fetches/sends other data from/to other places, has its own code, or at least its own macros/rules.
Now let’s look at InfoPath with the above in mind…
It was originally conceived as a way of doing Structured Documents from a desktop smart client. Along the way to version 1.0, the team added the Standalone Applications scenario, because at the time — the Office 2003 era — Microsoft’s Office division viewed the world from a client-centric point of view.
By 2007, you could use InfoPath for Solution UI if that solution was a code-based workflow, and in 2010, it worked even in declarative workflows (e.g, SharePoint Designer, Nintex Workflow). 2010 also introduced InfoPath support for Data UI — if that data source was a SharePoint list.
In other words, it tried to be all things to all people. How often does that go well? Let’s see…
- Using InfoPath for Solution UI isn’t a bad idea in theory, but there’s nothing in InfoPath’s designer that knows about the rest of the solution (workflow context, for example, which is one of many reasons Nintex developed Nintex Forms). In addition, those UI assets need to be developed completely independently of the rest of the solution. If you make a change to the data, the workflow logic, the authorization model, etc., you have to make sure the forms are independently updated accordingly. If code is required, it gets even nastier. It’s no wonder that as early as last year the Office team blog was suggesting a look at Access.
- That led a number of InfoPath people to conclude that the best course of action was to move to the Standalone Application model, throw away “workflow”, and put all of the logic in the form. That’s a problem – a big problem. For decades now, we’ve been taught that solutions should be broken up into a presentation tier, a logic tier, and a data integration tier. Who thinks cramming process logic and data access into the UI is a good idea? Hopefully no one. Even if you did, how easy to follow was an InfoPath form with a lot of views, field rules, form rules, and embedded code?
- As for the Data UI use case, InfoPath does a fine job of this if you have SharePoint Enterprise Client Access Licenses so you can use InfoPath Form Services. But I hope that’s not the only reason you have Enterprise CALs, because a number of companies have or will disrupt that. Nintex Forms disrupts that, albeit not deliberately. Heck, even CodePlex projects like Forms7 disrupt the Data UI use case.
- Actually, InfoPath is an excellent structured document product. Then again, that was before all Office documents became XML documents in 2007.
So if not InfoPath, what? There is no one replacement. There are three. Use the right tool for the right use case:
- You want app-coupled forms? Get a product that’s tightly coupled to workflow solutions. I obviously have a favorite, but this blog is not a promotional vehicle for Nintex; suffice to say that decent workflow companies offer you form options — look at them. Your app isn’t about workflow? Consider Visual Studio. Visual Studio LightSwitch, Access, etc.
- You want structured documents? Every Word and Excel file can be a structured document. So can PDF files.
- Data UI? There are a lot of options for that, too. Pick one you like. Again, I obviously have one I like, but your preferences may and will vary.
Yes, I know I mentioned four use cases at the beginning of this post, but I really hope you’ll abandon Standalone Application forms — those are just nuts.