Ask Reuben

Multiple Dialog

What is Multiple Dialog ?

How can I set focus to an inactive field?

How can I improve the User Experience?

In transforming from Informix-4gl to Genero, there is a focus on the user interface.  That includes using GUI widgets (COMBOBOX, DATEEDIT etc)  and arranging the fields on a form into containers (TABLE, SCROLLGRID, GROUP, FOLDER etc) , that is changing the form file.  The user still experiences the same combination of dialog instructions (MENU, PROMPT, INPUT, MENU, CONSTRUCT, DISPLAY ARRAY, INPUT ARRAY).

In a GUI environment you now have a mouse that the user expects to be able to click fields they can see on the screen.  These dialog instructions may only apply for a subset of the fields on the screen and it is a source of frustration for users that they cannot click on these other fields on the screen, typically to go back and correct something they just entered in the previous dialog.

The screenshot below illustrates this.  The fields in the top half of a screen were in a CONSTRUCT  that the user has navigated through, whilst the fields in the bottom half of the screen are in an INPUT dialog which is currently active.  The user is unable to go back and change the fields in the top half of the screen by clicking on them which is their instinct.  Instead they have to click the Back button so that the CONSTRUCT becomes the active dialog.



Multiple Dialog was introduced in Genero 2.10 and consisted of a keyword DIALOG that allowed the developer to combine multiple INPUT, CONSTRUCT, DISPLAY ARRAY, INPUT ARRAY statements together in a single dialog.  For a user this meant that all the fields in the various sub-dialogs were active and the user  could now click on any of these fields.  This gave the user a similar user experience to other GUI applications.


The Patterns

I identified four key design patterns where using multiple dialog was advantageous and placed before and after examples of them in the github repository https://github.com/FourjsGenero/ex_multidialog.

The Starter Pattern (INPUT + CONSTRUCT) is probably the most common pattern I see where a quick gain can be made with Multiple Dialog.

This pattern is typically found in programs that start a report, start a batch process, start an enquiry screen.  It consists of a CONSTRUCT being used to enter QBE criteria, and an INPUT being used to enter some additional parameters.  The user has to accept two or more dialogs, that is they have to press ENTER, click OK etc multiple times to navigate through the dialogs.

The frustration for users is that with singular dialogs, if they were in the INPUT they could not click on fields in the CONSTRUCT, or if they were in the CONSTRUCT they could not click on fields in the INPUT.  They would have to either accept or cancel the dialog they were in to go to the other dialog, depending how the program had been written.

Using Multiple Dialog, the CONSTRUCT and INPUT can be combined in a single dialog.  The fields in the CONSTRUCT and INPUT are active and the user can click on any of these fields to change the value in these fields.  The user now only has to accept one dialog, that is they have to press ENTER, click OK once to navigate the dialog.



The Two List pattern (DISPLAY ARRAY + DISPLAY ARRAY) is the pattern commonly used in the promotion of Multiple Dialog.

It is a pattern seen in other applications, typically in wizards where the user is selecting one more items from a list and adding them to another list.  It consists of two DISPLAY ARRAYs that show the values in their respective lists and the user selects or drags items from one list to another.

With singular dialogs, the user can only ever be in one list at a time.  To switch lists, the user has to click a button that ends one DISPLAY ARRAY and starts the other DISPLAY ARRAY.

Using Multiple Dialog, the two DISPLAY ARRAY can be combined in a single dialog.  Both lists are active and the user can navigate the two lists and select and drag items from either list to the other without having to end one dialog and start another.



The Master-Detail pattern (INPUT + INPUT ARRAY) occurs when you are maintaining two or more database tables that have a master-detail (also known as header-lines, parent-child) relationship.  The program is written so that the rows written to the database for each table are in the same database transaction and it is desirable that the editing of the values is done in a single dialog.

The frustration for users is that with standalone dialogs, if they were in the INPUT they could not click on fields in the INPUT ARRAY, or if they were in the INPUT ARRAY they could not click on fields in the INPUT.  They would have to either accept or cancel the dialog they were in to go to the other dialog, depending how the program had been written.

Using Multiple Dialog, the INPUT and INPUT ARRAY can be combined in a single dialog.  The user can freely switch between the fields in the INPUT and the INPUT ARRAY.  The user only has to accept the dialogs once by pressing ENTER or clicking OK.



The Listbox pattern (INPUT + DISPLAY ARRAY) allowed you to code the equivalent of a ListBox widget as seen in other toolsets.  This is a widget that allows you to select one or values from a list.  The difference to a COMBOBOX or BUTTONEDIT with a zoom window is that is that the Listbox takes up more vertical space than a single EDIT .  The user can also see both the selected and non-selected values whilst a COMBOBOX or BUTTONEDIT plus zoom window, only the selected values are shown.

In the screenshot below the user can select one or more Promo codes.



There is no practical limit on the number of sub-dialogs.  You can have any combinations and as seen with the Two List pattern, multiple instances of the same singular dialog.

One usage I have seen is to have a form with multiple groups and an INPUT sub-dialog corresponding to each group.  This allowed the developer to add logic in the AFTER GROUP of each sub-dialog when the user moved from one group to another.


Coding

To code using multiple-dialogs consists of the new keyword DIALOG being wrapped around the various sub-dialogs.  So for example the Master-Detail pattern would be coded as …

DIALOG
    INPUT ...
    END INPUT
    INPUT ARRAY ...
    ... 
    END INPUT
    ...
END DIALOG

Key things to note include …

  • the concept of scope as it applies to actions.  If you have actions that are global to the whole dialog they should be placed at the end of the DIALOG after the various sub-dialogs.  If an action only applies include a sub-dialog the ON ACTION block needs to be placed inside the appropriate sub-dialog
  • the use of dialog instead of the sub-dialog equivalents where appropriate e.g. ACCEPT DIALOG vs ACCEPT INPUT,  BEFORE DIALOG instead of BEFORE INPUT etc.
  • the developer has to explicitly code the ON ACTION accept , ON ACTION cancel, ON ACTION close blocks at the end of the DIALOG statement.  These actions are not created implicitly and a common mistake is to forgot to include them
  • the int_flag is not used or set with multiple dialog
  • the dialog attributes FIELD ORDER FORM and UNBUFFERED are defined against the whole dialog and cannot be defined against the individual sub-dialogs
  • common sub-dialogs can be coded once and reused using the SUBDIALOG syntax.

Transforming Code

Transforming code from consecutive singular dialogs to using multiple dialog is not always trivial.

What I tend to find is that the code before the first dialog and after the last dialog is the same, and that the code in the various BEFORE FIELD and AFTER FIELD block remains the same.  It is the code that manages the transition between the dialogs and the code that is in the BEFORE and AFTER blocks of the sub-dialogs that needs to be reviewed.   You often end up with less code as you do not need to manage the transitions between the various sub-dialogs, but it is not a blanket case of deleting these lines of code, as there maybe some logic that needs to be retained.


Summary

The use of Multiple Dialogs is a tool in your toolbox that should be used to ensure a modern User Experience.  As a general rule of thumb you can use Multiple Dialog to ensure that a user can navigate through a window only having to click OK or press the Enter key once.  If you find that a user has to click OK multiple times on the one window then that is a good hint that Multiple Dialog might be an option for that window.

As well as the Github repository I mentioned above, a number of demo programs in $FGLDIR/demo utilise DIALOG.  A search such as grep "END DIALOG" */*/*.4gl */*.4gl | grep -v ":0" from $FGLDIR/demo uncovers a number of demo programs using the DIALOG syntax.