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.
– Printing.
– 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.
Example jobs
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.
After seeing the entire keynote speak by Steve Jobs on Panther, I think this sounds like an idea for their next cat, or possibly MS and/or Apple already have experimented with something like this and deemed it unecessary for some reason?
BeOS had this in a very different way but still worth mentioning, but I found that way very annoying so… but cool idea still.
Because of it’s power I use OpenTracker to do lots of things at the same time. I am very use to seeing three or four tracker progress bars running at the same time. I do agree it better to have them all in one window than separate dialog boxes. I have downloaded multiple files overnight and having 16 or more dialog boxes does make for a mess.
“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.”
This is a good example of the clutter caused by running all programs on one screen. On my system (not Windows), the progress bar stays on the screen for that program, and while it is busy I can switch to another screen and work on something else. If there were ten progress bars, each would be on one screen, so you don’t see ten at once.
And while we’re on clutter, why doesn’t a Windows window have a button to send it to the back? And why does it jump forward even if you click anywhere, covering up some other window which you want to see? Major annoyance when using Real Audio with IE, for instance. The RA progress bar disappears behind the big IE window as soon as you click a link.
with this app, your’re creating a single point of failure… segfault this app… all your jobs are lost
IMO it is a really great idea. I have thought about it before when I thought about writing a DOS file manager: an area below on the screen containing a list with all jobs running in the background.
It can then indeed be extended with download progress, printing progress, MP3 encoding progress, Gnutells host-find progress and more.
Actually, might it be a nice thing to add to Qt/KDE? An application running in the systray, if you click it, a window pops up listing all progress, click again and it disappears. Via DCOP any client could use this service to display its progress.
I would love to try coding something like this, however, I am not good at C(++) as I only know Pascal well enough to write something useful
Instead of creating another app, put the progress bar on the application’s taskbar button, either as a discrete section of the button or make it shade the entire button as the task progresses.
Windows has something called a taskbar (or something like that, I tend to forget the M$ vernacular), which is a reserved area usually at the bottom of the screen, where every application has its own little button for fast task-switching.
One other use, however, is to put progress information into the program’s button. There are actually several programs which do this, which means that they can be minimised, while still keeping the user à jour regarding their progress.
I’m using windows at school right now..but one of my favourite features in kde is the option to show all progressbars in a single window.
I think it’s been there since kde2.
Taras
And while we’re on clutter, why doesn’t a Windows window have a button to send it to the back?
You must be an (ex-?)Amiga user. 🙂 I’m with you on this one.
Getright download manager displays all downloads in a single window..or does minimize to tray per download.
KDE however is the only evironment that can consolidate progress dialogs from several apps.
While I like this idea in some programs, I hate it in others. When I’m using Getright, I appricate that it’s all in one window. However, at any given point in time, I can double click one progress bar and launch it in a seperate window if I want, which gives me more information about the file being downloaded.
However, when I download files with a web browser, I want each file in its own Window. I don’t know why – I just do. I can’t stand the way Opera does it … just lumps everything into one window that (AFAIK) can’t be ‘undocked’ from the MDI interface. This was one of the main reasons why I went back to using Firebird. Sometimes it’s just the little things.
As I always say – when in doubt, make it an option. If people would adopt this philosophy, you wouldn’t have all these arguments about things such as CLI vs. GUI app installation. Some people prefer one and some prefer the other, and some prefer both and will chose one depending on the task. Just include both and be done with it.
How do I set this up in KDE?
with this app, your’re creating a single point of failure… segfault this app… all your jobs are lost
I like the idea, and the segfault is bullshit offcourse…
See its just a display application, it should have an api to update the progess not get controll of the processes. My application just does a update_progress(process_id,progress%) and then the one window with progresses gets updated and if it crashed well nothing happends, maybe the api can ake sure it opens a new window or something, but your application should keep on running though the function might return a false or something. Seems like a pretty simple thing here which should be fairly ease to implent. Go go!
> with this app, your’re creating a single point of failure… segfault this app… all your jobs are lost
I wouldn’t think so. The apps do their own jobs and tell the progress app (built into the window manager, maybe) how much has completed with, umm, IPC. Duh.
I like the way adobe photoshop on mac os x does it. When there is a time consuming task in photoshop, it shows a progress bar in the dock. I can go on to do other things, and occasionally glance at the photoshop icon in the dock to see if it’s done. If more programs adopted this method, there would be no need for a “job” window described in the article.
Sounds like an overengineered solution to a nonexistant problem. Nothing here, move along.
Quickly install opera again and go to preferences – windows en enable “open pages in new window”
—
Windows handling
You can decide how pages and application windows should behave:
Whether links should open in a tabbed page in the same application window (MDI), or open in an entirely new application window (SDI)
Whether new pages should always be maximized
Whether bookmarks should be opened in the active page or a new page
Whether to show scrollbars in pages
Whether to show size of pages (used to see how Web pages look at particular resolutions)
Mac OS X’s Finder handles all copy, moving, deleting into one window that has multiple progress bars in it. But I agree, Photoshops icon in OS X has the best functionality. A progress bar in the icon. I have seen this in a few other apps too I just can’t remember.
Windows could do it in the taskbar window buttons, but what else they should do is make these window buttons draggable around the taskbar…sometimes I hate the order they’re in.
Alt+ESC
I would very much like something along these lines. I would like the status of all copy operations, all file transfers, etc. available through a single “pane” of sorts. Slicker (http://slicker.sourceforge.net) has mockups for something to this effect (implemented as a Slicker “card”, albeit somewhat ugly): http://slicker.sourceforge.net/mockups/downloadmanager.png
The main difficulty something like this is facing is IPC. Making two processes talk to each other in a Unix environment is just too hard as the interfaces (Unix domain sockets, SVR4 IPC) are just too low level to really be useful, and non-uniform across various platforms. I started a Sourceforge project to deal with this very issue, and designed the interface to a library which would provide an interface similar to BeOS’s BMessage system (only in C instead of C++) and would sit on top of the best available underlying IPC system on the given platform (i.e. Unix domain sockets on Linux/*BSD/Solaris, Mach message queues on OS X/the Hurd) but unfortunately it never went anywhere. If you’re interested see http://lamps.sourceforge.net/
From my experience, OPENSTEP, and OmniWeb already do this.
All Workspace Manager processes are shown in a little space below the Shelf, and if one opens the Processes window, all running Workspace Manager processes are shown and their progress displayed.
OmniWeb does a similar type of thing, with it’s Processes window. All downloaded files, image loading, &c. are displayed.
This isn’t anything new, I’m afraid.
Any advantage to lamps over something like D-BUS?
But why stop there? I don’t want to see dialogs popping up at all. I want one log style window to hold all of that.
a quite uniform approach would be to add a new window manager hint that categorises an window as a “progress” one and could be shown in a taskbar icon only, spining, grouped by owner, in a special place, shown on all workspaces …
Any advantage to lamps over something like D-BUS?
LAMPS is similar to dbus in that it provides a lightweight middleware solution, however LAMPS was supposed to handle more than just message passing but provide an abstract and portable event handling system along with messaging, so LAMPS message queues could be multiplexed with sockets, Mach message queues, and VFS events through an abstract wrapper for select(), poll(), /dev/poll, kqueue(), epoll(), and DNotify.
>How do I set this up in KDE?
Konqueror
Settings -> Configure Konqueror -> Behavior -> ‘Show Network Operations in Single Window’
(It is the second option from top on that preference page.)
KDE 3.1.2 was used for reference.
Quickly install opera again and go to preferences – windows en enable “open pages in new window”
That’s not exactly what I want. I want web pages to show up in tabs (unless I specify otherwise), but I want file download windows to show up in their own seperate windows. This is possible with Mozilla/Firebird.
I really like this idea. You’d have to call it “jobs” not “processes” because the word “processes” has a specific meaning in OS parlance. It would also help improve the overall integrated “feel” of an OS, having all applications update their status in one place.
It’s about patience, grasshoper!
That’s not exactly what I want. I want web pages to show up in tabs (unless I specify otherwise), but I want file download windows to show up in their own seperate windows. This is possible with Mozilla/Firebird.
This is not possible with Opera, afaik. Transfers either show up in the Hotlist or the Transfers window. This is preferable behavior for me, but evidently isn’t for you, so I don’t know what to tell you.
This isn’t a new idea, the Processes Panel in NeXTSTEP was used to manage both applications and background processes.
Personally I’d rather have a small progress indicator that’s displayed automatically, rather than have to keep a panel open. A lot of apps put progress indicators in the taskbar. For example my download manager shows progress in the system tray, while my filesharing, CD-burning and MP3 encoding software all show progess in their taskbar titles. IMO that’s a perfectly good solution, it keeps them out of the way while still allowing you to quickly see the progress of the task.
I can’t think of many apps that still have modal progress dialogs that can’t be moved, personally I don’t find minimising or moving a few dialogs to be a big deal. The only time it can be a problem is when idiotic apps insist on grabbing focus when a task starts/finishes, but TweakUI can deal with them. Even on a fairly small monitor I don’t find a couple of file copying/moving dialogs to be a big problem. I suppose a central process window could be a good idea if you have a huge number of background tasks running. But I have trouble thinking of any practical reasons why that would be the case.
why the hell would that be a good idea?
it is harder to add an option to a system than it is to just rip out the old thing and put in the new one. keep the interface the same and you have no problems.
Anyone remember jobqueues on mainframe and AS400? Nice to see we are coming full circle.l
Surely if a programmer uses a standard API that handles progress bars all of the work could be done in the API, by having the application’s invokation of a progress bar send appropriate signals to the operating system.
A display app then need only receive and display this information. The app itself would handle the task, and could still display its own progress bar (what are you going to do? ask every programmer to rework their interface design for no progress bar?). You’d just have an extra way of viewing them all centrally.
This is not possible with Opera, afaik. Transfers either show up in the Hotlist or the Transfers window. This is preferable behavior for me, but evidently isn’t for you, so I don’t know what to tell you.
My only problem with this is that you actualy have to have Opera visible if you want to view progress bars, whereas if I have 2-3 files downloading and they’re all in their own seperate windows, I can simply glance down at the taskbar and instantly see the percentage completed of each. Doing it the Opera way, I actually have to un-minimize Opera and look at the transfer/hotlist window to see how they’re doing.
it is harder to add an option to a system than it is to just rip out the old thing and put in the new one. keep the interface the same and you have no problems.
Yeah, this is the same reason why people program desktop apps in Java “it’s easier to do cross platform stuff that way than coding it natively”. Nevermind if the speed and interface sucks shit … let’s do what’s easiest for the developers.
My point here is that just because it’s easier doesn’t always mean it’s better.
This may be a little off topic, but I remember once, I was installing BeOS a while back, and was making the boot disks and the little BeOS boot disk maker used a really cool progress indicator. Instead of a bar, it used a circle that filled in like a pie chart, or really like a clock. That stuck with me for some reason, I guess that I thouhg that that analogy was kind of neat. In a way, I guess it’s more intuitive than a bar. It’s not at all what this guy was proposing, I just though I’d bring it up.
On Panther when it’s out.
http://www.apple.com/macosx/panther/expose.html
Just a thought on extending that a little, I generally use more than one system, and I often have a system setup just to keep track of information, so how about you extend this a little more to allow an option to remotly monitor the progress of the apps, even making it a standard setup that would allow me to monitor my windows apps, my mac apps and my linux apps all on one screen using one program.
That is something I would find usefull, but most would likely not.
Enjoy!
Guess what? That’s in OPENSTEP too
GKrellm (http://www.gkrellm.net) is a compact system monitor that uses plugins to support a variety of monitor types and application-specific information. For example, there is a plugin to show the status of your queued downloads on the giFT network, another which shows alerts from the Snort IDS, etc. The current version also has a client/server mode, where a compact server application is run on each machine you wish to monitor, and the client polls them for information to update the UI.
The current version is fairly UNIX-specific, but I see no reason why a more general version of this couldn’t be done, and with the kind of refresh rates most of these applications require, (i.e., 1+ seconds per update) you could easily just use an XML-over-sockets protocol to pass the status updates around. Separating the UI from the backend would be vauable, as well, so that you could support different rendering styles for each platform (i.e., taskbar or system tray on Windows, the dock on OS X, etc.).
It’s not a system-wide thing, but it wouldn’t require system-wide changes, either, which means that people could buy in on an application-by-application basis, rather than an entire operating system or desktop environment.
Something very minimal and simple would be nice. BeOS’ replicant feature would be great for something like this, in that you could make progress bars into replicants and allow them to be dropped into an area on the desktop where they could all be monitored without needing to do any window switching or even have a window open.
Just sounds to me like more BS tinkering with the UI so you have to have all your users re-learn things… Again. In other words an MIS managers nightmare.
I’m getting really sick of all this UI tweaking. It is about as big a BS as the slap of paint they put over XP with the Luna theme, or the stupid things like Mouse shadows or fades and scrolls on menus. Maybe if they spent less time making everything do goofy animations and more time on making the Core OS work we’d have less bugs in our OS’s.
Dosen’t VMS already do this.
Personally I would vot on little circular pie charts in a
status bar of sorts, When the mouse over (focus in eent) is seen it pops up (using 3D nomenclature of a springing to a larger view) and shows the app an pie chart (Transparent at 40 percent to scrolling text showing where in the job its at. The textlayer is 20 percent transparent so the main desktop is still visible.
Hey just my 2 cents.
Leslie Donaldson
hmmm, maybe I should right this for X, except for OPEN-GL on the main frame buffer the rest I could do pretty eaisly, A few focus in etc, have it use a socket or some other form of ipcs (shared memory mamybe) and for the effects I could use open-gl on a non visible framebuffer (offscreen) pull the frame buffer back across the bus , shove the image through the shape extension and render it over the desktop… hmm I still need to see if the render extension for X is useable yet to make the entire thing slight transparent…. About 2 weeks playing. hmmm… HAve to consider this.
Donaldlf@no_spam_here:cs.rose-hulman.edu
> why doesn’t a Windows window have a button to
> send it to the back? And why does it jump forward
> even if you click anywhere, covering up some other
> window which you want to see?
PowerToys / TweakUI.
http://www.microsoft.com/windowsxp/pro/downloads/powertoys.asp
http://www.microsoft.com/ntworkstation/downloads/PowerToys/Networki…
Allows you, among other things, to have the focus following the mouse without the accompaigning window popping up. That made the Windows desktop bearable for me. (Combined with DOpus 6… hail to the Amiga! 😉 )
There are occasions where a progress bar window could be avoided (1) changing the mouse cursor shape or (2) using the statusbar.
(1) I’m thinking of PMView here. When you apply a complex filter, when the mouse is over the window, it changes to the shape of a wall clock with just one handle. This handle is representing the status. The picture goes from 12 o’clock (=0%) to 3 o’clock (=25%) to 6 (=50%) to 9 (=75%) to 12 again (100%).
The reasoning is: you want to see the progress when you are waiting for it to finish. If you are doing something else, you will notice when the image in the window changes.
(2) In GIMP and in ACDSee, when you load/save a file, the statusbar of the image window have a little progressbar.
I think we all agree that a lot of windows in the desktop is not practical…
This is my first comment here, so let me thank all of you for reading the article and providing such interesting feedback. Let me be more specific now:
To dysprosia:
I was interested in the OPENSTEP system once upon a time, because it is really advanced technically. I wanted to experience a true object-oriented system and experiment with the Objective-C language. I spent hours reading documentation and setting up the system. When I got it up and running I was disappointed.
I didn’t notice at all how OPENSTEP handles the time-consuming operations. The thing is, there was almost nothing to do in OPENSTEP, no Workspace Manager application that would perform a time-consuming operation for me so that I would find out about the Process viewer you mention.
In any case, I am proposing the inclusion of such a feature in a modern desktop where multiple jobs do exist, and in these desktops the proposed feature is absent.
To Daan:
You may be the first reader who has exactly gotten my point. Thanks for your attention and your comment.
Pop it open by Cmd-P (Cmd-Shift-p, or through Tools->Processes) and do some WM stuff, you can see it working for the processes you’re performing until you close it.
If you compress something nice and large, or do a lot of disk operations at the same time, and you have the Processes window open, you’ll see how it handles.
Why were you disappointed with OPENSTEP? OPENSTEP is a truly beautiful operating system, and a joy to use! It’s very technically advanced. I won’t rant on how much I love it, though
This can only work to replace for non-modal dialogs.
For example, say you had a word processor, and you wanted to translate a large document from english to french. You click the translate button and you then have to somehow lock the document so the user cannot continue editing in english. This locking is performed by a modal dialog box in most cases, and this will have a progress bar on it. The same would be true of a photoshop filter. You cant have the user editing the image while performing filters on it.
I like the idea of temporary background tasks getting better representation in a desktop environment. A little like Windows tray area does for non temporary background tasks. But you cant just apply this to every situation – it eneds to be an option available to developers.
…but Apple had to throw away Workspace.app and reimplement
the Finder for Mac OS X…
The progress monitor also needs to have a cancel button for every job — that works. Half the progress bars I’ve seen don’t actually respond to the cancel button, or you click cancel at 50% and several minutes later when it’s reached 99% then it cancels.
As mentioned above, there are some solutions regarding clutter. But what is more important is the resources used to run these tasks are not proportional to the purpose/benefit of these tasks. A simple, text, percentage counter should be more than sufficient to accomplish the same task.
You can’t have separate dialogs for each transfer, but you can put the transfer window in a separate window. Simply create a new window (ctrl+alt+n) and open the transfer window in it (ctrl+alt+t). You can then make that window the size you want and keep it visible on screen to quickly see the progress of downloads.
But personally I use a download manager that integrates with Opera and takes over any downloads.
Perhaps something like this?
http://www.esware.com/~apg/shots/progress-bar.png
It’s only a mockup.
Another one.
http://www.esware.com/~apg/shots/progress-bar2.png
YES! This could be one view of the Progress Monitor since it doesn’t include all of the fields mentioned in the article, but only the progress indicator and the icon representing the calling application (including a status indication if I understand well). But it certainly is a view of the proposed idea, and a fine one –even if a bit oversized for the amount of information it offers.
I should add that the Progress Monitor could have multiple views with varying levels of details displayed. In one view all the fields proposed in the article could be presented. Another view could be just as in the (mockup) screenshots. A more detailed view could offer even a custom area for every application to display its specific information. For example, track information for CD recording, document information for printing, location information for downloading, package information for installation of files etc.
And while we’re on clutter, why doesn’t a Windows window have a button to send it to the back?
Try ALT-ESC
The main difficulty something like this is facing is IPC. […] I started a Sourceforge project to deal with this very issue
it’s a non-issue. There’s already an old and pretty mature standard for portable network-transparent IPC: OSF RPC. It’s what Digital’s, Sun’s and Microsoft’s RPC mechanisms are based on, in turn what whole parts of their operating systems are based on (Sun RPC is the foundation of NIS and NFS; Microsoft RPC is Windows)
Despite what you may think, it doesn’t require sockets at all, and Microsoft RPC, with its “ncalrpc” transport protocol based on message passing and shared memory, is a perfect example of this