This has bugged me for quite a while, what is the proper way to do progress bars? There are times you have no idea the total number of iterations you’ll be doing prior to entering a function, like a nested lookup. Sometimes you’ll have to gather a bunch of stuff that is conditional.
What is the proper way to do this? do you have to essentially go through the function twice? or at least the data twice?
For example say in maya you had to show a tree of a scene with n objects, in this tree you were displaying an attribute value and only include it if the attribute was greater than a certain value. So going into this, you have no idea how many objects will be there and this lookup is the slow part you’re trying to give progress on. Is this just a case of show a spinning progress bar?
This is a good question, it really is. :nod:
Normally I know the amount of tasks that shall be down when showing a progress bar, that’s where a standard bar fits in very well. Running twice over your data without a real demand is never a good idea.
A spinning bar seems a good idea, for instance, Windows does the same. If a certain task/job is unpredictable or a process is pending due to some reason, it shows the bar in a so-called indeterminate state.
I recently wrote an asset browser to work with all our game assets. In fact, since the amount changes dramatically every day I can’t really know how many entities I have to load. That’s why I initially fire a query for the row count of the database to have a maximum for the progress bar.
That works fine for this certain purpose, but as soon as users might want to browse the meta data of all assets there’s no chance to know how much time that thread will take to load the data. So I only provide a nice rotating ring of dots. And it really does the job.
Keep in mind that the progress bar is only a UI feedback for the user, it was never meant to be an exact instrument of measurement. At least I’ve never seen one that works 100% accurately. 
So, showing a spinning progress bar or a ring is definitely the better idea than leaving the user just with a busy mouse cursor.
what Killian said. For unpredictable stuff I usually do a spinning bar as well. If possible I give the user info what’s happening, e.g. what sort of action the script is doing - e.g. loading, calculating, manipulating stuff in the scene, etc. It’s really mostly a feel-good thing for the user so they know the script is still doing something and hasn’t crashed or gotten stuck.
Yea, I’d echo the sentiments here. I would say that it really depends how long the “spinning wheel” lasts as the real factor. If the wait is only a maximum of 10 seconds who cares, but if it’s minutes, I would say more information is needed. Like Robert says, it’s really how long it takes your user to say, “is this still doing anything?” You don’t want the user killing it, when it just hasn’t finished running You can always run twice like you’ve said, and there is a little more overhead. Also in your scene graph example, you could run through the list once, without doing your compares just to get a total count, then run back through it again and do the counts so you have your progress. The last advice i’d give is, you can always have a status bar in the bottom, that might not have count or percentage, but print out what node it’s running on now, so you don’t have the upfront issues, but users can tell it’s changing nodes/etc while the spinning circle tell you it’s processing.
maybe something like a console frame, that shows the current step, and previous steps
Nice idea, using row count as maximum.
I haven’t been writing too many scripts needing a progress bar, but can vouch that including feedback to the user did help. It just avoided the panic that something might be wrong when it was just taking a while to run through.
