As the saying goes, nothing is free. This can’t be more true of the choice to implement dynamic Hide/Show functionality within your SmartForm. When deciding if your requirements demand the ability to dynamically hide and show information within a single SmartForm step, it’s important to take into consideration the implications of doing so.
There has been a lot of discussion lately about the best way to implement Hide/Show capability into a site’s SmartForms and I’ve seen different approaches to solving this problem. No matter the specific implementation approach, however, all of them require additional costs to both implement and maintain. It’s advisable to take a moment before jumping on the Hide/Show bandwagon, to consider the implications and decide for yourself if the benefits outweigh those costs.
Implementation costs can be measured in a number of ways but I’ve chosen to break it down into three primary categories:
- Cost of Initial Implementation
How much additional work is required to add this feature to your forms? - Ability to continue to leverage built-in features
These features include SmartForm Branching, Validation and Hide/Show Errors, Printer Friendly, Project Snapshot, Data Not In SmartForm Path, and View Differences. How does adding additional dynamic behavior into the individual forms impact your ability to easily take advantage of base product features? - Long Term Maintenance Costs
As requirements change and fields are added, removed, or rearranged on the forms, how much additional work is required to verify that the custom Hide/Show implementation continues to work as expected?
Taking these factors into consideration, the following chart draws a comparison between three implementation approaches in order to highlight where the added complexity of Hide/Show will introduce additional costs.
- No Hide/Show
Avoid the temptation altogether and keep forms simple. Use only SmartForm branching to steer the user to the proper questions. - Limited Hide/Show for Yes/No questions
Hide/Show in it’s simplest form. A repose to a simple question, such as a boolean, will drive the visibility of follow-up question(s). - Multi-Level Hide/Show
Allowing for fields within a Hide/Show also display dynamically. e.g. A Hide/Show block within a Hide/Show block.
After considering the costs, you may still decide that your functional needs are best met with Hide/Show but at least you made the decision an educated one and you’re heading into the implementation with eyes wide open.
I wouldn’t discount, however, the elegance of simplicity and take heart in the fact that paper-based forms have never had a hide/show feature and people have been using them far longer than online forms. The addition of a few simple instructional words on the form may be all you need and allow you to avoid the additional implementation and maintenance costs.
Cheers!
Tom,
ReplyDeleteGreat article!!!
Thanks,
Shap
I'm going to have to call you out on that last paragraph. If paper forms are so great, why do it online at all? Why would Smartform branching be such a huge advantage over "if you answered question 10 "yes", complete pages 15-16 of this form"? Why does your product exist?
ReplyDeleteIn all seriousness, I view the hide/show feature as a natural evolution of the Smartform branching. When done well, it can be a very positive experience for the end-user. When we implemented at our site, we got tons of feedback congratulating on us on finally making the forms shorter. We hadn't shortened them at all, simply hiding some of the questions unless they were needed was enough to make it FEEL shorter to the end-user. And technically it is shorter, because the user no longer spends time reading questions they don't have to answer. Yes, branching also does this, but there is a distinct difference in when to use one vs. the other. The trick is walking that balance between the two.
I completely agree with you that there is a high maintenance cost to implementing complicated hide/show, and that needs to be carefully considered. But, I'm hoping that some point it becomes either integrated into the base product or someone innovates an even easier way of implementing it. There are plenty of features that are now part of base that used to require tons of work on the part of your customers, but it didn't stop us from creating/using them. And we'll continue to do so as long we think that something can be improved upon, especially when it comes to user-friendliness.
This is a stellar discussion and it's off to such a good start. I agree with what both of you are saying, and speaking from experience.
ReplyDeleteWe've felt the pain of custom development and the upfront issues Tom is describing. There are even more issues we could point out that we encountered! Including all of this in a blog post would have been too lengthy though. This captures the condensed constellation of problems one has to consider and raises the cost vs. benefit considerations at hand very effectively.
We have also heard the identical feedback Jon C. noted, to the point of being eerie. "The forms seem so much shorter." Clearly, the users are having a positive reaction, who likes to fill out forms?
How do we walk the line and not overcomplicate our implementation? How do we know we have exhausted Base functionality and need to go custom? How do we create customizations that will survive Framework upgrades and can be maintainable?
Appending to the previous post, a recent KB article describes a new Base feature in 5.8 that could significantly simplify our custom Show\Hide implementation: Click Portal fires the "viewControlUpdated" event on the DOM. See Article:
ReplyDelete"Responding to User Interactions with Reference View Controls (e.g., in Hide/Show Implementations)"
https://www.clickcommerce.com/cc/resource/doc/DOC00034893/INFO_viewcontrolupdated.htm