SIGIA-L Mail Archives: Re: SIGIA-L: Task Copy: Progress Bar vs.
Re: SIGIA-L: Task Copy: Progress Bar vs. Time remaining
From: Ziya Oz (ZiyaOz_at_earthlink.net)
Date: Fri Mar 08 2002 - 16:50:28 EST
Eduardo Gomez wrote:
Man, you are picky :-)
This is a rather narrow technical issue entirely dependent on the
application that's showing the progress bar and the way its programmers
chose to implement it.
> 1) How is "Time remaining" calculated? For example, "About a minute" takes
> much longer?
If you know (sometimes you don't) the totality of the number of items you
need to process, you take that as the base and decrement it by a set amount
in a loop. So it says "Copied 15 of 38 files..." In the next loop pass, it
may say "Copied 16 of 38 files..." or "Copied 20 of 38 files..." depending
on the number picked (1 or 5) for decrementing. You could make this
proportional: for a large set a large number, for a small set a small
number. No point indicating each file copied when copying 10,000 files :-)
You could map the process of decrementing it against time, although this is
almost always imprecise. For instance, if you are downloading a 10 MB file,
your total download time will change with respect to your connection speed,
which itself may change due to network congestion, server load, etc. There
are rough estimates of how much transfer you can get per connection speed,
so your app will do a quick mapping against that formula.
Now, about the last minute, file, etc. Once a transfer/copying/etc has
finished, the app or the operating system does a bit of house cleaning, like
deleting temporary files, closing connections, setting flags, doing
integrity checks, etc. These take time and are often 'added' to the last
remaining 'minute'. So even though the bar say "Copied 37 of 38 files..."
that last one seems to take forever :-) Now you know the reason.
> 2) Does the Progress Bar visualize the Mbs transfered? If so, how does it
> refresh itself?
It could. It refreshes itself by counting the MBs transferred and at an
interval determined by the programmer (see above) it writes to the screen.
> 3) # of files being copied: How does this impact Time remaining? Accordingly
> for Progress Bar?
> - x files with y memory seems to be more precise when visualized
> (time,bar) vs. 5x files with y memory??
In long and fast operations, it is often faster to display and update
numbers that display/update graphics. However, with today's fast machines
and caching graphics in memory this really shouldn't make much of a
difference in most cases. [1]
> 4) User perspective: which one is better when supervising task? (bar or
> time)?
Actually you could do both, since the calculation has already been done by
your app; it becomes just a display issue.
> - how does this change when the bar is close to the end ( or not moving
> that much)?
See above.
> - likewise, what does a user do to determine actual status of task when
> time becomes unreliable (about a minute)?
As I indicated above, in the last 'minute' you do some house cleaning tasks.
So you could take this part out of the progress bar loop, that is conclude
the bar and then give further notice of activities in a separate message. Or
you could keep the last 'minute' on but explain via text (nearby) that some
house cleaning operations are going on.
Or you could counsel patience, it's only a 'minute'. :-)
Best,
Ziya
[1] Once I wrote a complex app and it took me several days to do all the
progress bars since there were long operations. They were informative and I
felt good despite all the work. A month or two later, computers with a new
generation CPU chip arrived in the office. So I recompiled the app and ran
it on the new machines. Virtually none of my progress bars ever showed up.
The machine was so much faster they didn't get to display. I was heart
broken for all the work I had done :-)
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:55:05 EST
|