Experienced users of a computer system who already know what input data, format and sequence of keyboard inputs are required, may be able to enter it more rapidly than the system can process it, or its interface software can refresh the input screen.
This can result in frustration if the user is forced to adjust their pace to that of the machine. A common solution to this is to buffer keystrokes entered ahead of the input request, and process them in sequence. This was typically done by default on old timesharing systems where response could be variable depending on system load, and is a common facility in command line driven systems.
It may also be implemented in menu driven systems to speed passage through levels of menu, where it has been characterized as the BLT approach by Ben Shneiderman (after the common abbreviation for a bacon, lettuce and tomato sandwich). [Shneiderman 1998, pp. 256] The specific details of this pattern are captured in Menus With Type ahead (#).
The size of the keyboard buffer should be set so that it can accommodate appropriate type ahead, but should probably not be massively larger, as the user will not take advantage of the capacity, while unintended multiple key strokes (caused, for example by a document being inadvertently placed on the keyboard) may cause problems. Buffer capacity being reached should be signalled in some way — typically by a beep.
Therefore:
Allow an appropriate number of keystrokes to be buffered ahead of the display or system processing, warning the user when the buffer capacity is reached.
However, there are situations where type ahead (or keystroke buffering) may cause problems, BUFFERING MAY BE DANGEROUS (#). . . . .