Reflecting on user interface design and programming, there is a cluster of notions I would like to get across.

When writing a GUI framework to run on the original 4.77Mhz Intel 8088 based PCs, after writing the initial set of primitives I found performance unsatisfactory. I am a big believer in making the lower level framework very fast (then and now), so that the higher level code can be less concerned about efficiency. This was not an obtainable goal with generalized graphics operations on 8088 (too many clock counts for shift operations).

So I flipped the problem around. Instead of generalized graphics I came at the problem differently. Graphics operations are at base moving bits from one location to another. The 8088 string instructions were the fastest means of moving bits around. By choosing the right constraints (mainly byte-alignment in source and destination) I could write graphic operations sufficient for a GUI framework (at the time), and deliver very high performance levels.

It was nearly ten years later before Windows applications could count on similar performance levels (though of course the operations supported were far more general).

At about the same time I found an early shareware editor called Dewar Advanced Screen Editor (DAED). The interesting thing about using this editor was not the features offered (basic even for the time) but rather the fluid, fast, predictable response time. I had turned up my key-repeat rate up to much higher than standard levels (to something like 100 repeats/second through a third-party TSR), and because of the fast response of the editor, could simply zip from one location to another using simple cursor movement commands. Because the simple movement commands were (very!) fast and predictable, there was much less need for the more complex movement commands. When moving vertically you could judge where you were in a file simply by watching the text slide smoothly past.

In contrast, when later programming on Unix I became accustomed to using the complex movement commands available in Emacs, as this was the fastest way to move around in a file when the screen was painted by characters squirted across a serial line. Complex movement commands make more sense when display and response time is relatively slow. Note also on time-shared, multi-tasked systems the response time to simple movement commands is unpredictable. On a single-task unshared system you can learn to judge the distance per second moved through a file by holding down a movement key. This sort of learning can only take place when the response is immediate, predictable, and you can watch the shape of the text flowing past (fluid movement with no flicker).

We have an entire generation of programmers and designers who - outside of video games - are accustomed to relatively slow (certainly not fluid) response from their user interfaces. This lack of experience means the notion does not occur to most of the folks as even a possibility.

There is something fundamentally different about a user interface with fast, fluid response.

Note that Windows does not let you set key repeat rates above the standard 31 repeats/second. You cannot explore notions that are impossible within the common framework (Windows).

Not sure the interrelationships in the above is at all clear…