According to Material.io, these UI elements are called progress indicators:
Progress indicators inform users about the status of ongoing
processes, such as loading an app, submitting a form, or saving
updates. They communicate an app’s state and indicate available
actions, such as whether users can navigate away from the current
Perception of time is a tricky one, as it really depends on the expectations of the user.
A loading screen / animation allows us to give an immediate response to a user action when the result of the action is going to take more than 200ms to display something on the screen. It reassures them that system registered their action.
Any user action that has an ...
That's a progress indicator.
I think Flickr might be the first one start using this in early days, that will be back at least 10 years ago, then Material design release an official doc and usage for this.
...authentication can take anywhere between 3 seconds and 1 minute...
I'd recommend starting with your basic animation, then add additional feedback as time elapses.
A video game I play often, Rocket League, does this when you begin to search for an online match. It begins with the simple message (the first in the list below) then adds ...
My answer is a bit simpler than the others.
I think your answer is in the tests you made already.
Ask this question:
What was the average time after people showed signs of hesitation when
waiting to login?
Once you have this measurement then you know that you should give "reassurance" some seconds before this. Or even some seconds before the ...
I believe none of the examples.
I would prefer to start loading the HTML and CSS skeleton of whatever that button must fill.
Let's suppose that when the users clicking on the button it makes a REST request to fill a table, as soon as the user clicks on the button, it starts loading HTML and CSS skeleton, that time in animation is used as a waiting time for ...
The answer what is the most user-friendly is always it depends.
Depends on a lot of factors the main one is who is your target audience? What is their knowledge and mental models.
For this example, as I have no idea about the context of the action, I would recommend thinking about few things:
What action that user took? (action)
What did they expect to ...
[click]↖ => [click] ↖⚙
This can be very confusing for the user, as they don't specifically know if a process is being run on the website or on their pc
[click] => ⚙
This would have been great only that, it doesn't pass enough information to the user
[click] => [ ⚙ ]
This is similar to the above option still not much information passed, the extreme ...
How frustrating would it be to manipulate something that is still changing? I think the answer is "very."
There is something called "moment of interactivity" and it can be progressive on a page. If the navigation is ready, show that, if another element is ready, show that too. But if a component is not complete, don't show it until it is. Otherwise, you are ...
Since this only occurs once at startup and users are accustomed to programs loading, Option 1 makes more sense. Could you have this information load with the program and extend the splash screen loading time so that the program loads with the information ready?
To answer your title question, the user should not be allowed to manipulate a list before it is ...
Considering left-to-right mentality, I think, the difference is this:
If it’s to the left, the user will read it as “we’re working, and here’s why...” - they’ll “read” the indicator first and then, if confused or interested, the description for it that will clarify what’s happening.
If it’s to the right, the user will read it as “we’re doing this and this,...
If it is close to 10secs or above then yes an indication of what is being loaded and how much is the progress should be added (source)
Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation.
Nowadays a spinning circle is a good enough indicator of loading.
However it might be a good idea to preload some data for the map, rather than leaving it an empty rectangle. This way people can also see what is loading.
The intent of a skeleton page is to shorten perceived loading time. If your filtering requires a re-loading of the page data, then, sure, it could make sense to use it there.
That said, and this is just my opinion so take it for what it is: I'm not convinced skeleton pages have much staying power to them in terms of them accomplishing what they were ...
Like exp mentioned in the other answer, both the approaches have different narratives that makes sense. Adding to that:
Visual designer can direct the flow of reading in a correct way. Though having an icon to the right may appear optically balanced, the reading flow will be broken because of the bold stroke, dark colored icon. Adding to it the animation ...
I would never change the mouse cursor.
IMHO, best UX is to disable the button as soon as it is clicked and change the button text to 'Please wait...'/ 'Loading...' .
Call it old fashioned, it works best for web as well as mobile layouts.
Changing the mouse cursor is not a good idea and is likely to confuse the user. The busy spinner is a consequence of an action taken by the user, so it must be shown in relationship with this action.
The spinner must be visible enough not to be missed by the user. If you only replace the text inside the button, or make the spinner appears within the button,...
As maxathousand suggest, you can improve the wait spinner by providing a progress message (or even a fake progress bar). My only addition to that suggestion is to use "Less than 1 minute" instead of "up to a minute." This suggestion comes from the book Designing and Engineering Time: The Psychology of Time Perception in Software, and you can find some tips ...
How to decide on a speed for the iteration of a loading spinner... ?
Experiment 1. Show users random pairs of spinner speeds. Have them choose their preferred speed of the two. Repeat.... Repeat... Repeat... Use the speed that appears to be most preferred.
Experiment 2. Randomize the speed of the spinner for different users. Monitor users to see if spinner ...