Scalabium Software

Discussion about Application Interface

Mike Shkolnik, Scalabium

In this article I’ll show the common mistakes in interface building and show a few standard schemas which are useful for end-users.
The any RAD including Borland Delphi, of course, is very powerful tool, which allow to reduce a time and to increase a quality of development. But in same time the any RAD allow to write an application with bad style and bad performance. To describe a necessity of changes in programming is one task of this article.

I shall try to divide the mistakes in development using Delphi IDE on two logical parts:


Visual mistakes

The first opinion about your application that will be created by end-user is very important because any application must not only solve Ó task but also the person that will work daily with this application must like it. To change a first opinion is very hard so don’t think that in the next version you’ll change it – you can lose your customers (and money as result) and this customer never will be returned.

The visual interface is the clothes of your application and these “clothes” must looks nice.

I don’t want to repeat a some article about usability but I want just to show a few errors of developers which can be fixed very easy but which can decrease a number of end-users of your program.


Large resultsets

This mistake is very popular. I saw a lot of applications where list box (or other control) contains the hundreds and thousands of rows/records.

Time-to-time in any forum of developers someone asks: “where can I find a listbox that allow to show the 100000 rows?”

The answer is one – try to change a logic of your application. The Microsoft’s developers limited the standard controls (especially in Windows 95/98) but this is not bad – this is good.

To find a desired row in large list of such listbox/combobox/etc items is a task without solution… To use a large resultsets is bad style because your application is very slow and any end-user can’t process such large set of data physically! You can always limit your resultset by filtering, or fetch a data by blocks…

You must create a good interface for end-user. To drop a lot of controls on form and say that your program is developed, is not good programming – you must create a really native presentation of your data.

Anyway you must change the data presentation and/or redesign an application. For example, to load a data into first/root level of TreeView control only and to add the children in OnExpand event when user wanted to view data. Of course, this method requires some additional programming but this is more useful for end-users.


Custom drawing

The some controls (listboxes, comboboxes, grids etc) supports a custom drawing mode. For example, you can easy to change a background color for some desired rows in listbox or dbgrid.

I must say that the custom drawing must be “soft” and "safe". Especially when you want to highlight a data in control which end-user must view daily.

For example, you have a task “to highlight the non-American companies in the customer list". You can just add a custom drawing and use a red color as background for records where Fields[‘Company’] doesn’t contain an ‘US’. In this case you will receive a picture which will be similar to picture below:

But now imagine that end-user which purchased your application have 90% of customers which are not USA based companies. In this case your painted list will look as solid red area and I not sure that your user’ll like it…

On the other hand you can realize the same task in other way (look a picture below).

Here the non-American companies are highlighted too but I used more “soft” method – small picture with country flag and blue font color in Company column. So now the user can find the non-American companies without any problems and if someone will have a lot of such customers, he/she will easy continue to work without any problems for him/her eyes.

I suggest the next recommendations:


Many-To-Many relationships

Exist a lot of tasks where data depends one from other in many-to-many relationships.

For example, in small program for travel accounting we have the next relations:

So we have a list of available trips (Trip table), the list of tourists (Tourist table) and in Travel table we have start and finish dates of trip for each tourist. Here we have the many-to-many relation because each tourist could visit a few trips in different times.

Now imagine that we must display in a form these data. I suggest separating a data into two TabSheets and showing a Tourist names per trip on first tabsheet and a trip list per tourist on second tabsheet. So we will receive something like that:

In this case user can navigate by any master table and view a linked detail rows. Easy navigation and easy switch between master tables are important parts of native interface.


Data editing in the grid

Some developers allow editing a data directly in grid cells. This is useful for small area of tasks where user must enter quickly a group of rows and especially of numbers. In this case the analogue of spreadsheet is useful.

But this area is limited and to edit any data in grid is not good idea. Better to create a small dialog where controls will be separated by logical groups for user and selected a desired control type for each field (radiobox, richedit etc).

And anyway even for tasks where you decided to open an edit mode in grid, better to use a custom inplace editors for each data type (checkbox for logical fields, dropdown calendar for TDateTime, dropdown calculator for currency fields etc).


Don't interrupt the user

If your application works sometime in background mode and you want to notify the user about process finishing, don't interrupt the user with some dialogs which will change a focus of keyboard or mouse cursor. This is a bad style because the user couldn't continue with their current task.

You always can offer some feedback that don't interrupt. For example, add an icon in tray with meaning glyph (success/error/etc) or to change a hint of your application on taskbar.

The similar problem is timeout dialogs. For example, your application will generate a large report form and this process takes a lot of time. After report generation you want to ask a page scope, or copy number or printer for report printing. I suggest to add a timer and close this dialog after one-two minutes. If user didn't changed any option in this time, just close a dialog and print with some useful predefined options! You'll save a time to users.


Mistakes of development

The native interface term includes not only visual look of your application. The work with your program must be easy from different sides and in the different end-user environments.

Regional settings

The most popular mistake is to use some predefined formats for date, time, currency, number etc The any user can set a desired format in Windows settings and any application must accept these formats. Imagine that end-user like to use the MM/DD/YYYY date format but your application will use the DD/MM/YYYY, for example.

Also I saw a few applications which changed the regional settings after installation or running without any warnings. The wish of end-user is a law and you can’t violate it!


Keyboard navigation and control access

The any RAD (and Borland Delphi as one from them) allow to develop visually when the programmer can construct own application using drag’n’drop (in case of Delphi is a drag'n'drop from component palette to form designer).

But when you use this type of development, you can easy make the next mistake – the navigation by keyboard will be “corrupted”.

In any interface guide you can read that native navigation is:

from top to bottom
from left to right.

So just after each change of form contents check an tab-order of controls.

Also don't forget about keyboard shortcuts.

For example, you may add a hot key for label which will place a cursor to “linked” editbox (check the FocusControl property of TLabel) or to add a standard keyboard combination to menu item/toolbar button.


Different checks

Always you must check the application running on different version of operating system. The application that was tested on Windows 95/98, can not work on Windows NT/2000 and vice versa. The each version of Windows have some small modification and some procedures which successfully worked on your computer, can not work on others.

For example, you used a writing into registry and saved there some important information but in Windows NT/2000 you must check additionally the user privileges before writing. The same you must check for some other actions (for example, Windows shutdown).

Also some difference you’ll find in Windows API.

Don’t forget to check your application on different color schemas and different screen resolutions. The problem with small and large font sizes is very important – your application must look nice in any mode, which will select a user.


Just a few important tips:


Mike Shkolnik is an author of Delphi/C++Builder components (freeware and shareware). Currently he specializes in system design, database engineering, datawarehousing and custom development by remote contracts. In his spare time, Mike maintains and operates his web site: //

Borland Software Scalabium Delphi tips

Copyrightę 1998-2023, Scalabium Software. All rights reserved.

June 26, 2001

SMExport advertising