App feedback while loading data

The implications of loading data via AJAX are crucial in the way we interact with the user. There was a time when we didn’t care about the feedback a website gave to us, essentially, presenting new content to the user translated to a page jump. We can still say is the most common behavior throughout the web, and thus, many designers and developers might not have such preoccupations (yes, I'm talking to you WordPress peeps).

When a page jump occurs, the browser takes care of letting the user know that exchange of data is taking place. It might not be as obvious as it once was, when there were progress bars indicating a page was loading, but there is still some hint (loader icon on tab) that something's happening.

Now, when it comes to AJAX we all know that the browser won’t help you tell the user that there is something happening in the background, and here is when UI/UX best practices must take place to inform the user there will be a little delay before they get to their desired app state.

If we were in an ideal world, all applications would be blazing fast and the data would take milliseconds to render on screen, but we all know this is not usually the case.

Having a really fast application, enables you to avoid the loading message or even having a really subtle one. However, there is a good reason why animations are a great aid while loading data asynchronously.

There is a psychological response to a loader animation, it mostly eases the anxiety of a user waiting for information.

Let’s take the case of the progress bar for example.

If your server allows you to send the amount of data to be transferred in the header of a response, you are one lucky fellow who can use progress meters to show the user the percentage of the data downloaded so that they know exactly where in the load state they are. This is an advantage that makes the user feel in control of the application, cause you know, knowledge is power, and knowing how long a load will take enables the user to take decisions so that they can give their time a better use, staying in front of the screen or grabbing some coffee.

Now, lets say you are able to implement a meter for your AJAX interaction, but at some point, the network struggles a little to load those 25K left. Maybe your meter is showing the progress of multiple loads and between each file request, it lags a a few instants. These are the scenarios where your users will instantly think that there is something wrong with your stupid app.

Some users are more anxious than others, it mostly depends on how close to the beach they live (fact), but if you want to ease their pain a little, do not depend solely on the progress meter, add some constant animation to the view, so that there is the perception, that although the meter did not increase it’s magnitude for some time, the accompanying movement of a spinner or loader animation is doing some work behind the curtains, and that at any moment, progress should increase.

Let's think of an actual machine with gears and other moving parts that is going on, but doesn't show a clear transformation of energy for all of it's dynamism. You instantly get the feeling that all of those moving parts are accumulating energy for something big to happen. Then, when the machine makes it’s final display of mechanics with a big output, you validate that previous perception of a momentum build-up. But if instead of a big display of mechanics, the moving parts stop and nothing happens, you get a clear impression that something went wrong. If we extrapolate this example to what happens with progress bars and spinners, you understand the principles we use in UX and UI interactions come from previous experiences we have had out of the digital world.

There are many ways to make this happen on screen, some might actually render actual gears moving to illustrate that something is building up for you to see, but the main takeaway of what I am trying to explain, is that you might not have a progress bar, but you sure need an animation to let the user know that something is happening behind the curtains.

Now that you have chosen your preferred animation method, it is time to go further and think of the scenarios when things go bad. Yes, the undesired malfunction must be part of of our lives as professionals. Here is when things like setting timeouts at a certain time range when you consider the data should have loaded come in handy, so that you can tell users everything is being a little slow, and even longer timeouts to inform that something wrong might have happened and give a few pointers on what to do next. This enables the user to take decisions and make them feel in charge (even if the only possibility is just going away).

Treating errors is the pinnacle of UX/UI, it shows that you had plenty time to dedicate attention to things going bad with software, and users are more likely to cut you some slack if you actually acknowledge you messed up.

Who knows, they might even grant you another visit.

Lucky you!