Tips_gui   >   About   >   About (All Contents)

About GUI

GUI stands for Graphic User Interface. The GUI is what the user sees on the screen. The GUI is where the user interacts with your application.

The GUI classes in Omnis Studio are window classes, menu classes, toolbar classes, and report classes.

This GUI group covers topics relating to the GUI classes, GUI objects, and user interface.

User Interface

I don't claim to be an expert in designing a proper user interface.

This section is a list of ideas and guidelines which I have been collecting along the way. I've been reading a couple books on user interface and am using this section for my notes. Don't take the information in this section too seriously. These are not guidelines for everyone. Read and decide for yourself.


Locate buttons along the bottom of the window.

Right justify the buttons along the bottom.

The Okay/Default button is always furthest to the right.

The Cancel/No button is next to the left.

Other buttons are to the left of the Cancel/No button.

Center justify the text in buttons. Use plain text.

Specify the action that will be taken rather than just saying Yes or Okay. For example in prompt where you ask the user to confirm whether or not they wish to delete the selected record, use a Delete button rather than Yes or Okay. In a prompt where you ask the user for some information prior to running a report, use a Continue button, rather than an Okay button.


The industry standard has been to append a colon : on the end of every label. I feel that is an old habit from the 'command line' green screens. Going against the industry standard, I do not append colons on my labels.

Context Menus

The basic application should run without using any context menus. Context menus should be geared towards the advanced user.

Drag and Drop

Don't require users to drag and drop between lists. It is a GUI option. Allow the user to be able to select lines and click arrow buttons to move data between lists.


Always use ellipsis on menu lines and buttons when a prompt will be opened which will require user input.

Do not use ellipsis if the command simply opens another window.

Error Messages

Write code to avoid the need for them. :-)

Error messages viewed by the user must be in user friendly language. Error messages must not simply state the problem. They must help the user to solve the problem. A further level of information for the programmer should be available. Using a window expander triangle?

Field Focus

I like to indicate to the user which field has the focus. This can be done by changing the field border color/style on the field with focus to a suitable color. (e.g. blue)

Font and Case

Be very consistent with the use of fonts throughout the entire application.


If a menu has a matching toolbar button, include the same icon in the menu. This helps user learning. Create shortcut combination keys for commonly used menu items.

Provide keyboard equivalents for the Wintel platform. (The unique letter underlining thing). I admit to not yet having done this latter item in my application.

Message File

Use a message file (String Tables?) for storing all menu items, button names, tooltips, error messages.

OK and ID

The shortform for Okay is OK. (not Ok)

The shortform for identification is ID. (not Id)

Toolbar Buttons

Toolbar buttons are a great user interface.

Toolbar buttons should not be a mirror of the menu items. Toolbar buttons should be for higher frequency use commands.


Only use tooltips when they will give additional information. Never have a tooltip that says the same as the label/button text. Toolbar tips should be readable sentences.

User focus

Users tend to read a window from top left to bottom right. The top left and bottom right get good attention from the users. The sweet spot is dead center.

The top right and bottom left get the least attention from the users. If you use graphics, (or less important info) put it in the top right and bottom left corners.