24

Discussing with my team-mates this morning but we're not sure which one is the best way.

Scenario: When users select a single document to process, they will see a progress bar and text displaying its progress (ex: page 35 of 40).

When users select multiple documents, the current implementation is that they see two progress bars. The first one indicating number of document that is being processed (ex. 13 of 30 documents) and the second one indicating the pages that are being processed for a specific document (ex. page 20 of 1000).

It would be ideal if the system knew the total number of pages in all documents so the progress bar could reflect this in real time. However, it's not going to work that way. We only know the current document's total pages.

I want to get rid of one of the progress bars, but at the same time matching the dialog when you only have one document (showing the number of pages that are being processed). But also I feel that total is more important than one document. Maybe keeping two progress bars isn't that bad of idea?

Improve this question
0

3 Answers 3

Reset to default
31

Displaying multiple progress bars is not a new concept. Your case is an ideal scenario in which usage is justified. One progress bar represents the overall progress and the other represents the current task's progress.

If you want to use just one bar, then it makes sense to show just the overall progress rather than showing the current task's progress.

A good way to get the best of both worlds is to have a 'Show more details' function. The default view is a single bar with overall progress and the detailed view is the two bar version.

enter image description here

enter image description here

Improve this answer
2
  • 1
    Regarding the example screenshots: You’d have to read the labels to understand how they relate. I think it would be better to make it clear which one is the overall task bar by intending the individual task bar underneath it (and making it smaller in width).
    – unor
    Commented May 31, 2013 at 22:37
  • @unor Like rk. said, this is not a new concept - the first common usage, I would guess, was installation wizards on Windows from the 90s. The top bar was progress of copying individual files, while the bottom was progress of the whole install. It makes sense that the individual task should be on top.
    – Izkata
    Commented Jul 1, 2013 at 3:42
5

I think two progress bars that look similar is pretty hard on the user. It takes quite a bit of effort to grasp the abstraction that the bottom bar represents just one chunk of the top bar.

Here's a suggestion: replace the top bar (overall progress) with a vertical series of icons, representing documents, with a number counter (eg, 3/25). Scroll it up a notch every time one is finished.

Improve this answer
4
  • Wait, why did rk add bold to my answer?
    – Steve Bennett
    Commented Jun 5, 2013 at 1:15
  • Highlighting the core arguments for easier scanning.
    – rk.
    Commented Jun 21, 2013 at 14:28
  • 2
    Is this standard practice? Personally, I'd really rather you didn't - I don't write that way.
    – Steve Bennett
    Commented Jun 22, 2013 at 14:42
  • Feel free to edit it. This behavior is (in)directly encouraged - there are badges for this.
    – rk.
    Commented Jun 22, 2013 at 14:52
4

Showing two progress bars may not be horrible, but question the value of the total documents progress bar.

Since the application cannot know the total number of pages, a progress bar showing the number of documents processed could be misleading in cases where the first 9 documents are 5 pages long and the last document is 4000.

One option could be to display the document count as just a count...

Processing document 3 of 23...
[== progress bar ==]  Page 20 of 1000

...and update the document count numerically.

Improve this answer
9
  • Good suggestion, but, if you are just displaying the progress of current document, the user has no idea how long the process will take. Each document need not be the same size.
    – rk.
    Commented May 23, 2013 at 20:52
  • 2
    @rk. Agreed, but the system will not know how long processing will take, as the total number of pages are not known, even if we assume each page will take the same amount of time to process. Without that critical piece of information, a progress bar tells me just as much information as the "3 of 23" counter, albeit in a more graphical format.
    – wootcat
    Commented May 23, 2013 at 21:01
  • 1
    good point. We do not know much about this system. Though ideally, I would assume the time estimation (for file transfer) would be based upon the total size of all the files and the number of files. It is not accurate but does give you an estimate.
    – rk.
    Commented May 23, 2013 at 21:04
  • 2
    I think you've got it backwards when you say "question the value of the total documents progress bar." If you're going to use only one bar, the total documents would be worthwhile because the user cares about overall progress. Knowing the total pages on the current document is comparatively useless and should be used only to give a sense of movement if the documents are particularly large.
    – Graham Herrli
    Commented May 23, 2013 at 23:15
  • Both are good points. The system actually doesn't do a good job at time estimation. (it only based upon the total number of files, doesn't consider the total size) So i guess in this case, showing either both, or using the progress bar for the number of pages that is being processed would make more sense.
    – sylvia_lai
    Commented May 23, 2013 at 23:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.