Streamline Web UI

This article offers valuable advice on enhancing user experience, specifically focusing on aspects related to time management, reducing waiting periods, and avoiding mistakes in creating the user interface of web applications.

Instant Feedback to User Action

In modern applications, interface feedback to user actions should be immediate, even if providing a complete response takes some time. Immediate feedback helps users understand that the application is working. For example, highlight a menu item immediately after clicking on it and start loading the content, or instantly open a dropdown menu or modal window and display their data once it’s loaded.

Separate Loading and Moving Content

If some content on the page is heavy or takes time to calculate it, gather or load from the server, make a separate request to show lighter queries first and heavier ones later. This approach prevents delays in displaying easy data and allows parallel loading. For example, load the main menu, header, and service section’s name and description first, then continue loading other data such as lists of items and their details.

But be mindful of interactive content that can change its position after loading. The biggest problem users may encounter here is misclicks. Misclicks happen if elements move just as users are about to interact with them. For instance, a user may find the correct line and intend to click on it, but just before clicking, new data loads, shifting the content, and causing the user to click on the wrong line. This technique is often used with slipping banners that replace the main button, leading to user frustration.

You can safely display content at any time if it has fixed dimensions and won’t change position after loading other content. Display content from left to right and top to bottom without altering its position. Content that can shift significantly after loading other blocks should only be displayed when all other content, which can change the size and affect this block, has fully loaded or after an error occurs in loading these blocks. Avoid showing such content or blocking interaction with it until loading is finished.

Cache the data

Another effective way to quickly show data is by using the cache if the user has visited your application before. You can display cached data initially, send requests, and update the data upon receiving a response. This method also helps optimize application performance by avoiding excessive server requests. 

However, using cached data can lead to content shifts and misclicks. Of course the easiest way to avoid this problem is not to use cached data, especially if it may be outdated by the time the page is viewed. Just always show the newest data.

But again, if you use cache  — you need to determine the average time at which data becomes outdated and adjust the application accordingly. 

There are two ways to work with cached data, based on how frequently the data might become outdated:

  1. Frequently Updated Data: If data often becomes outdated during a page view, do not use the cache. Wait for the server’s response and always show the latest data.
  2. Infrequently Updated Data: For data that remains the same across different page views but occasionally becomes outdated, use the cache. Simultaneously send a request to the server to validate the data’s freshness, and do this periodically.

Once we recognize that the data is old, carefully replace it to avoid misclicks. For example, display a message saying, “The data is out of date and needs to be updated,” prompting the user to click the “Update” button and wait for the new data. During the update, hide or block old data and show a loader.

Spinners loaders and skeletons

Spinners, loaders, and skeletons are common UI elements that indicate an application is working while content is being fetched or processed. Of course you know and use it often. Most likely — too often.

You can’t use skeletons or spinners if the page loads quickly!

If the page loads in less than 1 second, skeleton screens, loaders or spinners are not needed, as they will not positively affect the user experience. If the delay of appearing new data is less than one second and you have given the user immediate feedback on his action, the user does not notice a delay of application response. And using loaders in these situations can be frustrating, as a fast-flickering page can make users feel like they can’t keep up with the fast changing content. It creates a feeling of strange behavior and slow performance of the application.

But what if we cannot know whether the page will take a long time to load or not? 

Of course, we can’t know everything in advance, but we can not show loaders or skeletons for the first time.If unsure about load times, use a short delay (500-1000 milliseconds) before showing loaders or skeletons. Incorporate a fade animation for these elements. This way, if the page loads quickly, the delay will be almost imperceptible to the user. 

An attentive reader may notice if the page takes slightly longer than 500 milliseconds to load, users still might see a flickering loader.

Even though this won’t eliminate flickering entirely, it will significantly reduce occurrences. If you have data on average page load times, adjust the delay to further minimize this effect.

Thanks for reading! If you agree with these statements, share them on your social networks or channels!