Typeahead

The concept of Typeahead can best be illustrated by way of example.  Consider a simple INPUT that has the following …

INPUT BY NAME field1, field2, field3, ...
    AFTER FIELD field1
        SLEEP 3

If the user types 123 [TAB] 456, what do you expect to happen to the 456 that the user will type whilst the SLEEP is occurring?  Would you expect the “456” to disappear or would you expect it to appear in field2 after the SLEEP has finished?

The answer is most would expect the 456 to appear in field2.  For reasoning why, consider the following …

INOPT BY NAME field1, field2, field3, ...
    AFTER FIELD field1
        IF valid_field1() THEN
            #OK
        ELSE
            ERROR "Field1 is invalid"
            NEXT FIELD CURRENT
        END IF

… if valid_field1() took 0.1 seconds to execute, returned TRUE,  and this coincided with the user typing 4, you would still expect 456, not 56 to appear in field2. You would not expect the 4 to be ignored because the user typed it whilst the application was processing valid_field1(). It would be a poor experience for an experienced user if they had to wait for the cursor to be flashing in the desired field before they start typing into the field.

One of the intricacies of typeahead can be seen with the above, what if valid_field1() returned FALSE.  As the NEXT FIELD CURRENT would put the focus back in field1, 456 would end up in field1.  This is the correct thing to do, no matter how fast or slow the user types 123 [TAB] 456, and no matter how fast or slow valid_field1() processes, the result will be the same.  If valid_field1() returns TRUE, 123 will be in field1, 456 will be in field2.  If valid_field1() returns FALSE, 456 will be in field1.

With TUI applications, as the user typed, the keys would be added to a keyboard buffer, and fed to the application.  Some customers took advantage of this to automatically run programs using stdin and a file that lists all the key strokes needed to run the complete program and exit.  For example, to generate reports overnight they might have cronjob(s) with entries similar to …

export FGLGUI=0; fglrun report_program.42r < keystrokes_to_run_report.txt

… where keystrokes_to_run_report.txt is a listing of keystrokes including tabs, down arrows, enters etc as well as what is entered into each field.

With FGLGUI=1 this approach is not possible as the user input is handled by the front-end application.  With the GDC, this is the Genero Desktop Client executable (gdc.exe) whilst Web Clients this is the browser.  It is this front-end application in cooperation with the operating system that is responsible for buffering the keystrokes and sending them to the application.  Note: it would be possible to create similar automation of programs using the Genero Ghost Client.

When transitioning from a Desktop to a Web environment, this concept of Typeahead is something you should keep an eye on.  Is the typeahead capability the same for desktop and web when …

• moving fields within the same dialog ?
• when selecting values from different widgets ? (e.g. COMBOBOX you might select a value with DOWN DOWN TAB etc)
• has the active state of a widget changed  ?
• responding to modal dialogs ?
• starting a new dialog within the current dialog ?
• ending the current dialog and starting a new dialog ?
• when starting a new program in the same browser tab ?
• when starting a new program in a new browser tab ?

You might not notice but your experienced and fast users will.  If you watch your experienced and fast users, you will observe that they might not read a screen and respond, but simply repeat a series of keystrokes.  An “Are you sure you want to do this? ” dialog has already been responded too with a [Y] [ENTER] before the dialog appears!.

A phrase you may also hear in conjunction with typeahead is predictive focus or predictive typing.  In the above examples, the user when they type 123 [TAB] 456, and they don’t see the 456 because of the processing that is occurring, they might interpret that as something has gone wrong and type 456 again!  Predictive focus seeks to avoid that by placing 456 in the next field (field2) as the user types so that the user receives immediate feedback to their typing.  The problem with this approach is what if the NEXT FIELD CURRENT occurs and puts the focus back in field1 ? or what if the next UI is a new window? or what if the AFTER FIELD logic enables/disables, shows/hides fields that impact what the next field is?, or in general what if something occurs that means the next field in the natural sequence is not where the focus goes.  Early versions of the Genero Browser Client made some attempts at predictive focus but these have since been removed.

Final point is that when the runtime is processing  an indicator does appear.  This is when keystrokes could be going into the buffer and mouse events would be ignored (apart from an interrupt).  At the moment the indicator is a very thin progress bar as pictured below but as per this article it is possible to make it more visible as part of GBC Customization.