Really Slow Processors

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

Why write about the mouse down state? Because it’s been forgotten, and it’s still important. note 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. note


Page: LFL03 version: 0.9 | 02.14.2005