Always display "progress/load" or only when a request seems to take longer than expected?

Question

My question is about ux (user experience), it is not about material-design and the like and it is also not about "think", but about some experience in this type of functionality that has already passed with users, let’s go to the problem:

I often notice two different situations:

1. A load is always displayed, even if the response is quick (or not), an example of this is the votes of the site https://stackoverflow.com, by clicking to see the difference of downvotes and upvotes is displayed always the load:

   

2. Do not use load, because usually requests are quick, but these developers forget things like oscillations due to "overloads" or some temporary signal loss (this is independent of HTTP, the oscillations can be even in local programs, caused due to another program consuming the same resources)

In the first situation I felt (of the votes in the https://stackoverflow.com) that the load was so fast that perhaps it was not necessary, so my idea to solve this (what would be almost like an answer) would simply detect if the data request is taking too long and then show the load if necessary, for example (I did it in html+js, but it applies everywhere):

var rapida = document.getElementById("rapida"),
    lenta = document.getElementById("lenta"),
    resposta = document.getElementById("resposta"),
    container = document.getElementById("container"),
    tempoMinimoParaExibirLoad = 500; // Se em meio segundo não tiver ainda a resposta será exibido o load

rapida.onclick = function () {
    requisitar(100); //Simula uma requisição rapida (1ms)
};

lenta.onclick = function () {
    requisitar(5000); //Simula uma requisição rapida (5 segundos)
};

function requisitar(delay)
{
     var timeout = setTimeout(load, tempoMinimoParaExibirLoad, true);

     setTimeout(enviarResposta, delay, delay, timeout);
}

function enviarResposta(delay, timeout)
{
   //Se a requisição for rapida para o timeout do load
   clearTimeout(timeout);

   delay /= 1000;
   resposta.textContent = "Sua resposta levou " + delay + " segundos";

    //Remove classe in-load se necessário
    load(false);
}

function load(mostar)
{
    container.classList.toggle("in-load", mostar);
}

#container > div {
   padding: 10px;
}

#container .load {
    display: none;
}

/*Exibe o load acaso a requisição esteja demorando*/
#container.in-load > .load {
    display: block;
}

/*oculta outros elementos durante o load*/
#container.in-load > :not(.load) {
    display: none;
}

<div id="container">
    <button id="rapida">Requisição rápida</button>
    <button id="lenta">Requisição lenta</button>
    <div id="resposta"></div>
    <div class="load">Carregando...</div>
</div>

---

Of course, this is a perception that I have of how the experience would be better for the user, but I would like to see some response that would state that something like this can actually hurt the experience or that there are better approaches or even how to improve this approach. I really hope the question isn’t too subjective.

Answer 1

According to Jakob Nielsen of Nielsen Norman Group there are three main time limits (which are determined by human perception skills) to be remembered when optimizing web and application performance.

• 0,1 second is the limit for the user to feel that the system is reacting instantly, which means that no special feedback is needed except to display the result.
• 1.0 second is the limit for the user’s thought flow to remain uninterrupted, even if the user realizes the delay. Normally, no special feedback is required during delays of more than 0.1 but less than 1.0 seconds, but the user loses the sense of operating directly on the data.
• 10 seconds is the limit to keep the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while awaiting completion of the computer, so they should receive feedback indicating when the computer expects it to be done. Feedback during delay is especially important if response time is highly variable as users will not know what to expect.

Source: https://www.nngroup.com/articles/response-times-3-important-limits/

As the question is more focused on the instant answer (range less than 1s) I will focus on this other example from Nielsen himself. 0,1 second is the response time limit if you want users to feel that their actions are directly causing something on the screen.

For example, If you click on an expandable menu and see the expanded version in less than 0.1 seconds, it will be as if you had opened the menu yourself. If it takes more than 0.1 seconds for the expanded state to appear, the response will not seem instantaneous - instead, it looks like the computer is processing something to make the menu expand.

In that article by Smashing Magazine the author addresses one of the points for do not use animations for response times less than 1s. According to him the "blink" of an image on the screen can cause a certain discomfort to the user, because see the image on the screen for a fraction of a second and fail to identifythere or understand what happened can leave the user confused and with some anxiety for not understanding what happened on the screen.

The fact is that yes, Loader is a valuable indicator of feedback for the user, they mitigate the negative effects of waiting time. Even why you should always provide feedback to the user about what’s going on with the app or page.

See below that:

These figures are based on the particular qualities of the Human Brain. Any Animation Shorter than 100 ms is instantaneous and won’t be recognized at all. Whereas the Animation longer than 1 Second would Convey a sense of delay and Thus be Boring for the user.

Translating:

"These figures are based on the particular qualities of the human brain. Any animation less than 100 ms is instant and will not be recognized. Whereas animation with more than 1 second would convey a feeling of delay and thus can be annoying for the user."

Source: https://uxdesign.cc/the-ultimate-guide-to-proper-use-of-animation-in-ux-10bd98614fa9

---

Points to consider

Loader Undetermined x Determined

For times between 2 and 10 seconds the ideal is to use animations of the type undetermined, as a spinner infinite. If the time is greater than 10 seconds it is advisable to use an animation of the type determined and with progress indicator. This gives a peace of mind to the user to know that their action is in progress.

Speed x Time

^{Here is a particular opinion, I found no reference on the subject.}

Look at these two examples of animation. They’re the same, but they’re at different speeds. Notice how the one that spins faster also looks like it’s processing faster. The slower animation in turn gives a perception that the process is also slower, even though it is not...

Another example is with Load Bar. These two bars complete with 2 seconds, but the larger bar may seem to be faster, and the shorter bar seems slower. Also the larger bar has a ease-out, or its animation starts slow and accelerates to the end. This further increases the perception that the process is ending fast.

OBS: a progress bar should never stop or be stopped, as any pause may indicate that the process has failed and may provoke some undue or unnecessary action from the user.

Another example, of how the Ease can interfere with the perception of the speed of the animation, see that the two animations are equal, but the one above seems slower because it is linear, but the two have the same duration! I suggest you consider the use of ease for animations with more than 1s, because the effect can change the real perception of what is happening. In animation with less than 400ms, will be so fast that will not make the user change the perception of what happened (it’s just a hint).

The fact is that the ease can be confused with a performance delay or connection speed or something similar to yield drop in longer animations. Then consider the use according to the type of animation! In a load bar for example I do not indicate, even if she has less than 400ms.

My tip is that for times between 2s and 10s use spinners or bar load undetermined and with a higher speed in animation. For longer processes than 10s use animations determined and with a size a little larger than conventional, this will make the animation fill wide spaces, giving the impression that is completing faster.

---

A curiosity

When users were introduced to a custom upload animation in the Facebook iOS app (left), they blamed the app for the delay. But when users were shown the iOS system spinner (on the right), they were more likely to blame the system itself.

So when the animation of the standard operating system Oader was displayed the user tended to believe that the slowness was caused by the device. But with the Facebook Custom Download the user believed that the slowness was caused by the App itself and not by the device.

Source: https://usersnap.com/blog/progress-indicators/