Related to Should a progressbar go both ways?
Assume a file copy dialog box with an option to stop and revert the current operation.
If the user chooses to revert, would it be better to roll the same progress bar backwards to 0% or to replace it with a new progress bar with the title "Reverting ..." which goes from 0-100%?
It would probably be a good extra touch to have the progress bar roll backwards.
This would make it clear to your user that the changes have been completely reverted. This is a necessary distinction, because a lot of poorly-written programs DO NOT fully revert their changes, e.g. they leave loose files lingering after the revert.
The progress bar as it stands for the meaning that it is a progress for the action that is being performed. I repeat that it is for the 'action' progress and not 'semantic-perception' progress. A progress bar is meant to be progressing and it can revert back only if it is a continous event as in case of performing roll back of the same event in continuity. If it is a discontinous event happening over an interval then the regressive bar will not be the right pattern.
Progress bars describe a process being completed from start to finish. Even when you are undoing a previous process, the removal process has a start and a finish. It's not like you conceptually start at the end of the process and then move backwards. From a user perspective, there's still a process happening that has a starting point that comes at the beginning and an ending point that comes at the completion.
One exception I can think of is when a progress bar is being used to display the available volume or capacity of something - like disk space. If you were deleting files from a disk I would expect the "deleting files" progress bar to progress from left to right, but the gauge describing my available disk space would move from right to left.
This progresses from left to right as files are deleted:
This progresses from right to left as files are deleted:
