Sunday, June 29, 2014

Fake Speed with Bitmaps

It seems that Apple has been working very hard on “hiding latency” by showing a picture of an app’s last state while the app reloads. Apps may have to opt-in to this behavior, but it seems fairly prevalent on iOS and now OS X. Specifically, I’ve noticed it on iOS in some password-locked apps, in Music Studio, and on OS X, in the App Store.

After a firmware update, logging in again “re-opens” the App Store in precisely the state it was left after reboot. Even the update being installed is still shown as available, with its “RESTART” button grayed out. That perfectly represents how the app looked… before rebooting. But it rather quickly reverts to “Cannot contact the App Store; an Internet connection is required” since the wireless isn’t up yet.

Why it needs to talk to the App Store when it could have cached the data less than five minutes ago is beyond me, but never mind that.

The point is, while OS X is busy displaying a stale screenshot, any UI interaction will be lost. Because it’s not a UI at all, it’s a highly accurate view of what it could look like. OS X remains awfully confident about the number of updates it has, even though it can’t connect to the Internet and isn’t even loaded.

This is especially noticeable on iOS where the screen doesn’t visibly change state between the picture being shown and the real UI replacing it. I have a password-protected app that always looks like an “Enter your password” screen, complete with buttons in pixel-perfect position, but if I interact with it immediately after switching to it, my touches are dropped. Instead of 1234, it only registers 234 (or even 34). Then I wait for it to check the PIN and do the unlock animation, then realize that it won’t, and finally delete each digit by mashing Delete before entering the PIN for a second time.

1234 is not my real PIN, of course; that’s the PIN an idiot would have on his luggage. Or, you know, every Bluetooth device ever with a baked-in PIN code. (sigh)

It’s also really annoying when an app takes a while to (re)load because it’s legitimately large, like Music Studio and its collection of instruments for the active tracks. The UI is completely unresponsive for several seconds, until suddenly everything happens at once, badly. The Keyboard screen often gets key stuck down, making me tap it again to get it to release. Or knowing that, I avoid touching it for a while and have to guess at when it will be responsive, not knowing how much time I’ve wasted in over-shooting that point.

In the end, using static pictures of an app for latency hiding seems like a poor user interface—because the end of the latency period is also hidden, it encourages users to try interacting early, when the result is guaranteed not to work. But instead of showing the user that, it silently fails. I’d much prefer the older “rough outlines” splash screens than the literal screenshots of late; the “ready” transition is obvious with those, when the real UI shows up.

It actually surprises me that Apple would even release UI like this, because it’s kind of frustrating to clearly have an app on-screen that’s not reacting to me. Then again, with the train wreck that was QuickTime 4.0 Player, perhaps I shouldn’t be too surprised. (Yes, that was 15 years ago or something. No, the internet will never forget.)

No comments: