What a developer wants in a post-InfoPath world

Posted Friday, January 31, 2014 1:01 PM by CoreyRoth

As a developer, I have to admit I have always had a love / hate relationship with InfoPath.  It worked well for some things but once you reached that point where you needed more, you had to scrap your entire solution and start over with something else.  Although I haven’t built solutions with InfoPath in quite some time, back in the da,y I did a number of projects that involved them from a workflow perspective.  Thinking back to the 2007 era as a power user, InfoPath was fairly straight forward to integrate when it comes to workflow.  However, as a developer, if you wanted to use InfoPath for a workflow association or initiation form, the process was quite involved (and well painful).  You had to create that XML file manually to map your fields, wire up a bunch of code to handle correlation tokens, and all of that fun stuff.  I can’t say I miss that at all.

For the last few yeas, we have been dancing around the future of forms.  It was apparent there was nothing new with InfoPath 2013, but the direction just wasn’t known.  Even now, we still don’t know yet, but Microsoft has told us something new is coming.  I am looking forward to a future where forms meet the needs of business users across multiple products.  Since Microsoft has announced the EOL of InfoPath, I’m excited to see what the future of forms will be.  Although the use of forms has always been centered around the use cases of the business user (as it should be), we developers have been able to make use of them too.  I am hopeful as a developer, that we get a solution that meets some of our needs too.

I have no idea what is coming, but from the development perspective, I hope whatever comes out of forms technology in the future meets the following requirements from a developer’s perspective:

  • The more end users can do the better – ideally, a developer never has to touch a form.  End users should be able to create rules, enable conditional formatting, and change the look and feel within reason.
  • Forms should be portable – if you build a form on one site or web application, you should be able to move it to another.  Lists should be referenced by name or relative URL as opposed to GUID.
  • Mobility is key – A user should be able to complete a form regardless of the device they are using.  Forms should automatically employ RWD patterns similar to Cloud Business Applications to render the form appropriately on mobile devices. If the forms worked offline, that would be a huge value-add.
  • Forms should be extensible – Code could be added to InfoPath forms, but that made deployment complicated.  Ideally, forms could be extensible using the Cloud Application Model (CAM).
  • Workflow is required – Access 2013 provides a lot of value in the forms world but you can’t associate anything there with a workflow.  It’s rare that a business user makes a form that doesn’t have some business process represented by a workflow associated with it.
  • Full support of managed metadata – The InfoPath story with managed metadata has never been complete.  Whatever the form solution ends up being, we should be able to bind form fields to managed metadata fields.
  • Good story with external data – the forms solution should integrate well with external data coming from Business Connectivity Services as well as REST data sources.
  • Support for cascading drop-downs – the new forms solution should allow for cascading drop-down lists.  This has always been a challenge with InfoPath
  • Painless transition to developers – when an end user reaches the point that they need a developer to assist with a form.  The developer should pick up where the end user left off without starting over.  Ideally, this means developers can deploy these same forms with the app model using Visual Studio.

I’m quite excited about what’s in store for forms with SharePoint.  Meeting the business user’s needs will always come first, but I hope that some of these things will are on the radar from a development perspective.  I am sure we will here more of what is in store at #SPC14.  If you are going, be sure and attend the session SharePoint Forms Roadmap (#SPC348).  It is sure to be a packed one so you best arrive early.

Ok, so I know I can’t speak for all developers.  What do you want in the next forms solution?  Leave a comment!

Comments

# re: What a developer wants in a post-InfoPath world

Friday, January 31, 2014 12:35 PM by Sumit

LightSwitch should fit the bill nicely, specially since it has gone HTML5 (instead of SL)!

Integrating with the Forms based SharePoint might be a minor hassle, but hey, LightSwitch is right there, why build anything else from scratch again, after all this is the new 'unified Microsoft' right?

# Microsoft confirm InfoPath 2013 is last release of the product | Jeremy Thake's musings

Pingback from  Microsoft confirm InfoPath 2013 is last release of the product | Jeremy Thake's musings

# re: What a developer wants in a post-InfoPath world

Saturday, February 8, 2014 10:15 PM by Troy Mann

I want the next forms solution to work with oData at least.  Also it should have support for JavaScript for developers with some kind of standard control drag and drop for business users.

Leave a Comment

(required) 
(required) 
(optional)
(required)