3 ms·

These are really very nice, but they don't really convey any more information than a static picture of a puzzled kitten. Like "security theater," this is "progr

These are really very nice, but they don't really convey any more information than a static picture of a puzzled kitten. Like "security theater," this is "progress theater" and I would prefer to give my users a more useful indication of progress. I do appreciate the work that went into these, and admire the skill.

jamornh 13y ago
I agree that what you prefer would be ideal, however a lot of things that happen on the Web isn't conducive to a real "true current state of progress" loader. Actually, a lot of things that happen even on local machines are not possible to be determined in an absolute sense. That's why most progress bars seem to progress in fits and spurts, not in smooth consistent amount over time... I think this is due to some tasks just take an indeterminate amounts of time. In those cases, a progress bar isn't much better than a numbered list of things shown as "to do" and "done." In the case like client server request response, which may be asynchronous, where responses are only received when it's "done" then it makes sense why these cannot show progress... Just that it's "still waiting." Not ideal, but I can't see a better solution that doesn't require sending multiple updates back saying "still not really sure when we'll get to your request" or "just fetched stuff from the dB, 2 more tasks to do."
coldtea 13y ago
>I would prefer to give my users a more useful indication of progress Those are called "indeterminate progress indicators". Not everything on the web has some specific state info or progress percentage to declare. Just showing that "something is running" is still very useful for those situations, and can have a huge impact on the users perception of the page responsiveness. (As has lots of other "theater", which is not to be dismissed -- e.g the mobile practice of showing a screenshots of the apps last state while you load it, making the user thing it loaded faster).

jamornh 13y ago

I agree that what you prefer would be ideal, however a lot of things that happen on the Web isn't conducive to a real "true current state of progress" loader. Actually, a lot of things that happen even on local machines are not possible to be determined in an absolute sense. That's why most progress bars seem to progress in fits and spurts, not in smooth consistent amount over time... I think this is due to some tasks just take an indeterminate amounts of time. In those cases, a progress bar isn't much better than a numbered list of things shown as "to do" and "done." In the case like client server request response, which may be asynchronous, where responses are only received when it's "done" then it makes sense why these cannot show progress... Just that it's "still waiting." Not ideal, but I can't see a better solution that doesn't require sending multiple updates back saying "still not really sure when we'll get to your request" or "just fetched stuff from the dB, 2 more tasks to do."

coldtea 13y ago

>I would prefer to give my users a more useful indication of progress Those are called "indeterminate progress indicators". Not everything on the web has some specific state info or progress percentage to declare. Just showing that "something is running" is still very useful for those situations, and can have a huge impact on the users perception of the page responsiveness. (As has lots of other "theater", which is not to be dismissed -- e.g the mobile practice of showing a screenshots of the apps last state while you load it, making the user thing it loaded faster).