Disclaimer: It is week 2 back on the doppio’s. I have been watering down my coffee to Skim Mocha for almost as long as I have been in Sydney. However, the days are growing longer, work is getting busier and the dull kick of chocolaty milky coffee just doesn’t get the desired results.
Which brings us nicely to InfoPath… When times are tough, resources are scarce and there are not enough hours in the day, you have two options. Either improve the productivity of your workers (see above) or improve business processes. One of these options does not carry the risk of spilling caffeinated liquid all over your IT assets though. Forms do have their own cost though… a choice cost.
The problem with a form is that it is the fuzziest end of a business process. While plenty of time may have been spent constructing reporting, dashboards, workflows and rules each more nefarious than the last, a form is a form and we often decide to build the interface with the tools that we are most familiar. This is the wrong way to develop forms – forces compromises in time or functionality and sells the business process short. A couple of scenarios:
You are a rockstar developer. One day you receive a requirement to develop a registration form for an event your company is about to run. The marketing team have been busy constructing their event and just need a teeny bit of your time to update the event from last year. Not a problem (besides, you scored a six pack of left over beer last time you helped out)! You open up the sourcecode for your website and make a few changes. But before you put it back into the production environment you should really test it. Once testing is done, the marketing developer has a few more changes to make. The 3 course dinner has become a buffet breakfast, so there is no need to ask for meal preferences. Not a problem. You make the change. You check in, you test. But then there is another change. and another. and another. One of those beers are looking pretty good right now…
If you are a developer, your time is in high demand! While it is easy enough to whack a form together, there are development lifecycle considerations to make, testing, debugging, deploying issues. What would be handy would be a flexible forms tool that you could quickly pump out no-code forms that can still talk to existing backend processes or even embed into existing websites or custom applications. Getting a good looking form up and running quickly frees you up to focus on the more interesting work and herding all those disparate apps into the one SOA to rule them all.
You are a accounts payable analyst. After years listening to the constant whine of “Greening IT”, “reducing paper use” and “this paper form is an antiquity” you have moved from your beautiful photocopied form (on company letterhead) to a newfangled word processor document. After getting over the initial shock of seeing the form you knew and loved rendered on a computer screen you start to like the power it can bring. A red squiggly underline reminds you when you type reciept. Using word fields you have even embedded drop down lists and check boxes. However, even though you have spent time in getting in touch with your inner geek, your inbox is still piling up with unsuitable forms and you have to check them by hand. Ideally you would be able to automate some of the error checking and even the whole submission process. You would ask a developer, but you really don’t want to see all that work you put into Word go to waste.
As a business user, you should absolutely be using the tools most familiar to you. There is a lot of interesting forms capabilities in Word and Excel – formats that many of your business forms are already in. While some of your really advanced business forms will require IT assistance, you don’t have the budget to get help with every form and don’t have time to wait for when a developer is next available. What would be great is a tool that will allow you to take your forms to the next step yourself – without needing a course in computer science.
These two scenarios illustrate how differing backgrounds can lead to different form decisions that may or may not suit the environment. I tend to think of forms choices as progression of more automated, yet more complex technologies.
At the bottom of the graph is good old paper. Undisputed king of forms since it was mass produced and marketed as Papyrus 2.0. Paper has it’s advocates: network, software and computer agnostic people with heavy requirements for offline or postal usage and manufacturers of large, expensive multifunction devices. For the rest of us, there are often better solutions.
Word adds the ability to treat the form as an electronic document that can be filled out on a computer, emailed around, archived or uploaded however you like. Perhaps a killer feature is the ability to downgrade into old-style paper formats (although this process is unfortunately one way).
InfoPath can import a word form and apply better rules, validation and integration with enterprise systems, databases and web services. This opens up the possibility of the form becoming more aware of the process it is facilitating, using dynamic values and removing lag time between filling out and processing. As an added trick, InfoPath forms can be published to SharePoint, exposing the form as a web page for people to fill out without requiring InfoPath.
And there will always be a place for custom solutions. Some forms are so heavy duty and so unique that only a handcrafted solution will do. Perhaps you want to show 3d data, imagery or heavy workloads in restricted environments.
There is a lot of overlap in this model – and that is for good reason. In many cases there are not clear cut-over points where it makes sense to custom develop rather than use InfoPath – a decision made murkier when using Data Connection Libraries, Web Services and managed code to extend InfoPath’s functionality. Likewise, InfoPath can scale down to meet almost ad-hoc requirements (although I would still turn to Word if the predominant output will be printed). So, while InfoPath may not be suitable for every single form in your organisation, it has a breadth of functionality that will meet most requirements in a simpler and more automated fashion. So rather than think “Should I use InfoPath for this form?”, think to yourself “Why would I not?”.
For the advanced infopath ninja, I am probably preaching to the converted. Here are a few links to really interesting InfoPath content for the expert:
PingBack from http://www.clickandsolve.com/?p=19986
Alistair Speirs has written a great entry on his view of Electronic forms.  His description of the