Why I love InfoPath

The best way to explain why I love InfoPath and InfoPath Forms Services is to explain why I hate other incarnations of forms.

When I was a student, I spent the summer holidays doing temp jobs so that I had money for the rest of the year. Temp jobs are generally not all that exciting and my work often involved tedious data entry and other miscellaneous office tasks.

A job I had a couple of summers ago was for a company that (among other things) provides training and qualifications for nurses. This involved a heck of a lot of forms for me. I would send out forms, either by post or by email, to the various companies that were interested in the training. Then someone in that company would fill it out and send it back, usually by post or fax. On one occasion, I emailed a form to someone who printed it out, filled it in, scanned it back into the computer and then emailed the scanned image back to me. That’s a lot of effort for one form.

Then came more effort. I would have to take the forms and enter the information on the computer about the trainees, log which trainer had been assigned and then store the paper form (I would have to move the forms later on because there were different folders for training that was booked, in progress and complete).

I also had to be careful if one company had a lot of people registering for the training because they would send in multiple forms. I had to make sure that those forms were dealt with as though they were a single form to prevent someone setting up two training sessions when only one was wanted.

And those were just the internal forms!

The company I worked for gave the training but qualifications were given by a well known UK exam board. So every single person the company trained had to be logged with the exam board. This involved the trainee filling out a form and me copying the information into the exam board’s system through their website.

There was some information that was exactly the same for every single form because I had to enter information on the training centre each time. There was no way to get the system to save a half-filled out form so that I could use the same information. I had to enter it over and over again until it felt like I could type the details in my sleep.

There was some information that was the same for a batch of forms. A lot of the training was done in groups, so there would be between twelve and fifty forms all with the same company details on, which I would have to enter manually every single time. Also, many of the trainees did multiple courses. They might do an NVQ level one in nursing but also do a separate course on some specialist area, but I could have to enter that person’s information for each qualification separately. It didn’t matter how many previous courses a person had registered for, I would have to do exactly the same data entry as I would for a new person.

If there had been some way of storing the data and reusing it, I probably would have been able to work half the hours and still have more time for doing the filing and answering the phone.

There were also occasionally issues with people not filling out their forms correctly. Some fields on the exam board’s forms were mandatory. Which gave me a problem if the trainee hadn’t filled out the relevant field on their form. I got a very annoyed man on the phone at me once because I’d registered him with the exam board as female. He hadn’t ticked the box and he had a name that could be either male or female, so I went with statistics given that he was applying for nursing qualifications. What I needed was some way to enforce the filling out of fields in the forms the trainees got sent so that I could make sure I had the information I needed to fill out the exam board’s forms.

Another experience I had with forms was before then, when I was starting university and applying for my student loan. The forms were extremely confusing and came with a huge, thick help booklet so that we stood a chance of getting them correct. There were loads of “if yes, go to section 5.6, if now, go to section 7.2” instructions, so I ended up not entirely sure I’d filled out all the relevant sections. I checked through over and over again just to be safe.

This confusion isn’t just limited to the student loan company. If you apply for a new passport, there’s a service you can get at the Post Office where someone checks your form to make sure you’ve filled out all the right sections. Presumably this service exists because a lot of people get confused and don’t know whether they’ve written everything they need.

So, that’s why I’ve been annoyed by forms in the past.

When I was told I was specialising in InfoPath, I did a lot of playing around to see why I could do with the program. My initial reaction: “Why doesn’t everyone in the world use this?”

InfoPath allows users to create, with no coding, incredibly complex forms with a lot of functionality. Without any training, I was able to create forms with different sections and controls, conditional formatting, links to databases and lots of flexibility.

One of the points in my rant was about having to enter the same information over and over again. InfoPath allows people to design forms which can auto fill sections. I could create a form which looks at a database or list to find information. If I enter some unique identifier in one field, the form can go to a database so see if my details are logged, and then take other relevant details from that database and put it straight into the form.

A good example of where this would be useful is customer orders. A new customer will get fields to fill out with their name, address, contact details and so on. A recurring customer will have those details logged from previous transactions. Filling out one field will cause a lookup that will put the rest of the details into the other fields as default values. Maybe even filling out no fields. InfoPath has a built in function called username. If I’ve logged into a system to fill out the form, InfoPath might take my username and use that to find the relevant details from a backend system.

So, if the exam board had used InfoPath, my logging into the system to enter new trainee information could have caused all the training provider details to be filled in for me. Then, when I entered the name of the company where the trainee worked, InfoPath could look up to see whether that company was already in their system and, if so, fill out the rest of the information about that company. So I could have logged most new trainees by entering details in four or five fields, instead of in dozens.

Another point I mentioned as annoying me was the fact that the same data had to be copied from forms and put somewhere else. Wouldn’t it be much easier for everyone if sending the form put the information where it needed to be? Instead of the trainee filling out a form and then me copying the information into the system, wouldn’t it be great if the data went straight from the form into the fields in the database? It would make the whole process a lot quicker and reduce one stage where human error could introduce mistakes. No matter how careful I might be, I’m sure that some of those company and training details included typos, just by the sheer number that I had to enter. It is possible to create submit connections in InfoPath, with no coding at all, that lets users send information straight to a database or web service when they click to submit the form.

Another issue I brought up was one about people running out of space on forms. I’m sure it’s happened to most people at some stage or another. You fill out a form and it’s given you five rows were you need six and you have to go get another blank form and fill that in for the sake of one extra line. InfoPath has the option to create repeating sections and tables. If I put a repeating table into a form, it appears as a table for the user to enter information, with a little button next to it to add a new row. The user can click this as many times as necessary so he or she always has exactly the right number of rows to enter the information they need. The same principle applies to columns or whole sections. If I put a repeating section into the table, I could include text boxes, tick boxes, formula fields, tables, images and anything that I could put in the rest of the form. The user can have this section appear as many times as needed when filling out the form.

I brought up the subject of data validation. I’m sure that anyone who’s registered for something online will know what I’m talking about. Certain fields have to be filled in for the form to be submitted successfully. InfoPath comes with several different types of data validation, including “can’t be blank,” “must be greater/less than,” “is an integer,” “matches pattern.” The pattern one is useful for things like checking whether the data entered is a phone number or a post code. There are options such as checking whether a date is in the past or the future. You can write your own custom messages for if the value entered doesn’t meet the validation, or set up conditional formatting so you can do things like change the colour of text boxes depending on whether or not the data is valid.

The mention of conditional formatting brings me neatly on to another of the features of InfoPath I think is brilliant. With conditional formatting and views, the person filling out the form sees only what they should. You can design forms with different views so that a customer will see something completely different from an employee, who will then see something different from an employee with a different job role. Conditional formatting allows sections to be shown or hidden based on values in previous fields. There are plenty of examples of situations where a yes/no option is followed by “if yes, please give details.” In an InfoPath form, selecting the yes option could cause a text box to appear that was previously hidden. In the example I gave about the student loan forms, I saw every section of the form, regardless of whether I needed to fill it out. An InfoPath form can show only those sections that are relevant to the person filling it out, saving a lot of confusion.

So, InfoPath is a wonderful tool when it comes to forms. But not everyone has the same software. If you’re sending forms to people, you can’t be sure that they’ll have InfoPath installed, or even be running an operating system capable of supporting InfoPath. That’s no longer a problem.

With the 2007 version of InfoPath, it’s possible to create forms that are browser enabled. This means you can embed them as part of a webpage or inside a SharePoint site. The person filling out the forms doesn’t need InfoPath; they just need a web browser.

It’s also possible to embed forms in emails. I could email out a form to someone. They would open it within their email client, fill out the form and then click send. They would never need to install or use InfoPath itself.

The only person who needs InfoPath is the person creating the forms. This means companies can use InfoPath for things like request forms and expenses claims without having to buy licenses for every employee. They can put InfoPath forms in their websites and not have to worry that the people coming to fill out the form might be running Linux or a Mac OS.

The best thing of all: InfoPath is easy to use. I was creating incredibly complex forms within a couple of hours of first using the program. I didn’t have any training and I was able to link to databases, submit to SharePoint, include functions and arithmetic in the form, auto fill fields, have repeating tables and conditional formatting, create different views and more. No coding is required (though custom coded controls can be included if so desired) so administrators and those who want to deal with the forms can make them exactly as they want without having to go to IT for help.