Speed perception

Moved from Announcements.

Properly written splash screens don’t

Yes, they do. You’re loading two programs instead of one. There’s no feasible way that does not take extra time, though these days it’s probably less than milliseconds, but it is extra. Just imagine loading that splash screen thingy off floppy disc.

A slow application is still slow, mind you…

Strangely, I am often told that programs with splash screens seem to load faster, because the user sees something happen, and their mind is distracted by the pretty picture.

That’s because the average user probably doesn’t know that the normal splash screen is just covering up for slowness. They think something is happening.

You know, I once came across a splash screen in a Windows program that actually enforced delays in order that the changing messages (some licence rubbish) be seen. Comment out the code, it flickers by. Leave the code in, the graphic is there for about fifteen seconds.

And before anybody says anything disparaging, I will refer everybody to the RISC OS desktop loading banner, that did the exact same thing…

The program can’t show progress when it is the program that is the source of the delay!

Depends upon implementation. The very first thing my software does is get enough of DeskLib up that error boxes work as expected, messages work (if used), and if any visual status is required, it can be shown. As such, the app has probably registered itself as a task and loaded its windows before touching any data files. A good example is Manga that, if it’s been too long (over 12 hours) will fetch and parse the up to date list of available manga. On screen notifications show the entire process, even though it’s technically “app startup”.

Anything that takes over a couple of seconds on a current system really ought to give the user some sort of feedback.

Which is where my comments about the “swirly paper” and similar come into play.
If the transfer was faster the graphic effect wouldn’t be considered as even vaguely necessary, and the reason the transfer is slow is the graphic entertainment

I’m not in total agreement. Usually it is a visual representation of activity. Like in the old days you’d see – then \ then | then / then back to – etc.

The problem with Windows file copy is twofold:

• Firstly, the animation is free running rather than tied to activity. If the transfer stalls, the animation keeps on going until it is noticed that something is wrong. This makes it “shiny-shiny!” rather than any sort of useful feedback.
• And secondly, the infamous time estimation. It is my opinion that the thing must calculate the current speed (K/sec or whatever) and use that figure to make an estimation of the remaining time. It is, however, extremely shonky as any hiccup can throw the estimation off, as the XKCD cartoon demonstrates.
  A better approach, used by real people, is to take the amount transferred so far, and the time taken so far, and use that to estimate the time remaining for the rest. Minor hiccups are generally glossed over and the estimate tends to get more accurate as data progresses (unless the source is wildly unreliable).

put in place to keep you occupied while the slow transfer occurs.

The thing that annoys me about XP is that big transfers tend to start with a phase that says “estimating copy time” or something. I don’t know what it’s doing at that point (there is network activity) because files aren’t copied until it begins to copy. Of course, if Windows wasn’t so ass backwards it would just begin the copy and then give estimates as it was going…

That said, it seems in my experience that as technology progresses, file transfers slow down. Especially “cloud” services that run their own weird protocols. I mean, why does it take my phone so long to sync some plain non graphics Docs documents with Drive? And, as usual for Google, there’s a notification with a meaningless “busy” bar indication that just fills up and resets, in a loop, until it’s done. Because using that bar to indicate amount copied – they couldn’t, people might complain at how long it stays at the 0% marker!

Drive

You may recall that I use an unusual arrangement for my emulated RISC OS – I have five “discs” and they’re all sub-directories of my Google Drive. This means not only is the content backed up in the cloud, it’s automatically synchronised between all my devices, and I get version control of every single file for free (in both senses).

The only problem is when starting Google Drive on the PC, because it takes an eternity to amass all the metadata of the files in the Drive – I just don’t think they envisioned users having 80,000 files on their Drive. It takes Windows 30 seconds to count them all. It takes Drive about half an hour to get to the point of syncing anything (when you first start it), and then it copies the changed files in a couple of seconds.

People keep demonstrating that scaleability is a difficult concept. Hence the old QA joke:

A QA tester walks into a bar and orders a beer. Orders two beers. Orders 999,999,999 beers. Orders -1 beer. Orders a squirrel.

The very first thing my software does is get enough of DeskLib up that error boxes work as expected…

In the use case that Andrew seems to have in mind, the banner is on screen long before this, while the antiquated RISC OS filing systems load up the libraries used by the application. At this stage, the application is not really in a position to start running, since it’s not even in memory yet, but at least the banner tells the user that the double-click worked and that the FS is grinding away in the background.