Tag Info

Hot answers tagged

64

You should not artificially delay how long a user must wait. Do not punish a rapid response by slowing them down to an "average". Let all queries complete naturally, for longer query times you may want to consider the following... Jakob Nielson did some research on wait times back in 1993. From "Response Times: The 3 Important Limits" - (1) 0.1 second ...


63

Showing details in a form not only developers understand is fine. If you are able to write your installation details in a more funny way than just "Checking Operating System Version" this might have two advantages: The user gets feedback about what's going on and that there's something going on at all. When installing e.g. a computer game you normally have ...


49

If your app loads instantly, then don't add it. Especially not when it creates (forces) an completely unnecessary delay. Splash screens just serve the same purpose as loading spinners: giving the user the reassurance that their action was seen and is having an effect, plus subjectively shortening the time it takes to load.


33

It can be useful for several reasons. One is that the user gets a feeling of that something is actually happening and not just a progress bar increasing. If the UI says "Checking OS Version" or "Initiating virtual processor" she gets a feeling that something good happens, even if she doesn't know the technicalities behind it. Second, if the process would ...


32

As an analogy, consider the mirrors universally installed in elevators. While these mirrors give the user a false sense of added space in the lift, they also serve as just mirrors; people tend to look at themselves and do not seem to notice how long the lift is taking to take them wherever they are going. But if they put in a countdown telling people 'xx ...


27

Management is principally seeking brand recognition. The same desire drive Coca-Cola to put their logo on everything they can buy. If the app, when running, has a visible logo of the product or company, then you should be able to make the case that brand recognition has been served. You could probably make the case that it's better served that way, since ...


24

There are situations in which adding a delay will help in building a 'trust factor'. While the conventional UX wisdom dictates that faster feedback is better, sometimes, it is better if you slow down the thing to a level at which the user can imagine the things happening. Here is a Hacker news thread touching upon the same conversation: Locksmith gets less ...


20

I am very surprised this comic hasn't been mentioned in an answer already. Admittedly, the question is asking about a short delay and these sources come from the era when every 'hip' website had a 'super-cool' animation which wasted 30+ seconds of your life (and bandwidth) for no good reason. Courtesy of The Oatmeal (crude humor warning) and idea inspired ...


14

This is the most compact and intuitive way to present an indefinite progress. The key word is indefinite. source I can hardly imagine an indefinite linear solution. For example, a common progress bar in indeterminate mode looks a bit unclear: source BTW, circle is a very useful shape (just want to make your day better :) Round-robin - The ...


13

showing what the program is doing while working on a progress bar gives an additional indication of progress. There is also a nice way of doing this involving a details screen: This method doesn't just show the progress of the installation as a whole, it also shows what the current step is, what the previous steps is and sometimes even the progress of the ...


12

I can't recall the study, but it has been found that the perception of speed is heavily effected by the time to first action. So my suggestion is a 4th option: Load the bare minimum that is needed for your customers to see the app and decide what they want to do. Basically what you've described as option 2. Automatically put the other modules into a ...


11

I'm assuming this question was incited by: How and when should you use animation in your application? I definitely do believe that if loading time cannot be improved, distraction is a good technique. Examples: github.com , as well as the popularity of having interlaced .png's. Maybe the term "distracting" would only apply to stuff sub 750ms, and after ...


10

Ideally, we'd always be able to give the user an estimate of the amount of time remaining. Visually, this is usually done through the infamous progress bar. However, certain activities such as waiting for a stream to buffer are difficult to estimate completion for. Most, if not all, progress bars have some sort of "indefinite" state available to programmers ...


10

I like the accepted answer and I agree that you should not artificially delay anything. However, given your expected wait times, I'd do what you can to improve perceived performance. For instance, showing a spinner while the results are loading helps. But according to this study, it's optimal to wait 0.4 seconds before showing the spinner. There's another ...


10

Over 30 years ago I was what at the time we called a systems programmer, looking after a minicomputer network with a few dozen users. In those days, the displays were essentially 80x25 "text only". When we upgraded the comms links between the minicomputer and the displays, several users started complaining that the system was slower, even though we knew ...


8

Does the user need all the parts to be loaded to use the page effectively ? If so, then going with the approach of loading parts separately might not be a good experience as users might want to interact with these parts and find that they can only partially interact or not interact at all might ruin the user experience. However if you can interact with the ...


7

If someone performs an action (usually selecting a button / icon), you should respond to that action as fast as you can. What that response is may vary, but if you delay responding while you get some data, it will appear that your app is sluggish and the person may think that the action wasn't recognised. Now, how you respond depends very much on your app. ...


7

I read through the Wait Indicator Pattern from Designing Mobile Interfaces (http://shop.oreilly.com/product/0636920013716.do). First of all, I could not find anything against this practice, but it wasn't mentioned anyway. You definitely have to consider the possible problems with your approach: Can the user still select content after he has clicked the ...


7

No, they don't care about the details. But the great thing about it is that they know exactly what is happening, it feels like he/she has control.


7

I would argue that "8~15 seconds" could in fact be long enough for an impatient user to navigate away or to think the app may have crashed. Changing messages is therefore useful as an indicator that something is happening and conveys a little more "why" of waiting than a buffering circle or similar. Whether the messages are of importance to the actual ...


6

A progress bar should show actual progress. If you are simply showing 85% at some point, it's not really an indication of progress, and users will soon learn to ignore it. If you have more specific information on the progress, you should use that. Otherwise, I would recommend a simple spinner or some other indicator that the process / program is still ...


6

The most important thing is here whether page rendering is blocked by the image download (or if the page is incredibly ugly or unusable before images load). In your specific example the rendering isn't blocking anything (though the text shifts a bit for me in Chrome). Remember that rendering time is more important than total download time; this is "Time to ...


6

As Marcos Ciarrocchi correctly pointed out,what users are more concerned about is the perceived time which it takes for your site or app to load than the actual time . To quote this interesting article which states that users are more concerned about how well and how quickly they can get a task then then worry about the initial load: When we began our ...


5

Raymond Chen (legendary Microsoft dev) is renowned for his opinions on this topic. As it happens, the post I've linked to includes one case where this behavior might be considered reasonable: This application will be run on dedicated machines which operate giant monitors in retail stores. There are already other applications running on the computer which ...


5

There does exist some research suggesting that, at least for certain types of applications (real-time strategy games, to be exact), users may find a slow but consistent response time preferable to a unpredictably varying one. Specifically, let me quote from the article "1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond" by Mark ...


4

The old way of showing a loading indicator always had the term "Loading..." or something similar on it. That is really a legacy requirement as when they first came out people didn't know what they were. These days it is not necessary to show text with it. The Android HIG for example suggests using a simple spinner with no text, which I agree with. When ...


4

Assuming this is an application destined for Windows, I recommend turning to the Windows User Experience guidelines. Specifically: Progress Bars Modal indeterminate progress bars Indicate an operation is in progress by showing an animation that continuously cycles across the bar from left to right. Used only for operations whose overall ...


4

Don't waste user's time just because the visuals look good. 2 seconds is plenty of time to frustrate the user if it happens every time - and will make the site appear really slow because nothing appears to happen fast. It's important to provide feedback and confirmation of completion - but not to fake it like that. In any case, a lightbox is a distraction ...


4

The users really care only about the perceived time, which is not often the same as the actual loading time. In that sense "distractions" are just another form of feedback, just like the progress bars and loading animations, but they reduce the perceived time to load. The Github example is really good and if you take a closer look you'll see that in the end ...


4

I agree with other posters that you shouldn't have a splash screen for an instantaneous start-up. A splash screens is an admission that the program is frustratingly slow to load. However, if your management still insists on it, a suggestion is to load the splash screen over the initial window and immediately fade it out, taking no longer than two seconds to ...



Only top voted, non community-wiki answers of a minimum length are eligible