How best to implement it, what is the operational limitation
preventing such percentage control?
The main cause of limitation is very simple: there is no way to know the "total" of the processing before actually performing it. Consider the simple example of listing all files in a folder recursively. If you knew how many files there are in all subfolders, you could calculate a percentage and increment it with each file listed. But in general you don’t know that. Therefore, there is no way to calculate this percentage and, consequently, there is no way to inform the user any actual estimate of termination. The most you can indicate is that the search is in progress.
Why it is more important for the user to know the loading time, the
that the page actually load faster (up to why transitions
of this kind include several libraries, which reflect in some way on the
performance)?
This comparison is not very correct as they are different problems. First, the loading time is a matter of efficiency - one of the aspects of usability). Regardless of showing or not progress is desirable that the execution is as fast as possible not to make the user stay waiting. Waiting time is idle time (Idle), and almost always hurts the experience. Second, the progress bar is a matter of feedback and sense of control (only when an option to cancel accompanies the progress bar) - two other aspects of usability. In relatively long tasks, the user needs to know that the computer is performing the task and ideally needs to know how much time is left for this task to be accomplished. Only in this way is the user able to reflect on the use he will make of his own idle time. What’s more, the ability to cancel this task gives the user an important sense of control, because based on the progress information he can decide whether or not to wait for completion.
In short, what should be done is to try to develop the system to carry out the tasks as quickly as possible. When there are long tasks (something that can be inevitable depending on the problem domain), one should always provide feedback information (even if it is estimated more comprehensively - for example, one could estimate the progress based on the folder count of the first level, on the file listing example given above), and provide a way for the user to cancel/stop this process. In fact, it is quite common to perform this operation asynchronously, that is, without preventing the user from using the system for other purposes while the task is in progress (which does not eliminate the need for feedback).
I find progress bars with percentage simply illusory, because they do not really represent the time taken by the application. One approach I use is a circular image running, like when win10 starts that load image, I think the main experience for the user does not and know the time it took, but rather have the feeling of progression. that something is really happening.
– Marcos Marques
It is possible to do something that illustrates ALMOST the actual page loading. It is not possible to calculate the page load itself without it having been loaded before, but I think it is possible to implement a script that counts the number of asynchronous elements on the page (such as img, iframe...) and with a
onload
within aloop
calculate the percentage displayed to the user. When all elements have been loaded, display the 100%.– Sam
Dude, if I’m not mistaken Flickr did just that with the help of Node. It exists the actual % of files to be shown and uploaded.
– user86267
Dude, see if it helps you. https://w3c.github.io/navigation-timing/ . I found his approach to trying to calculate total time very interesting. Otherwise just use the values in the bar you want.
– Marcos Marques
@Marcosmarques, sensational article, thanks for this tip!
– Felipe Duarte
> What is the best way to implement it, what is the operational limitation that prevents such percentage control? I don’t know, but I saw in the gringo that lib solves the job: Pace.js.
– Ruben O. Chiavone