Ever since the release of Office 2013 there has been speculation about the future of the information worker toolset, specifically InfoPath and SharePoint Designer. In SharePoint 2010, the go-to tools for information workers trying to build solutions within SharePoint were the browser, Office Applications, SharePoint Designer and InfoPath. Using a combination of these tools we could easily create no code solutions that allowed us to help impact the use of technology within the organization.
Today, some big news from Microsoft clearly states its position on the future of InfoPath. Lets look at some answers to many of the questions we have had about the future of InfoPath in the last year and how we should be using it now.
Clear Direction (Maybe …)
Microsoft's blog post made it clear that there will be no future releases of InfoPath. InfoPath 2013 will be the final release of the forms application. This does not mean that Microsoft is abandoning the idea of forms, it just means that going forward a different set of tools will be made available. At this time there is no clear direction on what the toolset will be exactly. The only thing we know for sure is that something new is coming.
The blog promises that our first glimpse will come during the Microsoft SharePoint Conference later this spring. The idea is that there will be a single way for people to customize forms that applies to SharePoint, Access and Word. This type of technology would allow for users to have one forms solution across all Office applications. The idea of this cross-application type solution fits the overall direction of things coming out of Microsoft lately and aligns well with the idea of having one toolset that allows you to do multiple things.
While We Wait
So now the big question -- what do we do in the meantime?
While we wait for Microsoft to release their newest set of Forms tools what do we use to address our current needs? The blog post answers this question very specifically and encourages you to keep using InfoPath. While I agree with this idea, I would caution you to tread wisely and use InfoPath when it makes sense, but in all of your planning remember that InfoPath will go away and be replaced with another tool.
It would be wise to evaluate each form on a case by case basis and determine the best path for that solution. There is a danger in building too much within a retired product, but there is also an equal danger of building something custom when you could have easily used InfoPath. The real trick is finding the balancing line and using the right tool at the right time for the right thing.
Below are some basic guidelines to adapt for your decision making process as you determine the right tool to use as we wait for the newest release:
How often will this be reused?
If I am building a solution that will need to be used over and over within the organization then I am most likely going to look at a tool other than InfoPath. Knowing that the tool has reached end of life, I wouldn’t want to knowingly put a form in multiple places that would require additional work for the next upgrade. In this scenario I would look for ways to reduce the places the form needed to be deployed or I would look into other options such as third party tools or custom development.
What is the life expectancy of this solution?
If I am building a solution that has a limited lifespan then I would be more willing to use InfoPath. For instance, if I wanted to create a form that allows for signups for a specific event or a training then I could use InfoPath to build the solution because I know it wouldn't be a concern for future migration. This would allow me to follow the MS guidance of continuing to use InfoPath, but still applying some timelines to the decision process to ensure that I am making the best long term decisions.
How long will it take to recreate this solution?
This is a big one for me as I look at the things I can do with InfoPath today, specifically related to customizing a SharePoint list form. If my changes are minor and require little effort, yet bring big value to the solution, then I would recommend that you continue to make those changes using the current available toolset.
What immediate value does this bring to the solution I am building?
The final question I would weigh is the comparison of the value the InfoPath customizations bring to the environment versus the effort that it takes to create it. Often a very small and minor solution within InfoPath can bring immediate value, causing increased usability and adoption among users. It would be a disservice to the organization if we stopped making these small changes and simply waited for another solution to come along.
In many cases answering these questions will help you weigh the costs of building a solution today using the tools available, looking for an alternate way to build the solution or simply waiting for the newest tools to become available. As you review your options on a case by case basis you will begin to develop a clear set of guidelines that will help you determine your best path forward.
As we wait to see what is coming next we will need to embrace the cloud first approach and understand that we are likely to see the changes first implemented within Office365 and then made available in a future release of SharePoint for on premises environments. This follows the same process that was outlined earlier this year with the announced release of SP1 for SharePoint 2013.
If you want to be the first to use the latest tools available, then you will need to be working with Office365. If you aren’t working with Office365, you should still be able to access trial accounts and get an idea of what could be coming in future releases for on premises environments. I imagine that the next big announcements around this topic will be shared by Greg Lindhorst as he shares the SharePoint Forms Roadmap during the SharePoint Conference in March. Until then we will just need to continue to work with the tools we have available today while always looking forward to what might be coming next.
Title image by Tatiana Popova (Shutterstock)
Editor's Note: Read more of Jennifer's SharePoint advice in From Requirements to Technology: An Approach to Build SharePoint Solutions