It has happened to all of us. We are using a web or mobile application, we are going to click on a button or link to execute some action, and at that same moment the content is updated, so we are left clicking on any other element and we do not know where the button or link that we were going to click was.
At the user-centered design and development level, these types of common errors can be measured through a metric known as “Cumulative Layout Shift (CLS)”, which is basically defined as:
(…) a measure of the largest burst of layout change scores for each unexpected layout change that occurs over the entire lifespan of a page.
A layout change occurs whenever a visible element changes its position from one rendered frame to the next.
This metric categorizes content rendering into three types:
- Good: CLS below 0.1.
- Improveable: CLS between 0.1-0.25.
- Needs improvement: CLS above 0.25.
Generally speaking, if the content within a view frame changes completely, the CLS metric would be 1.0.
#.Why does content change usually occur?
Usually the change of content (and its position) occurs when we perform an asynchronous loading of the contents of an application. This is increasingly normal when using libraries such as React, Vue or Svelte, since the content of the site is reactive to user interaction, so the loading of this content will depend on certain states.
Let’s give a practical example, using React:
For this example, we have a small shopping cart. This shopping cart looks for the order (which for practical purposes is a simple timer) and after 4 seconds it shows the table with the list. Nothing complex.
If we note in detail, the table, after being filled, will move the “Place Order” button down, so the user experience may be affected by moving the content.
#.What can we do to improve this metric when developing our applications?
When developing user-centered applications, we must first collaborate closely with the interface and user experience designer and ensure that the design considers cases like the previous one.
If we use the previous case, we have two options, which are applicable for almost all cases:##### Technique 1: Let the content grow, but position the action items outside this area
This option is usually the simplest and easiest to carry out. The solution, using the example above, would be to move the “Place Order” button above any content that may be updated in the future.
This way, we don’t run the risk of the action item’s position varying over time.
This option is widely used in mobile interfaces, for example, when we position the trigger elements either in the header or footer of the view frame.
#.Technique 2: Save the slot while loading and make the saved slot static
For this other option, the solution is somewhat different and we can use some simple patterns. Likewise, we require more use of styles to ensure that the experience is not affected.
For example, we could configure a maximum space for the products table, add some type of loader (a Loading box, or the now common Skeleton Screens) and use scrolls only for this content area. Likewise, we can use Placeholders, either in text form or simply making sure to respect the same area once the content is loaded.
For example, if we apply this option and with a little use of CSS, we can achieve something like the following:
In this adjusted example we will see that we make the following changes at the code level:
- We configure a static
heightfor the area where we will put the content. - In the same way we use
overflow: scroll, in case the content grows. This way, if the content is larger than the space we save, the lower content will not be affected in its position. - If the upload is still taking place, we display a text of
"Cargando ...". This is to illustrate the concept of Placeholders. The correct thing to do would be to show content similar to what is going to be loaded or use something like a Skeleton Screen.
⚠️ This is a merely illustrative example of the technique. The result is a bit poor, but with this we can understand an easy way to attack in a similar situation.
In fact, in the last point, we could make an even greater effort and only take care of filling out the parts of the cart that are really going to vary, for example the total amounts and the list of items. That would further benefit having a better measure of CLS.
So we could improve this example by doing something like the following:
In this case, we only alter the really dynamic part of the content, such as the product list or the shopping cart breakdown up to that point. In the same way we separate the minimum space while loading the information.Still, neither of these two techniques will be effective in improving the user experience if loading and rendering takes longer than 500ms, so it is extremely important to be able to speed up content loading as a first measure.
#.Other Resources
- Cumulative Layout Shift (CLS)
- [Everything you need to know about skeleton screens
](https://uxdesign.cc/what-you-should-know-about-skeleton-screens-a820c45a571a)