Sitecore Web Forms for Marketers (WFM) styling and lessons learned

I recently spent some time trying to use Web Forms for Marketers doing some custom styling and custom save action. I learned a few things along the way and wanted to share. I learned there are some times to use Web Forms for Marketers and some times not to use it. The goal of this article is to explain those consideration and help others learn some tips to understand why it may or may not be a fit. The module has some cool features and in some regards can be pretty slick. However, in other ways it can be a pain to use and provide no flexibility in some areas. This article is based on Web Forms for Marketers version 2.3.

Styling

The module sells itself as a control that can be styled anyway you want it. Well, that is kind of true. There are two ways you have control over the styling of Web Forms for Marketers, via the style sheets and via the Sitecore based module admin UI.

Module’s Sitecore admin UI

The Sitecore based admin UI comes with the module so lets start there. This UI does provide a way to assign styles to an input field via the “Css Class” field. Here you can assign a custom class to style the input box. You need to create a new CSS class in the module settings (all this is documented in the guide). If that is all you want (to tally style the textbox) you are good to go. All text boxes have the same style applied to them. Internally what happens is the information in your assigned CSS style is indirectly applied to the text box, dropdown box or checkbox. So some fidelity of control is lost.

Here are a few gotchas with this type of styling no one mentions. 1) You have no control over the field’s label style via this interface. 2) You have no control over the fields validation styling via this interface and 3) Even though you can tell it rather or not to show a title and footer if you say no to either or both the control still reserves space for those areas. So if you don’t want headers and footers you still have to deal with extra space above and below the form for them.

 

So if you want authors to control creation of forms and their styling, the styling requirements need to be pretty basic and stay similar to the default styling. If you have unique styling needs for forms on the site which go beyond text box styling and setting a required filed asterisk, this module is probably not a good fit. 

Here is the form I was trying to do.

As you can see it’s style is very different from what the default form spits out. I needed to hide my labels, have default text in the textbox and have special validation styling.

The default validation styling puts an error message to the right of the text box (by the way, you cannot control the error labels color. Even if you update the stylesheet the color is hardcode in their code behind). Validation also has a validation summary as a bulleted list below the form title. Again you have no control, via the UI, over rather or not this is shown or how it is shown (list, bulleted, paragraph, etc). For me I just wanted a red “required” text to show up top and the textbox to be outlined in red (more on this later).

 

Module’s Style Sheet

To style some of these more “advanced” things you need to venture into the Default.css that drives the form style. It was easy enough to hide all the labels this way. Just find the correct css style and update it to “display: none;” This is great if all your forms on the site will not have labels because when you change things in the style sheet it applies to all WFM forms added to the site. So if a content author wants a form on one page with labels they are out of luck. You can also turn off some of the validation styles here like the “*” next to required fields.

There are two default.css style sheets, one in themes and one in the module root. There is also a custom.css that you can add styles to. You do have a lot of control via these styling sheets, but it is key to remember the changes  you make here are global to the site and cannot be controlled via the admin UI. This means content authors have no control.

Save actions

One of the great things about this module is all the save actions you can attached to the submit button. You can save to the Sitecore database, send emails, create user accounts and lots more. You can even create custom actions. I will write another post on creating a custom save action. This is more focused on the implications of needing to do this. First, finding details on how to do this and what objects you can wire into is pretty limited. Second, if there is any configuration needed for your save action  you have to create a sheer UI for all of this (also not a lot of documentation on this either). The ability to wire into all these different events and Sitecore items can be powerful though.  You can do pretty much anything you need to via a custom save action. If you need to use some of the included Sitecore based action plus a custom save action this module maybe a good fit. If you only need your own custom action it may not be a good fit, unless some of the other areas are a good fit.

Validation

To be honest, I am pretty disappointed by the level of control over validation this module provides. In some respects it provides some great things, for other areas it levels the author and/or developer out in the cold. As you can see from the above screenshot, the module lets you specify if a field should have a validator for required filed, or for how many characters the field can have. You can also apply some regular expression, even a custom regular expression. You also get a validation summary and validation messages next to each field (you can control only some of the validation text that is displayed). Again if this is all you want it may be a good fit.

Some of the areas where validation can trip you up. If you don’t want each field to show its validation error but only want the summary control to show the message. The only way you can control this is by updating the css file to style those field so they are not visible, again this means it is turned off for all forms. Same is true for the validation summary control. If you want custom text to show for the validation summary control you are out of luck as well. You also cannot set the default value of a field and in turn set the initial value of the required field validator (this allows for a form like above where the label is actually the initial text of the field. Settings these values lets the required validator mark the field as invalid if a new value is not provided). You can export the form to a user control (ascx file) but this kills your non-IT based authoring story, which is one of the bigger reasons to use this module anyway. You also cannot apply custom error styling. For me I wanted to mark the field with a red boarder if validation failed, again you can do this in the code behind if you export to a user control, but now  you are really starting to swim upstream.

Summary

In short here are some of the things I would look at to decided if Web Form for Marketers is a fit.

I would lean away from WFM if:

• No need for Sitecore based form actions
• No need for content authors to manage and create forms on their own
• Custom styling, outside of input items (textbox, dropdown list, etc) is needed
• You want your field labels to be the initial value of the field
• You need some custom validation summary and error message styling

I would lean toward WFM if:

• Your styling needs are pretty basic or styling is global enough and limited enough so as to apply to all forms
• You need the included Sitecore integrated actions
• Module analytics are needed to track form submissions and other stats
• Non-IT resourced or pure content authors must have ability to author forms and control them

Hopefully this helps you understand the pros and cons of this module and how you can position it. If you need to use WFM just be aware of the pitfalls and try to work around them during requirements and design. I am sure there are other options as well, and if you have them please let me know.