Previous: 19 I shall say this only once ...
Next: 21 Dealing with text
In this section:
It is a matter of some astonishment to me that programs that literally ran for hours now complete very quickly. I remember running something (a finite element code) overnight where after 17 hours, all the available space on the hard drive was filled up with intermediate results, and the program crashed. It was nearly Christmas, and I had promised the results for the New Year. I went out and bought a machine with a 486 processor instead of the 386SX I had been using, installed it in my office and put the software on it and went to make a cup of tea. When I checked, the cursor was flashing and I thought “Oh no, I’ve wasted my money!” But, in fact, the machine had completed the task in about 20 minutes. Nowadays, that program runs even faster and finishes in just a few minutes using what I now consider to be negligible quantities of hard disk space.
As it happens, the results were available on time, and that enabled some tunnel lining segments to be designed, constructed and supplied to site in time for the tunnelling machine to get under a very large and heavy building that no one in the design team had appreciated would be built over the line of the tunnel!
The point of all this is that sometimes a program will run for a long time, and you need to program in a means to tell the user that all is still well, the program is running, and the user just has to wait. As well as telling the user that the program is running, it may be a good idea to tell them how far along the process it has got, when you expect to finish, and having finished, to tell them that it was successful!
Most users will be familiar with Windows software that takes an appreciable time to execute some sequence or other showing a change of cursor to denote that the application may be unresponsive. For several versions of Windows, the icon was an egg-timer, but lately it has been replaced by an animated ring design. ClearWin+ deals with this case by switching on the ‘waiting’ cursor (the rotating ring) with CALL SET_CURSOR_WAITING@ (1), and turn it back to the default cursor with the same call but with a parameter of 0. The question is, just how long can you show the ‘waiting’ cursor before the user loses faith in that the analysis hasn’t, in fact, hung up? That usually requires something more intricate than the waiting cursor.
For a longer wait, there are alternative ways of showing that the program is still alive. One of those methods is to show a hollow bar that fills gradually with colour. A standard ClearWin+ format code for this is %br, and the bar may be horizontal or vertical and can fill in either direction. In this case, the user will lose confidence if they do not see movement of the infill, so the bar is the mechanism for showing that the program is active up to a couple of minutes.
INCLUDE <windows.ins>
BAR_FRACTION = 0.0
IB = WINIO@('%ca[Bar format]&')
IB = WINIO@('Processing %2nl&')
IB = WINIO@('%20br&', BAR_FRACTION, RGB@(0, 0,255))
IB = WINIO@('%lw', LEAVE_CODE)
DO 10 I = 1,100
C ... perform 1% of a lengthy calculation
BAR_FRACTION = BAR_FRACTION + 0.01
CALL WINDOW_UPDATE@ (BAR_FRACTION)
10 CONTINUE
END
For even longer run times, it is probably better to give the user some indication of when they might expect completion. There is a choice between messages such as “X percent completed”, “Expected completion in Y minutes” and “Completion expected at time Z”, and these messages could be accompanied by a progress bar. In all cases it is probably desirable to give the user as much information as possible by frequent updates to the message although users tend to be a bit frustrated if they come time to completion estimate gets longer and longer. If the estimated time left for completion does not change, then the user will soon get frustrated, and if the time is progressively extending, it may be worth adding a “Time taken so far” indication, as that will certainly update and at least show that something is happening.
The benefit of the ‘percentage completed’ message is that quite often it is possible to make a reasonable estimate of how far through a particular calculation the program is at any moment of time. If the user is expected to have some understanding of the processes in the program, then it may well be appropriate to use multiple progress bars with each representing one of those phases of analyses. An estimate of the time at which completion could occur would normally require a certain amount of benchmarking to produce an estimate of the time taken to perform certain types of analyses and is likely to be well in error if the user moves the software to a faster or slower computer.
Even though most of my applications run effectively in real time, I do recognise that there is still software that runs for hours or possibly even days. In such a case I do wonder about the value of those completion time messages. A solution to the problem of computers running for hours is possibly to reserve a computer specifically for solving those types of problem, although it is a difficult one, as most users would prefer to use the fastest computer in their possession for their daily work!
Although I had found that in the early days of FTN77 running under MS-DOS with the DBOS extender software that it was as fast or faster than just about any other compiler on the market, benchmarking with current versions of FTN95 shows that there are other compilers that do produce a faster code. If speed of execution matters that much, then one possibility is to maintain the user interface with FTN95 and ClearWin+, but to spawn an executable program compiled with some other compiler. Communication each way, initially from the user interface in which the dataset is created to the number cruncher and vice versa to display and interpret the results can be done using disk files. For my own work, however, I definitely find that FTN95 is more than adequately fast even without using the optimiser switch when compiling.
In any case, the passage of time and developments within computers will make applications run faster and faster, and something that seems slow will run faster on your next computer or the one after that.
In short, the answer to my question about how long you should use each method of indicating to the user that they have to wait is probably not much longer than a minute to use the waiting icon, and probably not more than two or three minutes to use the progress bar without some other indication about how long to expect. With the progress bar, I would expect users to be happy if they can actually detect progress so that with the sample code above where the progress is indicated in steps of 1%, then I would expect that progress to be indicated and detectable for a progress bar on its own as something in the order of 10 to 20 seconds.
The next question, of course, unasked so far, is where to put the progress bar if that is the method chosen. Ordinarily, a progress bar would appear in a dialog. If the application is marked by many instances where the user does have to wait, then a progress bar might be put in the status line.
Of course, sometimes you choose the rate at which things happen instead of accepting the computer telling you how it is doing. An example of such a choice is in the gradual fading out of an initial splash screen which I described earlier. Such a programmed ‘drum beat’ is done using the %dl format code.
FORTRAN and the ART of Windows Programming, Copyright © Eddie Bromhead, 2023.