Guidance for UX Performance Optmization

cbrookes
New Contributor

Guidance for UX Performance Optmization

Hi All, 

We've had some issues with the UX performance and are in the process of trying to fix it. 

Our first step in fixing these performance issue will be to optimize our models formulas using best practices outlined in the Planual and community resources such as this excellent article on formula optimization.

I'm curious if there is any guidance on best practices related to UX performance. I've read the Planual and there isn't a lot on UX performance. For example, are there limits to the number of cards that should be published on a board?

I'd love to hear any best practices any of you follow related to UX performance.

Thanks,

Chris

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
andrew_martin_1
Occasional Contributor

Re: Guidance for UX Performance Optmization

Hi all

 

As @ArunManickam pointed out, a poorly performing model will manifest itself in the UX just as in classic. So if the experience for users is slow when changing data, running actions etc, then optimising the model will definitely improve things.

 

Similarly if you have very long lists as selectors or in a grid, this can degrade performance as the selector renders or the grid scrolls.

 

However, pages do render as you scroll now, as do grids with lots of rows. So the time it takes to render the top of a long page in the browser is less than when the whole page was loaded before seeing it. However this does mean that when you scroll down, it has to render the next view as you go, which obviously takes a little time.

 

I too have had to challenge this "everything on one page" request from some customers. In general, the more cards on a page there are, the longer it takes to render. But on pages without endless scrolling, the differences are marginal. So a design paradigm to focus users on specific areas when they visit a page, and have multiple pages for each part of the process with a well designed navigation, will perform better than trying to shoehorn everything on fewer, longer pages. This is good practice anyway, not least because it enables the page builders to deploy the best page types for each focus area.

 

Hope that helps!

 

Andy 

View solution in original post

4 REPLIES 4
rob_marshall
Moderator

Re: Guidance for UX Performance Optmization

@cbrookes 

 

Formula optimization is key and that article is great.  I would also recommend taking a look at this "check list" as well.

 

https://community.anaplan.com/t5/Model-Optimization-Checklist/tkb-p/model-optimization

 

As for the UX question, let me reach out to Andy Martin.

 

Rob

cbrookes
New Contributor

Re: Guidance for UX Performance Optmization

Thanks, Rob! That's a great resource. I was just searching for something like that earlier.
ArunManickam
Master Anaplanner/Community Boss

Re: Guidance for UX Performance Optmization

Hi Chris,

 

I have not seen an article specifically for UX Performance. Modeling is the first one to look when it comes to performance.

 

My few cents, Users want everything to be on a single page, which makes it crowded and slow.  Having more cards in a page make the page to load slow. We ended up splitting the pages which improved the situation.

 

Thanks

Arun

andrew_martin_1
Occasional Contributor

Re: Guidance for UX Performance Optmization

Hi all

 

As @ArunManickam pointed out, a poorly performing model will manifest itself in the UX just as in classic. So if the experience for users is slow when changing data, running actions etc, then optimising the model will definitely improve things.

 

Similarly if you have very long lists as selectors or in a grid, this can degrade performance as the selector renders or the grid scrolls.

 

However, pages do render as you scroll now, as do grids with lots of rows. So the time it takes to render the top of a long page in the browser is less than when the whole page was loaded before seeing it. However this does mean that when you scroll down, it has to render the next view as you go, which obviously takes a little time.

 

I too have had to challenge this "everything on one page" request from some customers. In general, the more cards on a page there are, the longer it takes to render. But on pages without endless scrolling, the differences are marginal. So a design paradigm to focus users on specific areas when they visit a page, and have multiple pages for each part of the process with a well designed navigation, will perform better than trying to shoehorn everything on fewer, longer pages. This is good practice anyway, not least because it enables the page builders to deploy the best page types for each focus area.

 

Hope that helps!

 

Andy 

View solution in original post