There is a difference between a spinner and a progress indicator:
a spinner only communicates the wait,
a progress indicator (be it a progress bar or any other form going from 0 to 100%) communicates wait and progress.
To communicate progress, exactness it is necessary. This is why those installation progress bars, stopping at 99% are so frustrating. ...
For a wait as long as that, I would be reluctant to ask the user to wait at all.
Consider showing them a result such as "Thank you, your form submission has been accepted and is being processed, you will be notified by [method of notification] once processing is complete. This is usually within [x] minutes"
Now they can leave the form, or page, or whatever ...
If the progress takes longer than a few seconds, you should think about the user-experience. You cannot expect the user to stare at a progress bar for one minute - the user will do something else in the time, while a long progress operation finishes in the background.
If you show a progress bar it has to be accurate (so waiting time can be inferred by the ...
Besides all mentioned above, I would suggest adding intermediary updates, e.g.
Yet still loading...
If the text changes it'll give a clue to the user that process is not hanged.
Depending on your app personality messages can be humorous or formal.
Why not make a cup of tea?...
Or even hot ...
Ideally, all three categories should be placed alongside each other horizontally because they are of the same nature and pertain to the same kind of elements. Requiring the user to scroll downward through them, especially when some are longer than others or off of the screen, will make retrieving information from them much more difficult -
Although you have ...
If you can't make the wait informative, at least make it entertaining.
For example, on a certain web site Bill Shatner makes some funny faces and hand gestures while a notoriously slow system is interrogated. You may not be the best person to build that humor, but perhaps you can consult with your business image or marketing team and ask them to suggest "...
Assuming one minute is as fast as your process is going to get, and this is a critical component, I would consider coordinating with Engineering to modify the approach so it no longer takes place in a long-running API call.
Here's a high-level approach to a user experience similar to what you might see on something like Dominos Pizza's order tracker:
My 2 Cents:
From a developer Point-of-view it is "plain stupid",
But as a business decision, it is "Genius!".
Consider this hypothetical situation:
You go to a fortune teller,
Ask: "when will i die?"
It instantly answers: "5th, June 2049"
No crystal ball, no humming, anything...
? what would you think ?
Example of an instance of intentional delay:
I know ...
The answers here seem to assume (incorrectly) that a SpinBox is constrained to only adjusting the number using the provided up-down buttons. I've never seen this be true.
If anything, a SpinBox is a desktop convention provides the following:
A visual cue that the TextBox is expecting a number.
Allows the textbox to be incremented and decremented using the ...
iOS calls this a "stepper" (usually associated with some feedback of the value)
A "spinner" on Android is similar to what you are referring to, though there are no increment buttons
And what I would call a "loading animation" is called an "Activity Circle" or "Activity Indicator" on Android & iOS respectively.
Android Guidelines (...
You (literally) can’t make the user wait
There is no “magic message” that will keep users from putting their phones back in their pockets when they aren’t getting the info they want. Literally, they will not wait.
Granted, network connectivity or “Lie-Fi” conditions are often beyond your control. The user may recognize this as well — but that will only make ...
In my experience, users overwhelmingly prefer the precision and ease of keyboard entry for numbers (and dates and other data that can be specified via number) over "analog-style" controls such as the spinner. This will most definitely be true on the desktop. For mobile, just make sure that you specify an input type that will pop up the calculator/phone-...
[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 ...
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 ...
@Karen covers the Spinner vs Picker question. Regarding the ActionBar vs Toolbar question:
Definition of Toolbar
A Toolbar is a generalization of action bars for use within
ActionBar was the first design introduced in Android v3.0 (Honeycomb). It was liked, but difficult to extend beyond the specific use cases Google initially ...
Typing is the fastest way to enter the information.
There is nothing wrong with letting the user type in the values, provided you have appropriate validation on the field.
(If the value being entered was something approximate, I might have suggested a slider, but that would be too fiddly for selecting precise values such as frequencies.)
I really do not like spinners. For several reasons.
The up and down buttons are typically tiny and adjacent to each other, which creates unnecessary user frustration with getting to the right button. This is especially true when users are on trackpads or ipad, because of the combination of fuzzy finger focus and "click-shift" with certain trackpads.
Have you seen this in any production apps? (That is to say, I guess
you'd have been on the development team - as you wouldn't
necessarily know about it, I guess, as a user!)
Yes, I think most of us have probably also done this because they like to see their clever little loader... but then move on. A loader should IMO only be used when something takes ...
Good idea, indeed.
The whole idea of a Spinner is to have the user know, there's something happening in the background so they will need to wait until it's done.
Especially in the case of a network connection, Spinners have been required since the reception of the network as well as the speed cannot be determined and is subject to change. Networks also ...
Wordpress does it, too. It’s better than no feedback or just a meaningless spinner, but worse than showing content immediately, which is the case sites should be optimized for. It’s really annoying that in 2016 small text fragments and a thumbnail image on billion user billion dollar sites don’t appear in zero time on a reasonable fast connection and ...
General practice seems to be the following for "loaders" / "spinners" these days:
Loader in the center of the screen with blurred / dark / whitened background
Loader on button is great as well, if you don't need to reload the whole page. But instead of using only a "spinner" you should indicate the progress with words as well, like: "Saving", "Saved" / "...
It is very likely that your target audience has certain common durations of loan. You can present these choices as quick list [max 5-7], and allow adjustment afterwards. If you don't yet know the common durations, record what users of your system input.
Duration of loan
other duration... [when this is selected then ...
Which bug report would you prefer reading:
The spinner just keeps spinning.
Progress is temporarily stuck at 78 %.
The app takes very long to perform the "Rectifying delta wave" stage, ten times longer than the estimate of the one minute given.
Yes, the latter may not be something the user understands, but nonetheless this is the information you as 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 ...
I feel that it depends. To be as unobtrusive as possible, if the settings that you are referring to, does not impact the immediate usage/experience for the user, we could just use option 3 - Immediately close the dialog + spinner on the settings
However, if the experience of the user depends on the settings that he has invoked, I would generally prefer to ...
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.
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.
Let's see it this way,
The year might not have a maximum value. The value for month cannot be more than 12. If it crosses that, it would add up to the year.
You can have a simple input field for the year and a select type for the month. This would restrict the user in entering proper information without writing code for validation. Of ...
Obviously, the perfect answer would be "Zero Loading time is always better" ; we all know reality is different.
Use dummy data will make clear to your users that only data are loading, not the whole interface. This will really increase their opinion of your service or app.
In my opinion, the best option would be to use dummy data AND a "Skeleton" of your ...