5

My application has a toolbar and a lot of buttons on it. Some buttons start a long running processes(tasks). At this moment every task executes asynchronously to allow user to do something else while task is executing. Thereby I have a problem: user can click the same button many times to start others same tasks. I have decided to disable button before start task and enable it after finish. Other problem, I should to protect other buttons from pressing (some of these would be disabled after done current tasks). In general, I have to disable all buttons (toolbar) to be sure that user cannot do something dangerous with buttons at transient. My questions are:

Could someone recommend way to distract users from flickering (disable/enable buttons) or how to involve them in process, how to made them filling that task is not so long?

Maybe I should to execute tasks synchronously and disable all UI for time of execution?

By the way: Delay can vary from 1 to 10 sec. About progress bar: it is a difficult to calculate current progress, and it causes some performance degradation (task can be done faster without any additional UI iterations from other threads).

Improve this question

5 Answers 5

Reset to default
4

Ultimately this is a problem about keeping the user informed by providing good feedback.

The first thing to do right away is indicate that the button was pressed and not to let them think that it can be pressed again. That is often done by disabling the button, but see further below for an alternative.

Since your delay can be of variable length, then the method needs to be able to inform the user how much longer the task is going to take. If calculating the progress is too difficult then you can indicate that it will take 'just a few seconds'. Make sure to use positive terminology.

I'm really not a fan of disabling chunks of ui temporarily - there's always that risk it may not get enabled again if something fails. So when needing to block the ui, I would prefer the option of a modal dialog to inform the user of the above message. Besides, disabling the ui is not a directly related feedback mechanism, it is a programming hack and simply leaves the user wondering what is going on.

So to give the user feedback about the current task, either use a modal dialog to show the above message and block the application, or display it in a feedback/status area within the application, depending on whether you want the user to be unable/able to interact with the ui.

If you do decide to let the users access the rest of the ui, while the task is active, then all the functionality should appear to work as normal. On the button that started the active task, you could indicate that this particular function is active. Commonly this is done by disabling the button, but a more directly communicative idea is to add a corner icon to the button to undicate the active state. This could be a small hourglass or other busy icon. If the user clicks the button, they can simply be informed that the action is already active. Tooltips can also give the active status. This idea of very localized, contextual per-button feedback should work very nicely.

Improve this answer
0
2

Ideally, you would want your application to be as responsive as possible to user input. So, it definitely makes sense to perform long running tasks asynchronously.

As far as user resubmitting the same task goes, you have a few options:

  1. Disable button before task/enable after task (this would be my default choice without knowing what exactly your application does): It seems you already do this. Developing the correct logic for disabling/enabling buttons can become complex but is worth the effort if it makes your application more intuitive to the end user.

  2. Cache submitted tasks: if a user submits a task, cache the input parameters. When he submits the task a second time, and the input parameters are in the cache, then don't start the task a second time (as it is already being executed). This option depends on task execution being idempotent, so will not apply to all cases, but when you can use, you don't have to worry about disabling/enabling logic.

  3. Just execute the task multiple times: this is not recommended(!) as an approach, though in some cases it might make sense. For instance, if you are only building a prototype (like a minimally viable product), then you want to get the application out there as soon as possible. In that case, learning about how the application is used is more important than wasting computing resources. It might be that those tasks are not even used, so you would save time by not developing something for them.

Improve this answer
2

If you want to avoid the flickering, you could follow Joel's advice: "Don't hide or disable menu items" and when a user presses a toolbar button for something already executing or that would interfere with another executing task, you can then either show a message on why you can't complete the users request or "cache submitted tasks" (and have a window of tasks to be executed) or just do as the user requests and execute it again (be aware of synchronisations problems here).

Improve this answer
5
  • Disabling, or disabling and showing busy icon on image is much better way than show message when button is pressed. Because when button is disabled user know, that something is happening, when button change state back to enable, he knows that now it's possible to start new task. If he will need to press button to check if task is completed or is still running, he becomes very unhappy.
    – Dainius
    Feb 3, 2012 at 10:40
  • @Dainius: there are many that do not agree with you. Disabling buttons will generally make an application harder for people to understand, especially when not enough is done for them to find out why the button is disabled. Read the link in my answer if you want to know more. User don't know what you mean with your changing state and different images until you tell them (or let them discover it) in a very obvious manner.
    – Marjan Venema
    Feb 3, 2012 at 13:11
  • Marjan that was just mine opinion, but if you will look at ux.stackexchange.com/questions/12756/… even Joel agrees that "f you can provide a tooltip explanation that will be easily found, disabling is fine". In more basic way IMHO disabling is a bit better because user will know that he can't do something before he try, as when he try and fail disappointment of failed action will be bigger (as he already did action). Disabling usually means that user forget to do something and that action is unavailable and with tooltips is very powerfull.
    – Dainius
    Feb 4, 2012 at 12:56
  • @Dainius: yes, as I said "until you tell them in a very obvious manner". Disabling + telling why with hints is one such manner.
    – Marjan Venema
    Feb 4, 2012 at 13:09
  • In ideal world all program should be made in such way ;) But was thinking about more simple scenario - there's a text editor with menu copy.You can copy only selected text (abvious).And take 2 scenarios-user don't select any text,open menu edit,pressing on copy as it's available, than open some other program and try paste there-he can waste few minutes until disovers that text not copied.He can get message that no text selected,but even than he need press copy,read error text and press ok.If copy would be disabled he would not make mistakes about thinking that text is copied.
    – Dainius
    Feb 5, 2012 at 10:16
1

A quick suggestion: can you make it a "checkbox button", having its "Pressed"/"Checked" state indicate that task is running. Then automatically "un-press"/"un-check" it when the task async finishes?

Improve this answer
1
  • +1 as half-solution. It has other buttons that can be disabled/invisible after task will be done.
    – igor
    Aug 23, 2011 at 11:47
0

I would not disable the button but instead internally make sure the action is called while already running. I would however made sure there is good feedback when the action is running, and when it has completed.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.