The Illusion of Life
Let me state the obvious: You are now staring at your computer screen. What you are looking at are not real buttons and the objects moving in your game are not really alive. You have been tricked and you like it that way. It’s all an illusion! A good app keeps those illusions alive and sucks you in, a bad app ruins your buzz and makes you painfully aware of the fact that you are just staring at a computer screen. But what is the secret sauce of those illusions? I think, that the main ingredient of that sauce is processing velocity, which needs to be just powerful enough to satisfy a few “human constants”.
Acceptable Frame Rates
I know from my own experience that a game crawling at 6 frames per seconds (fps) does not do the trick. It does not suck you in, instead you look at the game and think: Oh, yeah, this is some game on my screen. The illusion is broken. So what is the “acceptable frame rate” when moving pictures come to life? Here at Adobe we aim for 20fps, but sometimes that’s just not doable. It seems that 16fps is the absolute minimum. Everything under 16fps ruins your buzz. Perhaps we can then just say:
20 frames per second = 1/20 seconds per frame = 50ms per frame 50ms >= processing velocity
Acceptable Response Time
I couldn’t find any literature on “acceptable frame rates” but there is a lot of material out there that discusses “acceptable response times” for web applications. According to this article Miller (1968) and Card et al. (1991) summarize acceptable response times as follows:
- 100 ms is about the limit for having the user feel that the system is reacting instantaneously.
- 1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay.
- 10 seconds is about the limit for keeping the user’s attention focused on the dialogue.
In my opinion users become impatient in these days if they don’t get any visual feedback with some kind of progress report after the 1.0 second mark. If your desktop app is not up and running after 10 seconds you have lost the user, or made her angry about your product and, in extension, to your company. Also, I estimate that the average attention span for launch times is much shorter for mobile apps. I am afraid, your app needs to be up in about 1 second on mobile devices or the buzz is ruined. It seems that for button clicks we can assume:
100 ms >= processing velocity
and for launch times, which includes load times, we should be on the safe side with:
1 s >= processing velocity
Three of a Perfect Pair
(UPDATE, 2/13/2012: I corrected the formula. It’s SW/HW not HW/SW. The bigger the tax, the greater the expression, which needs to be smaller than the Human Constant on the left hand side.)
It seems that there are some human constants (20 fps frame rate, 100 ms click response, 1 s launch time) that set the performance rules every app has to obey. I would define “processing velocity” as the hardware’s ability to process software as fast as possible. If you adopt this definition then hardware has the horsepower while software is the sticky part you throw into the blender. We could generalize this relationship as follows:
Human Constant >= (Software Tax) / (Hardware Horsepower)
But why am I telling you all this? I want to make the point that the Software Tax is the part developers have the most control over and it is also the most flexible part. I don’t expect humans change their perception much in the next 10 years. If we all do so, then we will most likely get more impatient. Hardware gets faster every year but during a typical 12-18 month production cycle of hardware generations you have to treat the Hardware Horsepower as a constant.
Pirates Love Daisies
La Quenta, Por Favor
So what does this all have to do with “dynamic” versus “static languages”? Why do I prefer static types for practical reasons? Isn’t “dynamic” versus “static languages” a question of religion?
That said, I would like to end this post. My wife wants to go down to the market here in Oaxaca, Mexico. She is eager to buy a musician-skeleton wearing a sombrero (calavera).