« Google Chrome Start Page Thumbnails | Home | CD/DVD Drives and Windows »
Don’t Allow Your Application to Hang
By Jacob Cohen | September 15, 2008
One of the more frustrating things a GUI application can do is to become unresponsive while it is doing something or waiting for something to happen.
For example, to pick on Microsoft products, both Excel and Outlook have a problem where, if they are waiting for some operation to complete (such as fetching data from a remote file, or opening a .pst file locally), the application will not respond to anything, not even the message from the operating system telling the app to paint itself. From the user’s perspective, the app is frozen, and only experience tells them to just wait a few moments and the app will “recover”.
Applications often use a progress bar to indicate that stuff is happening, seemingly to show about how much relative time is left to complete the operation. But a new fad has been sweeping GUI application design in recent years: the “circular progress bar”, as I call it, which will reset to the beginning when it reaches the end. These progress bars are meaningless for determining if anything is actually happening, or how much is left. They are seemingly only there so that the user can see that the app has not frozen. The problem is, when the application reaches some particularly intensive calculation, or waiting on some data, the progress bar freezes! It can’t even keep a simple animation running.
Are GUI programmers so afraid of multiple threads or processes that they allow their applications’ very responsiveness to wait synchronously on something else their application is doing?
Sometimes it doesn’t make sense for the user to be able to perform any new actions before whatever else they did has completed, but they should at least be able to raise/lower the window’s focus, move the window, see the data that was in the window before, and especially cancel whatever operation they had kicked off.
And please, if you include a progress bar, make it meaningful. Circular progress bars are about as useful as the rotating hourglass mouse cursor.
Topics: General |
October 5th, 2008 at 6:25 pm
Yes, it is seemingly difficult to code multi-threaded applications. Coding synchronization is difficult and creates some overhead.
Although, It should be noted that many GUI’s are multi-threaded. At least mine are. The problem isn’t whether it is or it isn’t - but the execution scheduler on windows.
It is completely possible for a thread that is performing a large number of calculations recursively to slow down the application as a whole - even freeze it. I believe its because the other threads (namely my GUI) is not getting execution time.
Then again, I may be doing something wrong.
October 23rd, 2008 at 5:39 am
Man, patience of users these days is no longer then 10 seconds, if anyone expects to reduce frustrations in an application and thusly increase reusability they better insert something in a more obvious place that shows the user their command was not ignored.
As I always think, users are just babies. Need to get something done, and know what the fuck they’re doing.
I have to say though, that websites seem to have the idea down pact!