Progress Bar
About
Most progress bars are fake. While the progress bar pattern is designed around a part-to-whole relationship, with the whole being the total size of some task and the part being the portion of the task that has been completed so far, the true purpose of a progress bar is just to show that something is happening.
The actual progress usually doesn’t matter.
This is a good thing, too, as the actual progress is also often impossible to know. When performing a network request or other asynchronous action online, an app has no way of knowing how far along the remote process has progressed. It only knows the beginning and end: when the request begins and then when it succeeds or fails. And so for most apps that feature progress bars, such as Apple’s Safari browser, the progress bar will advance by a certain amount, slow to a crawl, and then rush to complete.
Why fake it?
A good user interface provides feedback to its user. Feedback is especially important when a user action prompts some delayed or asynchronous action, such as downloading a file, initiating a process, or submitting a request that must be validated by a server. Whenever a design must ask a user to wait, it’s important that the user know that they’re waiting: otherwise, the user is likely to believe that their action hasn’t been received, or that they’ve frozen, broken, or otherwise killed the app.
No one likes to wait, but waiting can sometimes add value to what comes next. Comparison apps, especially in the security and travel industries, often introduce artificial waiting in order to make their results feel more valuable, more like the patient output of heavy bespoke calculations. It works.
When waiting is just waiting, be sure to choose your progress bar carefully. In one famous example, Facebook found that by replacing their branded loading indicator with a stock device spinner, users were more likely to blame their device for the delay rather than Facebook’s service.
No matter how well you design your progress bar, your user shouldn’t have too much time to appreciate it!
Tips
A progress bar has three states: idle, loading, and complete. (In actual practice, it would also has a fourth state, error). In addition to designing each state and working out the transitions between those states, be sure to also protect against certain events in certain states. For example, whatever event brought the user from idle to loading should no longer work once they’ve reached that loading state.
If you’re expecting a long load, offer an option to cancel the process.
If you want to experiment with Apple’s misleading-but-effective progress bar animations, try using an animating with Framer’s Keyframes feature.