Progress?  We're not making any progress!  

or

Are We There Yet?

A common need in programs is the need to display the progress of an operation. 
Displaying progress can tell the user:

• the program is still alive;
• what percentage done the program is;
• when the activity might complete.

Another type of report commonly, but incorrectly, called "progress" is the spinning wheel.  A similar one is the "Cylon" activity bar.  Such indicators would more properly be called "activity indicators".  These are not covered in this post.

Progress can be defined: "forward or onward movement toward a destination". 

An activity indicator does not, and cannot, indicate progress, because it does not indicate that "forward" or "onward" movement is being made!

Thus, for a file transfer, a beep every second doesn't indicate progress, but a beep every 1024 bytes of data transferred would indicate progress (although poorly).

Progress indicators often need more features than you'd think at first:

• a short description of the goal (e.g., copying 4,567 files from a remote computer to the local one);
• percent done (or some measurement of work done vs. work to be done);
• an indication of the current step (e.g., "copying file foo");
• an option to pause the task (and later resume it);
• an indication of why the task is paused (if it is), and how to resume it;
• an indication if aborting the task could cause problems  (alternatively, a note that the task is not abortable);
• an option to cancel the task (you don't always need this, but it should be considered!);
• an option to cancel the current step, but not the entire task; (e.g.: stop trying to copy one file of a set of ten files, and resume with the next file).

As a bonus, a good progress indicator may give you insight into how a long a similar task may take in the future.

One example of a reasonably informative progress indicator is seen in the "wget" utility (a common Linux / Mac program).  wget displays the percentage of a file that has been downloaded, and the estimated time of completion of the transfer (called "ETA", for Estimated Time of Arrival).

After about 9% of a file has been fetched, wget might report:

 9% [==>                      ] 34,884,943   1.59M/s  ETA 09:10

At the end, "100%" and the final throughput is reported:

100%[========================>] 398,336      2.51M/s             

But, even wget has problems. 

A small file (30 KB) is left displaying this at the end:

    [ <=>                       ] 30,777       --.--K/s           

Note the lack of "100%" or a throughput report.

Thankfully, wget didn't take the very simple approach to measuring throughput (which would be: how many bytes transferred divided by how many seconds since we started).  Instead, testing shows that wget's throughput rate (and ETA) is based on the last N seconds (although 'N' is unknown), not the entire length of the transaction.  That means that if it's slowed down for a bit, but then resumes running fast, the rate and ETA will fairly quickly recover and report accurate information.

The final rate reported reflects the entire process, including any temporary slowdowns, which is quite reasonable ... knowing how fast the last few bytes transferred isn't likely to let you extrapolate how long a similar transfer will take next time.

Remember that "bonus" mentioned earlier?  If the progress indicator simply says "done", without reporting how long the task took, then if you look at that information later, you won't be able to say "ah, wget of 35 MBs took 9 minutes ... so I know it's about 4 MB per minute". 

With any luck, the next post will be more about progress .. because there's a lot more that needs to be said!

Stan
sieler@allegro.com