Have you ever been frustrated by the presence of the various progress bars on your otherwise beautiful desktop? As it happens there are many tasks that take more than a couple of seconds to complete even on a fast computer, regardless of the platform used.Some examples of applications that produce progress bar dialog boxes are:
– File downloading / uploading.
– CD/DVD recording.
– Mp3 encoding.
– E-mail sending / receiving.
– File copying / moving over LAN.
– Compiling / building software.
…and much more, evidently. All of the above tasks present some form of dialog box (modal or modeless), with at least one progress bar showing the degree of completion of the operation. If a particular user tries to do several things at once (which is quite sane with today’s software), he or she will soon end up with a screen filled with dialog boxes displaying little more information than the progress bars alone. These windows may or may not be resizable, moveable or minimizable. Even in the case where minimization is possible, a user is forced to restore (un-minimize) each window one by one from time to time, only to check the progress of each task being executed. This is very unproductive, to say the least.
Different applications handle the problem of time consuming tasks in different ways. For example, where some Internet browsers open a different window for each file a user chooses to download, others employ a single window displaying the progress for all the files being downloaded at once. We are looking for a way to do the same for all the time-consuming tasks, regardless of the fact that they do not belong to the same application (and obviously they perform quite different operations as well).
We’d like to have a centralized view of the progress of jobs taking place concurrently in the system (like burning a CD, printing a document or downloading a file) in one window. To achieve this we imagine a separate application capable of monitoring (and providing the user with the progress of) each task that is being executed at any time: a “Progress Monitor”. Also, each of the monitored tasks needs to be implemented as a special kind of background job: a job that reports its completion status through inter-process communication (IPC) to the Progress Monitor.
Let’s consider the CD recording application. At the point where a user hits the “Burn” button he or she is normally presented with a dialog box showing the progress of the CD recording operation. In the proposed system we suggest that the recording application generate a background job which is capable of reporting its progress to the monitoring application (the Progress Monitor), through IPC. The recording application can then be available to the user for other purposes, like preparing a label for the CD being recorded, or go to a “sleep” state if there is no other functionality built to it, or simply close. When the CD recording is done, the background job will end and provide some notification in the user interface (possibly requiring some user interaction at this time).
The Internet browser, similarly, would create similar background jobs for the files a user chooses to download. Each file being downloaded would have its own monitored background job for the user to be able to check out easily in the Progress Monitor window.
Last but not least, let’s examine the case of printing. Printing makes the more interesting candidate for a background job because it happens in three stages. First the pages are rendered in a (meta-) file format, then the file possibly waits in a queue to be printed, and then it is actually printed. Obviously all three stages are to become part of the background job. Otherwise, the job wouldn’t be much different than the jobs listed currently on a standard printer queue, with the addition of some progress bar indicator.
The Progress Monitor
With the ability to host diverse jobs (file downloading, document printing, CD recording etc). the Progress Monitor should have a variety of fields to help present the attributes of each task adequately, but it should also be kept as generic as possible. The most prominent ones should be: Job Title, Caller Application, Type of Job, Estimated and Elapsed Times and, of course, the Progress Indicator field itself. There should also be the capability to sort or categorize the jobs by the “Type of Job” field, so that the similar entries can be viewed together -the downloading jobs, the printing jobs etc.- much like the files of same type can be viewed together in a file manager window.
The transition to a new system
There is no doubt that all this will take a considerable amount of work to implement. So where should one start? For one, the Progress Monitor application and the method of communication with the background (monitored) processes should be designed. Then, the applications that generate time-consuming operations and until now presented custom generated dialog boxes should be upgraded to use a newly designed API that generate uniform dialog boxes displaying the progress of the operation, with parameters corresponding to the fields of the Progress Monitor application. In the mean time, the Progress Monitor application can be developed and tested, and the API that generates the uniform dialog boxes upgraded so that it can generate background jobs instead of on-screen windows.
A matter of preference
Obviously this technique would offer a much more uncluttered desktop, especially for users that do many lengthy operations concurrently. On the other hand, what’s best is always a matter of preference. The best system should offer the “Progress Monitor” method or “the multiple dialog boxes” based on some user setting.
About the author
Athanassios Floros is an Electrical & Computer Engineer working in the Software Engineering sector since 1997. He is currently employed at Intracom, one of the largest Information Technology companies in Greece.