Learning from limitations
|
|
Another big limitation was processor speed. The platform for much of our early touch screen work was a Mac IIci, with a processor speed of 22 MHz (if I recall correctly). The big problem here was lag: the time between user input and fully executing the operation. It was vital to address this problem, because users assumed that the machine was frozen, or something was just wrong, after about 6 seconds of lag.
The problem was compounded by the touch screen interface because there was always doubt in the user’s mind that the screen was interactive, that the machine was working, and that the user had touched the right thing. A roll-over state might have been nice but it was not a practical possibility with a touch screen (you don’t drag your finger around the screen like you would a mouse driven cursor.)
The solution seemed pretty obvious: we needed a
‘mouseDown’ state.
It took
very little processor power to change a button up
graphic with a button down graphic, and it reassured
users that yes, the computer received the input. They
were now happier to wait 6 or 8 seconds for the
operation to complete.
Why write about the mouse down state? Because it’s been
forgotten, and it’s still important.
There is always the
potential for latency on a web site; no matter how fast
the connection, hiccoughs happen. How hard is it to tell
users “yes, I know you clicked?”
This hard:
a:active {position: relative; top: 1px; left: 1px;}
The second device was the controlled screen build. This
has become some kind of weird, arcane knowledge that is
almost completely lost to the web. When loading a new
screen with HyperCard (and later SuperCard), the default
behavior was to grab data and media in any old order and
and throw it on the screen. On a slow computer,
this experience was unbearably ugly.
Of course, this ugliness is so familiar
to web users that we hardly notice anymore.
But in 1992, HyperCard gave us choices that are still
largely unknown to the web developer:
We could lock the screen until all the pieces were loaded, then reveal
it using a wipe, push, or whatever.
More importantly, we could overcome lag by choosing what order the pieces loaded, revealing
important stuff while heavier stuff was still loading in
the background.
The impact of these simple devices on storytelling can hardly be overstated.
Getting words and graphics on the screen in the right order
is, uh, really important. This is so self-evident that it feels
stupid to have to say it.
Imagine how much less stupid the web experience would be
if these choices were standard.