How To Organize InfoPath Fields: 6 Rules To Maintain Sanity

Unnamed InfoPath Fields
Before: What a mess! Impossible to determine what is going with the form.

Recently I ‘inherited’ an InfoPath form to clean up and expand the capabilities of. The project is fun and interesting, so I thought it would be a quick and easy exercise. Unfortunately, when I opened the form, to my horror, none of the fields were named or organized in any way. This isn’t a big deal on a form with a dozen fields or less, but this bad boy had 236 fields, named field1, field2, field3 … all the way to field 236. Worst still, the fields weren’t in any order in the fields window; checkboxes at the start of the form were at the bottom, and text boxes at the bottom were somewhere in the middle. It was literally impossible to tell what field was what.

This happens easily and regularly, because when you pop a field into InfoPath, it’s automatically assigned a name of ‘field#” (where # is the number of that field). When you’re quickly throwing together a form, it’s easy after a few dozen clicks to have an unmanageable, unorganized number of fields.

Referring to these fields in InfoPath by ‘field#’ is not best practice, and frankly it makes your fellow InfoPath developers weep before bed every night – oh, and wastes tons of time trying to figure out what field is what. For example, good luck building rule sets with conditions like:

field23 is equal to field94 AND field 12 is not empty AND field104 is greater than field 197.

This. Makes. No. Sense.

There is a better way: The 6 rules below will get you well on your way to organizing and bringing sanity to an insane InfoPath world.

How To Organize InfoPath Fields

1. Order

Keep your sections and fields in the order they’re displayed on the form. Moving fields around can be a pain, but it makes the field list more logical and easy to navigate. Tip: It’s a lot easier to move fields around when they’re inside of logical sections (see ‘Use Sections’ below).

2. CamelCase

Use CamelCase to name sections and fields to make the names more legible. Since InfoPath does not allow spaces in field and section names, using CamelCase can make it much easier to distinguish distinct words for field names. For example: producttype becomes ProductType.

3. Use Sections

Sections aren’t just for conditional displays. You can create them in the Fields window to separate logical groups of controls, or even blocks of text. If your form has logical sections or separation of content, use groups to define those sections in the field list.

4. Descriptive Names

In programming, Hungarian Notation is a naming convention used to describe variables and functions. I use a similar system in InfoPath to help describe the type of field I’m using, so I can quickly know what kind of control it is, and by extension the type of information being captured. For example, if I’m using a text box, I prefix the name with ‘txt’. So FirstName becomes txtFirstName.

Field Name Prefixes

Field Type Prefix Example
Text Box txt txtFirstName
Rich Text rtxt rtxtComments
Drop Down List dd ddPantSize
Combo Box cb cbShirtSize
Check Box chk chkNeedsBelt
Option Button rdo rdoShoeType
Date Picker dte dteBirthday
Date and Time Picker dtet dtetPickup
Multiple Selections ms msPatternType
List Box lb lbShoes
Bulletted List bl blBelts
Numbered List nl blChoices
Plain List pl plOtherSelection
Person/ Group Picker ppl pplSalesAgent
External Item Picker exl exlProduct

Object Name Prefixes

Object Type Prefix Example
Button btn btnSubmit
Picture Button pbtn pbtnHouse
Calculated Value n/a n/a
File Attachment att attDocument
Picture pic picFields
Hyperlink www wwwGoogle

Section Names

I tend not to append the section type with a prefix, because it’s more important to give it a descriptive name, and then name any fields inside with a prefixed, descriptive name. After all a section is a group of data, not the data itself.

5. Give Rules Action Names

I know, Rules are technically not InfoPath fields, but all the same you should always give them a good, descriptive name. Much like fields, by default InfoPath gives the rule a name like ‘Rule#’. I use a descriptive name that includes a verb, which describes the action the rule is actually doing.

A common rule is to make a section hidden if another field does not equal a particular value, in this example, I name that rule ‘MakeHidden’. Similarly, if a field has a rule that makes that field required based on another field’s value, I’ll name that rule ‘MakeRequired’.

6. Consistency

Rules are only as good as how consistently they’re applied. I know it’s more work to name, order, and section everything properly, but trust me, it will save you (and others) time and effort in the future. Apply the above rules across an entire form every time you create a form – and when you can glean what the form is and what it does in 5 seconds flat, pat yourself on the back.

Rules to organize InfoPath fields.
After: At one glance, it’s easy to see the structure and function of much of the form.

Closing

InfoPath makes it so easy to bang out a form in just a few clicks, but the cost of this is lack of enforcing any kind of structure or rules to that  will help you and others in the future to remember how the form is structured and what it’s actually doing.

 

Ordering your fields, using CamelCase, Sections, Descriptive Names, Rule Names, and Consistency are 6 quick and easy ways to bring some sanity back to your forms, and save you and your coworkers a significant amount of blood, sweat, and tears.

By Nik

Nik is a project manager and web technologist that enjoys solving peoples' problems through web technologies. When he isn't doing those things, he's lifting heavy things up and down repeatedly, and cooking with his 3 children, who are actively trying to eat all the ingredients.