"Come here and see this cool PBS promo that was just on!" I call to my wife, tapping pause on the PVR's remote. Given my history of calling her in for replays that weren't as hilarious or amazing as I originally imagined them to be, I knew this had to be a slick presentation if I wanted to impress with my PVR-fu.
As she enters the room the PVR finally reacts to my command, pausing, but then immediately playing again: Once again I've been caught out hitting the button twice, assuming that the first request got lost in the ether -- as often happens -- when it didn't seem to respond in a timely manner.
I hit pause again and this time it immediately reacts, coming to a halt.
"I just have to cue it up," I say, buying some time.
I tap rewind. Nothing happens. Come on, I think, I've got an impatient audience here! I tap it again, and the box launches into double speed rewind as I race for the play button. It plays on demand, but now it's several minutes before the desired start point.
Repeat.
Unpredictably high user interface latency strikes again. While this Motorola PVR is an exceptionally bad culprit for random non-responsiveness, it's hardly the only example of this seemingly growing trend.
My Moto Q smart phone is a great little device that I really enjoy, but the user interface responsiveness is enormously uneven, frequently lagging several seconds behind commands. Whether waiting for it to complete an application switch, or even during basic interactions such as entering a URL in the address bar of Pocket Internet Explorer, it's often out to lunch.
Presumably the questionable multitasking of Windows Mobile completely blocks the user-interface thread when it decides to chatter with a cell tower. Nothing else can explain its behaviour.
On startup my DVD player apparently needs to initialize its own little operating system, and if there's a disc in the drive it automatically demands that it determine the contents before it will eject. It insists that it be able to put "DVD" on the front-panel before any other activity occurs, achieving silicon self-satisfaction that it accurately determined the media type.
A common scenario has us getting ready to leave the house, preschool children bubbling with energy, when we realize that we have a disc that we should return to the movie store.
Turn on the entertainment unit. Wait for DVD to pre-power initialize. Hit eject on the front panel (which automatically turns the unit on). Wait as DVD player initializes and then unnecessarily spins up the disc in the drive to read the disc type and root menu.
Finally it ejects.
It isn't just household devices that show this worrisome trend. The bank recently "upgraded" their ATM machines, bringing a colourful, graphical façade to what was once an glowing-green, ASCII, very serious interface. What once was a quick navigation through the menus now sees the painful redrawing of screens and laggardly keystroke responses.
It might only be 10 seconds or so from beginning of DVD eject procedure to the actual ejecting of said optical disc, but that's approximately 9.75 seconds more than it needs to be.
When time is short, even small delays like this can be incredibly irritating.
Despite the increasing computational capacity of our devices, the problem seems to be getting worse. User interface responsiveness seems to lie low on the list of priorities in many contemporary electronic devices.
These devices seem to be growing slower and slower, yet the processors that power them are getting dramatically more powerful.
Slashdot recently had a story linking to some reviews of a new Windows Mobile 6 smartphone. Several of the comments provided variations of the argument that the primary weakness noted in the review -- poor performance -- was the result of "underpowered" hardware.
Throw some more hardware at it and everything would be okay, the argument goes.
Consider that for a moment: is hardware really the problem? My Moto Q -- a device that often demonstrates terrible responsiveness (I'm not trying to pick on Motorola -- I've noticed the same behaviour with Nokia and Audiovox phones) -- is powered by an Intel XScale PXA272 processor running at 312Mhz. It comes with 64MB of RAM, 128MB of flash memory, and I've supplemented it with 1GB of miniSD flash storage.
Is that an insufficient bit of hardware to manage the awesome tasks of a smartphone with a 320x240 screen?
As a point of historic comparison, in the late 80s I was a proud owner of an Atari 520ST. It was a multimedia powerhouse powered by an 8Mhz Motorola 68000.
Despite what now is a laughably anemic CPU, it seemed infinitely capable at the time: I used it to create complex reports for high school in a full featured desktop publishing app. I did hobbyist software development in a rich IDE on it. I wasted away countless hours trolling local BBS'. It even was a wonderful game platform, running richly challenging games with gusto (games far more advanced than what you often find running in J2ME on your cell phone).
Later I upgraded to the Atari 1040STE, still with the same 8Mhz 68000, but offering expansion capacity to bring it up to a colossal 4MB of memory. This was so much memory that I usually created a memory "disk" out of 3MB of it, and still never felt limited in the 1MB.
Seldom did my ST ever feel laggy or non-responsive -- it booted close to instantly from ROMs, and the simple UI was always extremely responsive. Demo programmers had it doing tricks that still impress me to this day. Later a UNIX-style OS was ported to it, including full pre-emptive multitasking.
So how does that relic of the past compare with something like the Moto Q? Comparing straight Mhz isn't a valid comparison (for instance the ST is a CISC processor, versus the RISC XScale), so I went searching and found some Dhrystone 1.1 benchmark numbers for both the XScale at 312Mhz and the 8Mhz 68000.
8Mhz 68000 (Atari ST) - ~1,603 Dhrystones / second
312Mhz XScale PXA272 - ~731,512 Dhrystones / second
On this benchmark the PXA272 in the tiny little smartphone on my belt (yeah, I'm a nerd) is equal to 456 Atari STs. Let's look at that in a bar graph in case it isn't clear enough.
| 8Mhz 68000 | 1,603 Dhrystones / second
|
| 312Mhz XScale PXA272 | 731,512 Dhrystones / second
|
Wow.
Memory wise the Moto Q has a virtually infinite amount of memory compared to my old Atari ST.
I'm not trying to pretend that the ST of old did what a PDA of today is doing: I remember first getting access to low resolution JPEGs on a local BBS (I was a teenager and they were swimsuit photos...pretty risqué at the time. This stuff was much tamer than an issue of Maxim magazine or an "Umbrella" video), having to go through the tedious process of first "decompressing" them to a TGA, waiting as the decompression processed for sometimes minutes, and then viewing the uncompressed image. There was no way it could realtime do something as complex as rendering a JPEG.
Yet considering this enormous increase in computational power, it does seem evident that many device developers aren't respecting the time of their users, and few users are calling out terrible interfaces for being unresponsive and disrespectful. Reviewers, in particular, seem blind to responsiveness when rating devices, presumably because the artificial environment of a review can't be compared to quickly trying to respond to an email while standing in an airport terminal just as the last boarding call is made.
A user interface should be predictable and consistent -- it should always respond in a short, consistent amount of time (I would honestly feel that the PVR would be better if it always took 3 seconds to react to a command, versus now when it's anywhere between 0 and 5 seconds), always allowing the user to cancel operations that they're no longer interested in.
Responding to the user's input should always be job #1.