InfoPath 2010 is a powerful form creation tool, from web enabled forms that can be accessed from anywhere to internal company forms that manage HR process, InfoPath is an important part of any form based SharePoint solution.
Just as in any development, there are best practices that can be followed when developing InfoPath forms. Note that development here means developing the form within InfoPath 2010, not writing a code based form using Visual Studio. Coding best practices are well covered here.
This best practices document covers best practices for use with InfoPath 2010. This post is intended to be "living", that is, I will update and improve as these processes are repeated in a professional development environment and refinements or updates are made.
The steps for form design and development, with associated recommendations, are in order as follows:
• Form Types
• The Form Design Process
• Form Design
• Form Development
Form Types
The first decision that has to be made when designing and InfoPath based form solution is which type of form to use?*
List Forms store all of their data in an associated SharePoint list. As a SharePoint list has a flat data schema, the data schema associated with the form will be flat as well. The form is generally bound to a single list and the data associated with that form typically remains in that list. List Forms are a good choice where the various fields associated with the form area also needed in reporting and other internal data retrieval processes. Since all of the data associated with a list form is in a SharePoint list, all of the functions related to SharePoint lists, such as building reports directly against the list using report builder are supported. List form data is typically not mobile (moved from one list to another).
You can create a master/details scenario for repeating data using list forms, using two lists linked together with a lookup field, or you can simulate a one to many relationship by adding columns to the flat schema to hold all repeated data, generally the cap on this approach is 10 columns max, use a linked list if the you require a larger number of detail columns. Using an InfoPath filler based form template provides you with master details data support by default (see “InfoPath Filler Form” section below).
Generally, List forms are simpler non code modified forms that directly attach to SharePoint lists.
Form Library Forms store all related data as an xml file. This gives the potential for nesting data schema’s, as the restriction on schema type is limited to what can be produced in XML, rather than a flat list.
As form libraries store the data as xml, the amount of steps to extract data for other purposes (binding to workflows, reporting, shared data with other forms) is higher than List forms, as you not only create the field to hold the data, you have to promote each piece of data that needs further interaction as a site column.
This additional effort to expose values stored in form library forms may be required if other features of the form library only available using that form type. It also adds a small inefficiency to the design of the forms, as data from the forms that needs to bind to workflows or be reported on is now in two places, the xml behind the form, and the site column in the SharePoint database. And also consider whether you wish site columns to be part of the content crawled by SharePoint Search (they are not by default).
The other feature of Form Library Forms is the ability to turn them into site content types. This allows additional functionality, such as the ability to MOVE FORMS between any SharePoint Library that has that form added as a content type, and using RECORDS MANAGEMENT rules to move form data if necessary, as well as binding workflows directly to the content type so that the workflow fires regardless of where the form is stored.
In summary , use a list based form if you wish to interact extensively with the data and do not need the features of the Form Library forms. Form Library Forms are more advanced forms that allow coding, digital signing, and can be used in sandboxed solutions.
InfoPath Filler Forms can be either List Forms or Form Library forms, the difference with these forms is that they can only be filled out using InfoPath filler, as opposed to being a web enabled form viewed from within SharePoint. All users who use this form must have InfoPath form filler installed locally on their machine.
The advantage of InfoPath filler forms over web enabled forms is specific functionality is available that is not available in web enabled forms, such as the supported display of master detail type data. A complete list of differences in functionality is listed here.*
* See the deployment section for further considerations around list based forms.
**One "gotcha" with web enabled forms that aren't present in InfoPath filler forms is are the oddities around tab order and the people picker. Basically, an InfoPath filler form correctly obeys tab order including people picker, the people picker on a web form doesn't.
The Form Design Process
The first step with any InfoPath project is to design the form and work through a design approval process with the client. At this time, no functionality or data connections are configured, the sole focus is on creating a form design that meets the clients requirements. This means creating a prototype form that doesn’t have any functionality or data connections, it’s simply the form created in InfoPath with the proposed look and feel of the final form as well as any fields associated with the form.
This version of the form is then provided to the client, usually the first version is a demonstration directly with the client to allow feedback and questions. The form then goes through a number of design phases and iterations as the client finalizes the look, feel, and functionality of the form.
While some show/hide rules may be associated with the form at this time to demonstrate specific functionality to the client, most of the logic and development is not completed at this time, as the form is in a state of change. The final design of the form may differ significantly from the original proposed design, so any development work may have to be re-edited and changed for each iteration. Saving the development work for after design approval is more efficient.
Challenging areas of form functionality can be tackled at this time however, see the “Proof of Concept” section in this document to cover this area.
Form Design
Form design refers to the look and feel of the form, the way that fields are placed, the information located on tabs or views, and the color and font scheme.
The first step in creating a new form, after determining the form template type, is to add all of the fields to the form. The fields should be named in Camel Case to speed up form development, if you name a control UserName for example, if you drag the field on to the form, InfoPath will automatically separate the field on the capital letter, so that the field descriptor looks like “User Name”.
Many of the InfoPath form design best practices are also web best practices, such as creating a clean interface and limiting each page to a maximum of 40 fields. This document does not go into detailed interface or web design best practices, but does make the following recommendations:
1. First do a sketch or wireframe model of the general form appearance. If the number of fields exceeds 40, use multiple tabs or show hide sections to hide additional fields. Plan the form design before opening InfoPath.
2. Create your fields first using a clear naming scheme that describes the data held in the field, name your fields in Camel Case. If you are using tabs, name the folders that contain the fields the same name as the tabs, so that it is obvious and intuitive when working on one tab which fields are associated with that tab.
3. Use tables to ensure field alignment in your forms. Don’t hard code colors or fonts, use the built in themes or font styles instead.
4. Use views to separate data groups. So, if you have a form that has employee information, request information, and manager approval information, create three views, one for each. Related data should remain in a single view. You can navigate to a view directly from the URL with the parameter ‘defaultView=[ViewName]’. Views can also be used in wizard like interfaces, where each view corresponds to a step in the form filling process. This type of more involved form development can occur in this phase as it may be important to demonstrate to the client how this functionality works and looks.
5. Name similary or same controls on different views with a view descriptor as well. If you have a save button on each view of the form, ensure each one is named with a view as well, ie Save_Employee, Save_Manager, etc. This will avoid confusion between similar controls when configurating rules and interactions.
6. Create a read only view on forms where the initial form user needs to be able to review their form information after submit, but not edit it.
The general rule for form design is to keep the form simple, and to avoid as much development work as possible on the form at this time to prevent needing to rework the same areas multiple times. You may however have to add some functionality in order to demonstrate show/hide or other functionality that is key for the client to understand.
Proof of Concept Work
As you review the form requirements and complete the design work, you may run across one or more functional areas that are either new areas of knowledge for you or complex. Make note of any functionality that looks challenging, and, during the design approval process, use this time to perform Proof of Concept work.
Proof of concept work is solving a technical challenge in isolation, with the intention of duplicating the solution on the client form once defined.
So, for example, if you have a form that has a number of statuses associated, each status indicates a step in the approval process of the form. One way to limit which statuses the end user can select is by creating a list with the status values associated, and then using SharePoint permissions on that list, limiting which list values will load into the form based on current user permissions. If you are also triggering workflows off of this status, the workflow that detects this status will have to be developed using the status ID value from the list, not the text value.
This specific functional challenge is outlined here.
This complex piece of functionality can be isolated and programmed into a new form, one that only has the minimum fields necessary to support the functionality. Then the process of extracting the status, based on permissions, and having a workflow detect that status are added to the form and workflow. Once the functionality is working and proven, the process can be documented for repeating later.
By documenting the solution, you allow future challenges similar to this one to be troubleshot faster, and you share the solution so that others in your team will not have to spend the same amount of time getting that functionality working.
This is one of the key tenants of best practices, repeatability. Finding an answer to a complex problem once is challenge, having to find the same answer again is a waste of time.
Proof of concept work completed during the design phase allows development to continue while waiting for final client approval, and allows complex technical areas to be resolved in isolation without having other areas of functionality potentially causing confusion.
Form Development
Once the client has approved the design of the form, and you have completed and documented any proof of concept work, you can start on form development.
Form development is the addition of the functionality and tools associated with the form. This includes:
1. Data validation
2. Formatting (show/hide, colors)
3. Actions
4. Default Values
5. Data Connections
6. Associated supporting tools (lists containing populating data, list that holds form data)
If your form has complex functionality or multiple stages, you may wish to create a debug view associated with a debug page that shows key values for that form. If you have a form with a number of hidden variables that manage state and appearance, then create a debug view with those fields for quick reference during preview.
Preview your form often, particularly after each new area of functionality is complete, to ensure any bugs or issues are trapped as they occur.
Name any rules appropriately by function, so that the purpose of the rule can be extracted by the name of the rule, ie “Show Hide Submit Button”. Adopt a consistent naming convention for all fields or rules to enable rapid troubleshooting and maintenance of the form.
Keep the data structure associated with the form as simple as possible, nested and repeating data adds significantly to the amount of effort necessary to bind the form to its data connections. Ideally keep the schema flat, where one to many relationships are simulated using multiple columns instead of a separate table. There may be a functional requirement for using complex data schemas, this is fine, the general rule however is to keep it as simple as possible.
Consider form load times for media and data. An infopath form can embed images within the form template (as opposed to having a link to an image), this can be useful in situations where the users of the forms don’t have permissions to the original images, but need to view the form with the images intact. It will add significantly to the size of the form however, so only use if necessary.
The “automatically retrieve data when the form is opened” on data connections can significantly slow the form load. It is better to delay the data load to on demand.
Filtering data before it is used in the InfoPath form is another way of effectively reducing load times.
As you develop the form, be sure to stay on top of maintenance, not just removing a control from the form but ensuring any fields and rules associated with that control are also removed. This also prevents unexpected behaviour caused by orphaned rules.
As in proof of concept work, any tough areas of functionality should be documented so that the time spent researching the solution does not have to occur again. Documentation may seem like a time drag at the time of creation, but being able to quickly refer to it again when encountering the same or similar issues more than makes up for that initial investment. And having other developers able to refer to that documentation instead of researching issues themselves is a further time saver.
Overall, form development that matches best practices does not simply produce a form that works for the client needs (meets requirements), it creates a robust form with reliable functionality, with a design that is easy to maintain. Using a documented approach to technical challenges also creates a knowledge base within your organization, so that new developers or team members can more quickly be converted into value producing resources.
Deployment
Once design work has been completed, if you are deploying your form straight to production (using InfoPath Designer's Publish ability) then you can start development immediately using the front end tools (InfoPath Designer, SharePoint Designer, Other Office tools).
If however you are following a more traditional Software Development Lifecycle where different environments have been created for each stage, such as development, testing, and production, then deployment influences your form type choice as well.
A SharePoint list based form cannot be deployed using the same techniques as a library based form, due to its specific functionality. When you add or remove a field from the associated list, the form itself needs to be updated and published manually.
In this situation, you may determine that a form library is the best solution, as the only way to script and have the forms deploy automatically through multiple environments is by using a form library based form.
This comes with a cost to the client however, as the amount of effort needed to modify a form library form with a new field, and have that field then exposed for reporting or workflow usage is considerably more than simply adding a field to the list and then editing the associated InfoPath form by adding that field and publishing.
If you are deploying your InfoPath forms based solutions through multiple environments then Form Library based forms may be your only practical solution.
If however you are deploying straight to production, then choose the best form type for the business application using best practices as outlined in this document.
No comments:
Post a Comment