Short answer: improving form performance & user experience, that’s what.
Long answer:
Since version 2011, major entity form elements (Control, Section, Tab) have the Visibility attribute added. This attribute, which is checked by default, determines if the form element will be visible to the user when the entity form loads.
Why would you want to render some elements invisible when the form loads? Here are some common reasons:
- Conditional logic: The form has some business logic related process which requires displaying some elements according to the user actions, e.g, hide Government Id attribute if the user selected Organization as Customer Type.
- Hiding built in required controls which can not be removed from the form and are meaningless to the end user.
- Hiding controls that are used to support the form business logic and has no meaning or use to the end user.
One uncommon reason to use the Visibility attribute is to improve form performance. I would like to elaborate on this, since I noticed many Microsoft Dynamics CRM developers are not aware of the impact which JavaScript code has on form performance which In most cases directly affect UX.
How can the Visibility attribute improve form performance and UX?
Business logic often requires script to hide/display form elements according the user actions. When the form loads, only a subset of controls should be visible to the user.
In many cases, the JavaScript code/form business rules which is triggered by the form onLoad event, literally hides all the form elements (some times, each individual control) and then render the required elements visible again.
Not only this approach waste client resources (inefficiently hiding controls which were just ‘painted’) but it also provides bad UX as it slows the form load time. With low resources machines, the user can also see the controls flick on the form before they are hidden by the JavaScript code.
The right approach in this scenario would be to uncheck the ‘Visible by default’ attribute for the elements which are not required to display on form load (preferring tabs over sections, sections over controls) and writing JavaScript code to render elements visible when required.
This approach will improve form performance & UX because of the following reasons:
- Less form controls to render: the form will load faster because it has less controls to render. In control heavy forms/slow machines, this is substantial.
- Less code lines to execute: since custom hiding related code/Business Rules logic is removed, the onLoad event will complete and turn control to the user faster. You can write less code by hiding/displaying containers such as Tabs and Section rather than relating to each individual control. Again, think control heavy forms.
- Reduce visual load: no element flickering on the form will provide better UX.
User experience critical to the application acceptance and over whole rating by users. Developers sometime miss these problems because the from loads fast enough on their dev machine.
For users who open record forms many times a day, even 2 seconds less form loading time can make a major difference.