views:

86

answers:

3

My application framework provides a progress reporting service to plugins. Each plugin can request any number of task monitors and is then responsible for updating the status includes a textual message, percentage progress (or indeterminate). Process monitors are free to switch from discrete percentage / indeterminate at any time.

What is a good way to visualize these multple progress/task meters? I have a detailed presentation in which each task is visualized as a progress bar in a list. These is pretty straight-forward but takes up a decent amount of screen real-estate. Users are more interested in know if some tasks(s) is currently running and when it will finish. They want a simple way to visualize activity and progress without a list of progress bars.

Knowing when tasks finish is tricky since indeterminate progress is allowed. Multithreading is both allowed and common which means that new tasks may be dynamically added/removed while other longer running tasks keep going.

Currently I combine tasks into a single progress bar in the status bar of the application using the following rules:

If any task is indeterminate, the entire bar is indeterminate. Otherwise, combine the progress of all tasks and displays Example: 2 tasks, first one at 50% and second at 25% results in the progress bar filled to 37.5% = ((50 + 25) / 2)

The problem is that this gets jumpy! If the first task in my above example takes 20s to run and the second task only takes 3s but reoccurs every 5s the task bar jumps all over the place.

Task A (10%), Task B(0%)
[===                                ]
Task A (15%), Task B(50%)
[=========                          ]
Task A (17%), Task B(90%)
[===============                    ]
Task A (20%), Task B(complete)
[=======                            ]
Task A (20%), Task C(0%)
[====                               ]
Task A (25%), Task C(50%)
[===========                        ]

If the secondary tasks occur every 4s and take 1-2s to complete while task A takes its time, the progress bar is jumpy and potentially distracting.

Any thoughts?

UPDATES: After the tasks reach 100%, they're removed from the list. I do not know how long each task will take. I'm not permanently attached to this visualization scheme. I'm open to alternatives.

My question regards the visualization of multiple progress/task meters which I feel is mostly language agnostic so try and stick to concepts. For the curious, my framework is client-server Java using OSGi (Equinox) using remote services like Riena.

A: 

Why not have a small icon for 'in progress' (AjaxLoad has many bars), then when you hover over it a tool tip that shows the progress bars?

I can mock a up a screenshot if thats not clear!

Pondidum
Sounds pretty good, perhaps a subtle animation to the icon as well
basszero
A: 

Do you know ahead of time how long each task will take (approximately), and when it will reoccur?

If yes to both, just calculate the total time it will take, divided by the computation-time (not real-time) spent ie. if the first task takes 20 seconds and the next 4 (even if they haven't started yet) will take 3 seconds a piece, use

[ 20*(percent of first task) + 3*(pecent of second task) + 3*(percent of third task) + 3*(percent of fourth task) ] / (20 + 3 + 3 + 3 + 3)

If the answer is no to either, then you are asking how to predict the future, which is impossible. If we are 50% done with the current task and a new task starts up, what percent are we done now? If the new task will only take a micro-second, we are still pretty much 50% done. If the new task will take 20 years, then we're probably closer to 0%.
Similarly, if we're 50% done with one task but don't know if there will be 0 more tasks or a million more tasks started before we finish, what percent done are we really?

BlueRaja - Danny Pflughoeft
I do not know duration :( I don't need the progress bar to accurately predict the future, just not be so jumpy. I'm open to different ways to visualize this, doesn't have to be a progress bar
basszero
@basszero: Can you estimate the duration (or at least proportions)? For example, download managers can give you a total-percent completed because they know that a 100MB file will take about 100x as long as a 1MB file, even without knowing how long that is; so if the 100MB is 99% completed while the 1MB is 0% completed, it still knows that you are almost 100% done (and not 50%). Reoccuring tasks aren't really a problem, since when a user adds a new download, they expect the total-percent to drop down.
BlueRaja - Danny Pflughoeft
Otherwise, your only options are: `1.` Try to make a poor estimate as to how long each task is going to take by how long they've been running vs. what percentage they're at, and use that to give a poor estimate of the total percent complete (the total-percent will still drop down when a new task is added, but it won't jump back up again like it does now); or `2.` not even attempt to estimate to total progress. Instead, just show multiple, separate progress bars, one for each task.
BlueRaja - Danny Pflughoeft
A: 

I like the way aptitude does this. The progress bars are appended on successive lines in the terminal. If downloads are from different servers, they progress in parallel. When each finishes it stays in the window at 100% state as more get appended after it. If you have a large number of tasks, maybe put them all in a scrollable view, and add progress bars at the bottom as more tasks are added to the sequence (kind of like a download manager).

Justin Smith