On 2006-11-11, Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> posted something concerning:
> Outlook takes 136 years to sync email (screenshot included)
>
> ,----[ Quote ]
>| The software behemoth has previously tried to assume control of the
>| fourth dimension by turning the clocks back a week early, and
>| turning the clocks forward a few thousand years to release its new
>| operating system Windows Vista.
> `----
>
> http://www.theregister.co.uk/2006/11/10/outlook_sync_progress/
>
>
> Related:
>
> Windows Vist (sic) - File Copying - Progress Bar (screenshot included)
>
> ,----[ Quote ]
>| The progress bar is yet to show the actual progress as it has
>| almost transfered 60% of data.
> `----
>
> http://interestingwritings.blogspot.com/2006/11/windows-vist-transfer-rate.html
I saw similar to this happen last night on $SON's Mac. I opened a file
to extract the contents of a game demo. As the count for the number of
files being extracted grew, so did the amount of time stuffit said was
left to completion. I stopped paying attention once it exceeded 650
minutes, but the actual extraction lasted less than two minutes.
For a few years I did all of my Redhat installs using the text
installer, even when they added a gooey interface. I just found it
faster and not really any harder to navigate (easier for some things).
The progress counter inevitably would start with a time so I could have
an idea of when to come back to a finished install or to change CDs.
With few exceptions I'd return and find everything about halfway
through what I expected and the total time expected to take had more
than doubled. The only times it didn't happen that way were when I sat
waiting for things to move to the next stage. During those times I'd
get to watch the overall time and time left counters bounce higher and
lower after each package, and it was always higher in aggregate.
I've seen a number of other installs do similar things since that time.
The live CDs and some other things have sidestepped that pretty much by
telling you how long things *could* take, and giving a progress bar
that gives a measure of percent (or relative size) completed, with no
timing mechanisms attached.
I used to have to copy several megabyte from a networked drive to the
local machine and back to another networked drive while running XP. It
took no more than a handful of minutes from drive to machine, and the
progress bar wasn't too awful inaccurate (jumping between displaying 10
minutes, 1 minute, 5 minutes, etc left randomly). The operation from
machine to network took about an hour. The progress counter for the
second leg would gradually rise to 10 hours, drop to an hour, drop to
45 minutes, go to 8 hours, drop to 3 hours, go to 14 hours, drop to 2
hours, etc.
Progress bars are one thing. Trying to time the activities they're
supposed to be measuring isn't among the brightest ideas anybody has
come up with since they seemingly can't account for all of the
variables that affect what the operations are doing. So it's probably
best to leave things as a measure of overall size and completion
instead of overall time.
However, if they're going to use a progress bar, they should make sure
it actually moves at some point as things progress, counter to what is
stated on the 60% completed of Fisted operations above.
--
Windows - Where user apps destroy your OS.
|
|
