Are we making good progress?

Of all the devices in the human interface to computers, there’s none so abused and reviled as the progress indicator. Those displayed during prolonged procedures like system updates have become a standing joke. Let me explain how they should work.

Progress indicators are bars, circles, and other graphical devices used to provide feedback to the user during operations that take significant time. First and foremost they inform the user that progress is being made, and the computer hasn’t ground to a halt or frozen. They come in two main forms: determinate and indeterminate, depending on whether the indicator shows how close the operation is to completion.

This is a good example of a determinate progress bar, showing graphically how far through a backup Time Machine has got, with text underneath it to provide numbers and give an estimated time of completion. To be able to do this, the app has to know two things: how much work has to be done to complete the task, and how much of that has been completed so far. While progress during backups isn’t always too linear, in general this approach works well here, and this feedback informs the user.

When the amount of work to be completed is uncertain, or progress through that can’t be measured, the alternative is an indeterminate progress indicator, of which the ‘busy spinner’ is the best example in macOS.

There are also circular variants, intended primarily for smaller areas, such as those on the displays of devices.

Recently, an indeterminate progress bar has come into use, in which a filled section of the bar moves from side to side without attempting to fill the bar or give any indication of progress. If I recall correctly, this is a latecomer to macOS and originated elsewhere.

The difficulties of determinate progress bars have long been recognised. For example, the 2002 edition of Apple’s Human Interface Guidelines for OS X 10.2 stated crisply and unequivocally that “progress bars should associate progress with time. A progress bar that becomes 90-percent complete in 5 seconds but takes 5 minutes for the remaining 10 percent, for example, would be annoying and lead users to think that something is wrong.”

Since then, determinate progress bars have got macOS into all sorts of problems. One of the most confusing I came across five years ago was this combination from iCloud Drive.

When I copied some files from iCloud Drive, instead of seeing a progress indicator reporting that they were being downloaded from iCloud, the dialog claimed that it was “preparing to move” the document in question. These preparations took some considerable time, during which the Finder’s status bar revealed what was actually taking the time: it was “downloading 1 item”, and reported its progress in doing so. For much of that time, the progress bar in the dialog showed that its ‘preparations’ were actually complete.

The reason for this little excursion into one of the most reviled devices in the human interface is the problem now faced by the Finder when copying an APFS sparse file, as I mentioned a couple of days ago. For any regular non-sparse file, it’s straightforward for the Finder to discover the size of the file, to monitor progress during copying, and operate a determinate progress bar faithfully.

With a sparse file, it has no such luck. When copying it between two APFS volumes, it should be able to write the destination file in sparse format, and only transfer the data used in the original, a fraction of the full non-sparse size of the file. So the amount of data to be copied could be anything from its current size on disk, perhaps 18 GB, to the full size of 100 GB or more.

What happens when the sparse file can preserve the special format during copying, is that the determinate progress bar assumes the worst, and the full size of the file is used to calculate progress. When the amount of data transferred reaches the sparse file size on the destination, long before the bar has even got to 50%, the copy suddenly completes, apparently after only a small part of the task has been completed, leaving the user as surprised as the Finder must have been.

Unfortunately, there appears to be no way to discover in advance how much data will need to be transferred. In this case, the source file on disk took around 18 GB, but even as a sparse file on the destination it required 25 GB on disk. Perhaps the Finder needs to resort to a busy spinner when working with sparse files.