Plop—Click—Gone

Let’s assume you have to develop a user interface. Clicking on a button in the interface starts a lengthy task. As you know that this task takes some time (e.g. 30s), you decided to run it in the background. To inform the user that there is a task running, you display a small progress bar in the status area of your window. You even thought of a cancel button next to the progress bar that actually works. So far, your decisions were wise.

Back in the days, when this task was not running in the background, you automatically opened the results pane once the task completed. Back in the days, this was wise. But now it no longer is. Why?

When the task ran in the background, the user had to wait until the task has finished. She did not start anything else, at least not within your application. When the task ended, opening the results pane did not interfere with what the user did.

Now, since the task does not restrain the user from doing something else, opening the results pane will probably interfere with the users new work. This is what just happened to me: I continued to work, and, right when I clicked on something, the results pane popped open. It popped open in a way that obscured the interface item I wanted to click on. And it was placed in a way that showed the close button right where I clicked. Great design! Plop—click—gone.

To be honest: I was not working while I waited for the task to complete. I was just using the freedom to look through the elements in the application. So, I lost the results just because I could (play around as well as lose them). I lost them because the task was no longer modal but presenting the results was.

Software development is like crossing a busy street: Walk on one side or the other but don’t stop in the middle.