Is the marquee loading bar bad for user experience?

Question

What is a Marquee loading bar?

The highlighted part of the progress bar moves repeatedly along the length of the bar. You can start and stop the animation, and control its speed. Marquee progress bars do not have a range or position. The following illustration shows a progress bar in marquee mode. The highlighted part moves across the bar.

I feel like these are bad for user experience because the user never knows what proportion of the task is complete as opposed to a 'normal' loading bar

When would a marquee style loading bar be preferable to a non-marquee loading bar?

Answer 1

I personally don't like marquee loading bars – though still I see a point in using them in special situations – and I think you actually point that out already: if you either don't know how long a process takes and/or you want to communicate that you don't know, then a marquee loading bar would be the right choice. And i.m.h.o in such situations it would be experienced more honest (and in that sence 'better ux') then having a progress bar e.g. stuck at 99%.

Answer 2

You are essential describing the difference between progress that has a determinate status and one that has an indeterminate status. The 'bad' user experience comes from not applying the correct design pattern to the right type of status and also letting the user know what the relative length of wait time might be. When it comes to waiting time, the key factors are the user expectation and the correct or accurate representation of wait time.

When you know the tasks to be completed and the amount of time it will take (hopefully it doesn't change during the process because it is based on some variable like connection speed), then it is appropriate to show a progress bar that reflects the relative completion status of the task. However, if it is not possible to be even relatively accurate then you can manage the user's expectation by showing them that it is going to take as long as it takes.

And if you can manage the user's expectation correctly, they are prepared to wait or go and do something else while waiting. If you provide an accurate representation of wait time, then they know roughly how long it is going to take and can therefore manage their own expectations and make a decision about whether to keep waiting or cancel the process.

If you really can't work out what the length of wait time is, and have no real way of managing the user's expectation, it is still possible to provide a good user experience by allowing the user to do something useful or entertaining during the wait time (e.g. provide a mini-game or show some interesting information/facts/trivia).

Answer 3

Progress-bar and Marquee bars both have different use cases and one cannot replace the other. We can happily argue that progress bar is better for user-experience but it still cannot replace marque control. Consider this;

An application is trying to establish secure connection with the server and server is not timely responding. It is a Boolean operation which can only have two states, not-done or done. Application is trying continuously or periodically but no one knows when the connection will be established. Application has to shows user that it is trying but can also not predict that the task will be completed in x amount of time. Thus we need a "busy" or "working on it" stats (like a marquee bar) to indicate that and this cannot be represented by a progress bar.

If you would use progress bar, the progress bar would be at 0% done and then suddenly 100% done. That jump is acceptable if in the middle, progress bar is able to show it is "working on it" which it cannot. Thus the feasible choice of control in this context is Marque Bar which tells you application is busy but doesn't provide any false of misleading info either.

Hope it helps.