Question
Apple Inc
US
Last activity: 12 Oct 2018 11:35 EDT
What would be the UI performance impact if the section contains 300 fields ?
Use case: Need to display 10 to 20 fields out of 300 fields based on the visibility condition.
Implementation: Created a section with almost 300 fields and also a when rule for each field. Most of the fields are dropdown which would try to fetch the information from external db tables. The reason we created one section so that it would be easy for business users to modify one section instead of modifying multiple sections.
What would be the UI performance impact if pega try to execute when rule for each field?
We have "Run visibility on client side" option available for each field. Does it help to improve the performance?
***Edited by Moderator: Pallavi to update platform capability tags***
***Edited by Moderator Marissa to update SR Details***
Accepted Solution
Aaseya IT Services Pvt Ltd
IN
Hi Surya,
There are 2 parts to this
1. UX experience in filling those fields: With all 300 fields in one section you have reduced extensibility as well as reusability of the section. You should group them in logical & layout form.
Logical meaning eg: CustomerDetails should be one section, BrokerDetails one section and say LoanDetails in one section. They can all belong to one single wrapper section but this gives a lot of flexibility. Even if the Customer Details has something which changes the details in LoanDetails section UI, you can do on-change action to refresh "LoanDetails" section without refreshing current section(CustomerDetails). In your current implementation you would do a refresh section & that will be a bad user experience.
Layout: should you be using a tabbed layout? or an Accordian so the number of fields visible at one time is say 100? You need a discussion with your BAs as well as Users to determine the acceptable behaviour.
2. Performance: A lot of the your fields are dropdowns which load data from external table - meaning you should be using DPages with appropriate refresh strategy. If the values in there are expected to be static organization wide, you could have them node level & so would need loading just once - will reduce your performance issue big time.
Hi Surya,
There are 2 parts to this
1. UX experience in filling those fields: With all 300 fields in one section you have reduced extensibility as well as reusability of the section. You should group them in logical & layout form.
Logical meaning eg: CustomerDetails should be one section, BrokerDetails one section and say LoanDetails in one section. They can all belong to one single wrapper section but this gives a lot of flexibility. Even if the Customer Details has something which changes the details in LoanDetails section UI, you can do on-change action to refresh "LoanDetails" section without refreshing current section(CustomerDetails). In your current implementation you would do a refresh section & that will be a bad user experience.
Layout: should you be using a tabbed layout? or an Accordian so the number of fields visible at one time is say 100? You need a discussion with your BAs as well as Users to determine the acceptable behaviour.
2. Performance: A lot of the your fields are dropdowns which load data from external table - meaning you should be using DPages with appropriate refresh strategy. If the values in there are expected to be static organization wide, you could have them node level & so would need loading just once - will reduce your performance issue big time.
With 300 fields you should ensure you keep "heavy on-change actions/validations" to minimum (eg: execution of activity,data transforms etc) to avoid screen lags. Also,a section to 'display fields which have errors' for better user experience. Lastly, ensure the screen can be used via 'tabs' instead of mouse clicks and the lesser the number of 'section refresh' the better will be user experience with screen.
Best luck!
Regards,
Tanul
Pegasystems Inc.
FR
Hello,
The impact is difficult to evaluate. It also depends on your fields, what are they containing, because it could be long list to present on drop downs or auto completes.
300 fields is still a lot. Even if you display 30 fields in 1 second, your screen will still be taking 10 seconds to display. It might not be acceptable for your users.
I wouldn't recommend to do it this way, even the maintenance will be difficult I guess.
CollabPartnerz
IN
Below post might helpful
Accepted Solution
Aaseya IT Services Pvt Ltd
IN
Hi Surya,
There are 2 parts to this
1. UX experience in filling those fields: With all 300 fields in one section you have reduced extensibility as well as reusability of the section. You should group them in logical & layout form.
Logical meaning eg: CustomerDetails should be one section, BrokerDetails one section and say LoanDetails in one section. They can all belong to one single wrapper section but this gives a lot of flexibility. Even if the Customer Details has something which changes the details in LoanDetails section UI, you can do on-change action to refresh "LoanDetails" section without refreshing current section(CustomerDetails). In your current implementation you would do a refresh section & that will be a bad user experience.
Layout: should you be using a tabbed layout? or an Accordian so the number of fields visible at one time is say 100? You need a discussion with your BAs as well as Users to determine the acceptable behaviour.
2. Performance: A lot of the your fields are dropdowns which load data from external table - meaning you should be using DPages with appropriate refresh strategy. If the values in there are expected to be static organization wide, you could have them node level & so would need loading just once - will reduce your performance issue big time.
Hi Surya,
There are 2 parts to this
1. UX experience in filling those fields: With all 300 fields in one section you have reduced extensibility as well as reusability of the section. You should group them in logical & layout form.
Logical meaning eg: CustomerDetails should be one section, BrokerDetails one section and say LoanDetails in one section. They can all belong to one single wrapper section but this gives a lot of flexibility. Even if the Customer Details has something which changes the details in LoanDetails section UI, you can do on-change action to refresh "LoanDetails" section without refreshing current section(CustomerDetails). In your current implementation you would do a refresh section & that will be a bad user experience.
Layout: should you be using a tabbed layout? or an Accordian so the number of fields visible at one time is say 100? You need a discussion with your BAs as well as Users to determine the acceptable behaviour.
2. Performance: A lot of the your fields are dropdowns which load data from external table - meaning you should be using DPages with appropriate refresh strategy. If the values in there are expected to be static organization wide, you could have them node level & so would need loading just once - will reduce your performance issue big time.
With 300 fields you should ensure you keep "heavy on-change actions/validations" to minimum (eg: execution of activity,data transforms etc) to avoid screen lags. Also,a section to 'display fields which have errors' for better user experience. Lastly, ensure the screen can be used via 'tabs' instead of mouse clicks and the lesser the number of 'section refresh' the better will be user experience with screen.
Best luck!
Regards,
Tanul
Pegasystems Inc.
IN
Hi SuryaM14,
Thanks for posting on PSC.
Using 300 fields on the same section will may impact the system performance because of huge data.Configuring sections with huge data is not recommended,So I suggest you to split the section to multiple section or try using screen flows if it met your use case.
Regards,
Hepsi