The Slowening of Faster Devices

Cueing Up An Ad

Come here and see this "">cool PBS
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

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


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.

User Interface Lag

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

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

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 a 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.

Seconds Add Up To Minutes Add Up To Hours Add Up To…

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

A Supercomputer in Your Hands

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”

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 320×240 screen?

As a point of historic comparison, in the late 80s I was a proud
owner of an Atari
. It was a multimedia powerhouse powered by an 8Mhz
Motorola 68000.

Despite featuring a laughably anemic CPU, by today’s standards,
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

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
, 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

"border: 1px solid black; float: left; width: 0.2%; height: 20px; background-color: red;">
312Mhz XScale PXA272 731,512 Dhrystones / second

"border: 1px solid black; float: left; width: 100%; height: 20px; background-color: green;">


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.

The Basics of a User Interface

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.