I just need a contact form. Simple, right?
I would have thought creating a contact from on our new website would be easy as pie. It is….if you are talking instead about calculating Pi….to the 100th decimal place. Our old, static website had a custom-coded .asp webform which pushed traffic to pre-determined email recipients in the company. At first, I thought about porting this code over to keep everything as is, but this is SharePoint, why not make it more robust?
InfoPath, Anonymous Users and Workflows = Danger!
If only I had known what this heading states before so many man-hours were wasted. Since our website is customer-facing we of course need to support Anonymous Users. And we need to ensure those users can contact us without trouble. Our original architectural approach was the following:
- 1. Deploy an InfoPath webform that is able to be submitted by Anonymous Users
- 2. Create a custom List in SharePoint that would interface with a data connection (custom webservice) setup in InfoPath Designer; data flows from the webform to the List (this allows us to keep information about our users, and possibly later allow us to flow this data directly into our Microsoft Dynamics CRM application as possible leads)
- 3. Create a workflow so that when a list item is added (a contact form from an anonymous user), an internal user/group is notified via email.
I didn’t think this was a big deal…boy was I wrong. The big problem in all of this is SharePoint 2010’s support of Anonymous Users. Anonymous users cannot initiate workflows! Although I understand there are probably security concerns with SharePoint allowing this, it seems like there should be a way to allow Anonymous Users to do this through some specifically granted permissions. I can think of many instances where this functionality would be incredibly helpful.
So now what?
What we ended up doing, was simply having email notification sent to our representatives and forgetting about storing data in SharePoint. I created a series of InfoPath webforms, published them to SharePoint, and I used the InfoPath Web Part to place the forms on the pages. This also caused a little heartburn as well, because the InfoPath Web Part cannot see InfoPath forms that aren’t stored within the site where you are editing pages. I discovered the best way to handle this was to publish ALL forms as a content type to a central forms library at the top site in the collection. Then, I could create a forms library within each sub-site, and in the library under Advanced Settings ‘allow the management of Content Types’. I could then select to inherit the needed content type (Form) from the top-level site and voila, InfoPath Web Parts for that site could now see it for selection.
Until recently this method didn’t seem to be a problem, but we just realized that because we are only doing email submit actions, we have no way to gather metrics on what percentage of people who hit a contact form actually submitted one.
Well, how about after form submission we send users to a specific confirmation page?….we can setup a page in our analytics tool to see how many get to the page vs. visited the contact form, and that equals our conversion rate. No sorry, InfoPath doesn’t have a submission rule for “re-direct to another page”. Ouch again. I strongly urge the InfoPath development team to think about supporting what I think would be a VERY popular form submission action. So what’s our conversion rate? I have no idea. We are now looking at having to contract a third party to host our webforms, track our conversions, and submit the data directly to our CRM. Ugh.
Now the good news…
So what DO I like about InfoPath/SharePoint webforms?
Point and Click form building
Being able to manipulate forms in this way is very nice for a designer. Dragging form elements and labels onto a page and deploying to SharePoint with a couple clicks is definitely nice.
I like the idea of supporting multiple Form Views. I was able to create a Form Submit rule that upon submission, the form could change to an alternate ‘view’. For our contact forms, this allowed us to put a custom message to confirm the form was submitted, and hide the form from the user to prevent multiple submissions. This also allowed us to create form-protected assets. We can force a user to fill out a form, and upon submission be shown ‘protected’ content or links. Pretty cool.
Form Submit Rules
I like the ability to build form logic using submit rules. In my case, it was great because I could use the logic “if user clicks radio button ‘x’, use data connection ‘y’ to send email to a specific representative”. I also like the flexibility of form validation rules and display that you can set on a per-field basis.
Support of Browser-Based WebForms
Thankfully you can set forms to appear as a normal browser-based webform. It would be a shame if every user who visited the site had to have InfoPath installed to send a form.
Any Other Gripes?
Sorry, but yes…
The InfoPath-Assigned Background Color
Why can’t you just set the form to have NO background at all? Well, I did set the form to have no background color, but it did no good. I have a ton of transparency on the website as you can see, and a big ugly white background with padding and margins set by default around a webform caused me much pain. These background and margin styles are inserted DIRECTLY into the markup as an element.style instead of a CSS class being assigned to the form. This means I have to use the ‘!important’ css hack to override this default InfoPath styling to get the output I really want. AND I have to go find EVERY instance of a form (of which I have many), copy the HUGE CSS ID to my clipboard and assign this style hack in the stylesheet. This is NOT easily maintainable and a huge waste of time all around. InfoPath developers: please just trust the developer using InfoPath Designer knows what they are doing, and don’t automatically assign styles. If they want a white background and 30 pixels of margin, they can do that in the app. REVERSING it however, now that is a pain.
Required Fields Styling
How about a little more control on what is shown to the user when indicating a required field. Having a red-dashed outline around a required radio button selection is a bit confining if you ask me…..Allowing for a custom style to be created in InfoPath would be nice. Or better yet allow a CSS Class to be assigned on a per-field basis and/or on a validation rule basis. Then you can control it centrally through your stylesheet, and change EVERY webform on the site with one change.