Progress indicators when migrating to a new device

TidBITS Talk
1

I just got a new iPad Pro M4 which, no complaints. Setting it up went great, though the overall time involved was kind of bewildering.

I used Apple’s native migration assistant (not sure if it’s called that on iOS/iPad OS) that fires up as soon as you turn on your iPad for the first time, and chose to migrate data directly from my old iPad (not from iCloud, or from a desktop backup). I’ve always thought this process, especially the wireless, “over-the-air” variant I chose, was a bit rickety; it feels like it’s easy to hit unforeseen snags. But I’ve been impressed by how Apple has continued to make this process more and more reliable over the years.

Ultimately, it worked flawlessly. One thing that gnawed on me though is the incredibly inaccurate time estimates for the migration as expressed through the software’s ostensibly deterministic progress bar. The first estimate was 19 hours, then it jumped to 22, then it said something like “About a day,” and then at some point it jumped back to 17 hours, then 11 hours, etc. Ultimately it took about 8 hours, which I’m grateful for. But man, those estimates were pretty confounding; I’d already decided that the iPad wouldn’t be ready for 24 hours.

I know that almost all deterministic progress indicators lie, that they’re difficult to program, and that many are a kind of social engineering as much as anything. But for an onboarding experience as critical as this is — it’s literally the first major thing many people will do after spending tons of money on a new device — I’m surprised Apple is okay with these kinds of wildly fluctuating time estimates.

So my question (which is borne more out of curiosity than a burning need to see this fixed): Are there similar software experiences out there that have figured this out? Is this just one of those things that we should all accept will never be fixed?

2 Likes
2

Good question! The only “progress indicator” that I’ve ever seen work well is the Google/Apple Maps estimate of arrival times. In the early days of GPS devices, I would often arrive before the estimate, perhaps because of driving faster than expected (I suspect they assumed the speed limit at all times, which wasn’t often true on freeways) and at least once because I chose a route I knew to be shorter than the one offered by the GPS. Nowadays, the predicted arrival time is almost always spot on unless there’s something truly unexpected en route.

Obviously, this is a rather different scenario, but I find it interesting that a complex real-world trip is more easily predicted than moving data.

2 Likes
3

This has been the case since (forever?). It’s has always been a joke even when the update is from a local disk installer. Can it really be THAT hard, or does the industry just not think it is worth the trouble to sort out? Seriously, it is hard to understand.

2 Likes
4

That’s a great point of comparison and I agree with you — Apple Maps is pretty much spot on these days. If it’s off, it’s by no more than a few minutes.

However it’s a funny thought exercise to think of a Maps journey ETA jumping around as much as my experience with data migration.

1 Like
5

In fact, this may be a job for machine learning.

1 Like
6

The feature is called Quick Start.

Interestingly, you can wire two iPhones together and the installation is supposed to go faster. I’m not sure if that works with two iPads - that would be great if it works. I plan to try the next time I buy an iPad (probably next year or the year after.)

I just did my iPhone 13 Pro to iPhone 15 Pro Quick Start a couple of months ago, and watched as my son did one from XR to 13 Pro a couple of weeks ago, and there were the wildly changing estimates at first, but after 10 or so minutes it seemed to settle down the the estimate was close to the actual time elapsed. I did’t used wired connection for either of those, because I forgot about it the first time, and the second time we were at the family summer house and I didn’t have all the cables and dongles I would have needed.

Honestly it would probably be a better experience if the estimated time just said “Calculating estimated time…” for several minutes until it was able to provide a better estimate. As for the reason for the wild fluctuations: it’s only a guess, but I think a lot of smaller files takes longer than the same size transfer of a smaller number of larger files, so it’s not just a matter of calculating based on the size of the transfer; and it may also be that the process uses compression and decompression to try to help reduce the file size and the number of files to send, and the timing of this is probably is a hard thing to estimate ahead of time. (Though perhaps Apple could ask permission to gather statistics on the time of transfer and the number of files and the speed of the data connection and use the results to create a model that will provide a better estimate as more people do this?)

4 Likes
7

Actually, it is that hard, almost impossible. I’ve done programming and even wrote an article about the trouble with progress bars. Just to give a few examples of the difficulties:

Variable Data Rate. When transferring information from a source where the bandwidth varies, there’s no way for the program to know in advance how fast or slow the data will transfer. Even today with mostly fast download speeds, there are times where the rate will slow down or speed up. That’s why installer and download progress bars’ time estimates jump all over the place.

Variable Data. Another issue is where the data itself varies. For example, I had an app that stored user data in various silos (groups of data). When I built an export feature, I wanted a progress bar to show how long it would take. My first instinct was to do a simple counter: if the user had 100 items, the progress bar would go from 1 to 100 and increment as each one was processed. The problem was that some bits of data were tiny and others were huge. The small ones finished exporting quickly, while the big ones took so long to convert the user might think the app had stalled.

An alternative approach is to calculated the size of all the data and update the progress bar per x amount of data, but even that can vary as some data might convert quickly and some might take longer just based on the complexity of the data.

One solution to this is to use two progress bars: one for the overall progress and one for each file or group of data. That doesn’t help predicting the time for the whole thing, though. It just gives the user progress feedback.

Multiple Parts. Another common problem is when a task involves multiple steps. An installer is a perfect example. It might need to download a compressed updater file, decompress that file, and then process (install) the update. Each of those tasks is an unknown amount of time. The download time is based on internet speed, the decompression based on the computer’s CPU power, and the install can vary greatly based on what’s already installed, what needs to be removed, analyzed, changed, or user options. Combining all of those unknowns into a fixed time is tricky, to say the least.

With all that said, however, I do agree that Apple’s estimates are very poor. Part of the problem is that Apple updates the time estimate too often, so if there’s a bandwidth change, the time left jumps or drops dramatically, even if that isn’t likely to be a long-term change.

A better approach is to do a rough calculation (probably conservative) and only change it when circumstances stay changed for a while. For instance, it could give you an “about 2 hours” time and unless the download or another part of the process takes excessively longer or shorter than the original estimate (say 20%+ longer or shorter), don’t change the time estimate. Then at least the user isn’t being jerked wildly around with estimates ranging for 14 hours to 5 minutes every few seconds!

Another solution is to just not give a time estimate: just show a spinning wheel instead of a progress bar, so the user knows the process hasn’t crashed. But that doesn’t give much feedback to user. A better approach is to display what the progress is doing, with text: “Downloading… decompressing… deleting 157 obsolete files… installing 1512 files… etc.” At least then the user knows the system is doing something.

9 Likes
8

Once upon a time, I had to write an installer for a much simpler software package. Installation was pretty much just unpacking files from a compressed file archive and moving them to the final location.

Initially, we figured we could make a time estimate based on the amount of data to copy (each file’s uncompressed size). That failed miserably because the installation media was CD-ROM and different users have drives with wildly-different speeds (1x to 54x, and higher-speed drives varying it based on head position), and the destination is a hard drive, which also has wildly-different speeds (different speeds of IDE, ATA, SCSI, different RPMs, different seek times, etc.)

And hard drive performance, even on a single drive, can vary wildly at different times due to things like file system fragmentation.

We also tried to use the download-estimate method. Keep a count of time elapsed so far for the bytes copied so far and apply that estimate to the rest of the installation. That works, and it reaches zero when the job is done, but you find the estimates bouncing up and down as it goes.

And then if there’s anything going on in the background (other apps, system maintenance, and on the Unix systems, what other users are doing), that makes everything even more unpredictable.

We eventually just fell back to two bar graphs showing the number of bytes and files remaining and eliminated time estimates altogether.

7 Likes
9

I think that would be better because progress (changes) would be obvious to the user. Just a spinning wheel, no. I have had lots of “spinning wheels” that were ultimately lockups/crashes.

But thanks for pointing out the numerous fairly obvious complications (if I had taken the time to really consider it).

10

100%! I hate wondering if an installer has crashed or gotten stuck.

3 Likes
11

This reminds me of the boot sequence for early releases of Mac OS X (10.2 through 10.4, I believe) where there was a line of text below the Apple logo that would show the component starting at the time. It was very useful because if the system would hang, you could see how far it got. Much like the row of icons classic Mac OS would present as system extensions loaded.

Later on, Apple did away with that, so now we just see an unlabeled progress bar. Not nearly as useful, even if it looks more artistic.

Of course, as a developer and engineer, I like to see startup messages. On my Linux PCs, I always disable the graphical splash-screen so I can see the hundreds of messages scrolling by as the system boots up. If something fails, it becomes much easier to determine what it is, and plan for how to fix it. (Yes, I know macOS has verbose mode, but very few people even know it exists, let alone enable it.)

3 Likes
12

Ditto. I really wished Apple Macs had physical drive lights like IBM PCs. Do any tablets and smartphones even have physical lights?

13

I love verbose boot sequences even though I have no idea what most mean. ;) Do AppleTVs, iPads, and iPhones even have those like in Macs? Those would be useful when needed!

14

Well, they’re all running the same Darwin/OSX kernel, so they are generating the messages. The question is how you might view them.

Most embedded devices I’ve worked on have a console terminal interface (which may simply be a few test-points on the board if the product isn’t meant to ship with a console). Messages from the boot loader and operating system (typically Linux) will be sent to that interface.

I would assume that Apple has a console interface of some kind on their devices, because it’s really useful when developing/debugging the operating system. But it may be nothing more than test points on the board, which would not be accessible without opening the device and soldering wires to the pads. And they may require special custom builds of the operating system in order to enable that console.

Assuming it’s not just solder pads, Apple probably has debug ports that can present a Darwin console (maybe only if activated using a special build of the OS). This is all speculation, but…

  • iPhones, iPods and iPads have Lightning/USB ports. This would be the most obvious place to put a diagnostic interface, since you can use it to create virtual serial ports.
  • Apple Watches used to have a secret diagnostic port that, we’ve been told, resembles a Lightning port. Apple pretty much locked out any consumer use, but it was used by Apple for their own diagnostic purposes.
  • Watch version 7 did away with that port, but added a 60.5 GHz wireless interface that pairs with a proprietary magnetic dock for (I believe) similar diagnostic purposes.
  • Apple TVs used to have USB ports, which could be used to restore firmware via a DFU mode using iTunes or the Finder on a Mac. I personally used this port at one point to roll-back a buggy firmware update on an Apple TV v3.
  • Today’s Apple TVs have a secret port inside the Ethernet jack. Again, we don’t know what it’s used for, but we’re told that it (like the Watch diagnostic port) has similar signals to Lightning and is probably also only useful (for diagnostic purposes) when used with a proprietary Apple cable and software.
2 Likes
15

In the days of old when knights were bold my husband drove me to an appointment in the wilds of Brooklyn one morning. Afterwards I needed to take a subway train to get to my office in Manhattan. I pulled out my brand new and beautiful iPhone and asked Siri to direct me to the nearest subway station. After directing me for about a million miles, I saw that Siri directed me to a Subway takeout restaurant instead of a train station.

I did tell Siri a very many bad words.

2 Likes
16

CCC provides a very good progress indicator when running a backup. It also shows the time to complete the last backup, so you do have a target. And CCC is dealing with a lot of different data types and sizes.

David

4 Likes
17

Perhaps @bombich can weigh in here to how CCC’s progress indicator works.

18

Time (and difficulty) are the main reasons I no longer do most upgrades, hardware or softare.

19

Someday. Maybe. But initially, I’m willing to guess that AI-based estimates of multi-hour times to complete transfers will be just as wildly inaccurate as current, purportedly deterministic ones.

20

I can appreciate why you as an engineer would want to see a textual startup on a computer, but I as an ordinary user certainly don’t want that experience (whether I can enable it or not).