Consider this scenario:

A "Connect" button, which changes to a "Cancel" button when clicked. When the connection succeeds, it changes to a "Disconnect" button.

Should this be handled with 3 different buttons (made visible / invisible), or by a single button (check buttontext/tag too see what action - connect/cancel/disconnect - should be taken)?

  • 3
    In general, buttons shouldn't perform multiple actions.
    – DA01
    Dec 27, 2012 at 16:45
  • Is it possible to cancel the disconnecting process?
    – finspin
    Dec 27, 2012 at 17:52
  • No, the disconnect happens so rapidly that it wouldn't be possible to cancel the disconnect. But if you're connecting to an IP Addres that doesn't exist, or that is not listening, you'd want to be able to cancel it rather than wait for the timeout.
    – DTI-Matt
    Dec 27, 2012 at 19:22
  • 2
    Just imagine how many inexperienced users will double-click on your button. I've seen quite a lot of people who don't know when to use single and double clicks.
    – vsz
    Dec 27, 2012 at 19:41
  • @vsz You make a good point. What would you suggest in this situation then as an alternative?
    – DTI-Matt
    Dec 27, 2012 at 19:57

7 Answers 7


I'd probably opt to use three separate buttons so that I'm not having to litter a single button's click method with state handling for the different statuses of the connection.

On the other hand, having a single button would enable you to have just the single control, change its text as necessary, and stack the logic in a switch statement as needed.

If the application is one that's going to be touched by anyone else, I'd definitely go with the separate buttons, but if it's a pet project of yours and you can handle its idiosyncrasies, I'd go with the single button scenario.

  • 4
    I think this is not a question of maintainability, but usability, and therefor your last statement seems like the wrong basis for decision to me.
    – kontur
    Dec 28, 2012 at 11:38
  • I agree with kontur... Maintainability and click method issues should not cloud the importance of usability.
    – daydalis
    Dec 30, 2012 at 21:40

For your case, since all the buttons are dependent on each other and cannot be enabled simultaneously, I would say a single button would work best.

The best practice is to point the user to the change in text of the button. Wherever I have seen this remove the text from the button, turn it into a lighter shade, bring the second text on the button and then turn the button back to the darker shade. This slight change in shade of color gets noticed since the mouse-over would still be over the button. (Since you are changing the button text as soon as they are clicked). I find this to work fairly well in practice for wherever I have seen it in action.

  • The problem with using a single button is that you're assuming the program will update instantly to a click, showing the state change. There are any number of reasons outside of your control why a click won't be processed immediately (e.g. application memory has been swapped out; another process is consuming 100% of the CPU; the machine is in a low power state). This gives a situation where a user clicks on the button, gets no response, clicks again, still gets no response, clicks again, then your application wakes up and processes all three clicks. Boom.
    – Bevan
    Jan 18, 2014 at 19:10
  • Relevant: ux.stackexchange.com/questions/1215/…
    – Bevan
    Jan 18, 2014 at 19:18

That's what Firefox is doing with "refresh" as your "connect", and "stop" as your "cancel." They are having two things in 1 button. But while it's connecting, you should have some kind of cue like a spinner to signal that's it's connecting. So that the user know the button changed to cancel because it's connecting right now. And once the connecting is done, you change from cancel to disconnect.

The spinner is very important in smoothing out the sudden effect brought by the button changes, as that's the only thing that explains why those buttons changed from one to another, since you don't want the users to use their brains to think about that themselves.


Seeing as in this scenario the three buttons all related to the same type of action, there is no problem with using a status-dependent button text.

It would help the user to label the button with something that gives a clue as to what it manipulates, i.e. Connection and the button then gives the action you can apply to the connection.

Additionally you could or should signal the change in button action to the user somehow. This could be fade the button out and then in with different text, or somehow highlight the button while the text changes, anything that make the user realize the button function changed.

The same type of approach works with forms where you have data and a button to manipulate, which, when clicked, changes into a save button. All in all, this method can actually declutter the UI, but you have to be careful not to make things incomprehendable.


I'ld prefer the solution with a single button. Three buttons on the same location are needlessly complicated to maintain. Three buttons with two of them grayed would confuse the user. If you are changing the Text property, you don't need the Tag property. Just change and check Text.

It might be a matter of taste, but from my experience it is better to have as few controls as possible. If there are three buttons and only one of them enabled, superfluous information gets displayed. What is the point to tell/show the user what he potentially could do in another state? He might never enter that state again or might be fully aware of it. Follow Einstein's motto that everything should be made as simple as possible, but not simpler.

  • 1
    Why would it confuse them? It would actually give them the means to learn that you can only disconnect while connected and you can only cancel when connecting but not connected yet. Dec 27, 2012 at 19:35

This should most certainly be three different buttons. You simply want to make the buttons visible when they should be - much like a wizard would.

If you make them one button you're going to have statements like if (this.button.Text == "Connect") or you might even use a switch, neither of which is good.

Building one button will destroy maintainability and stability.

  • "Building one button will destroy maintainability and stability" - Since the button should just check state and then call another object to do the real work, I disagree with your answer. I think three separate buttons would be more difficult to maintain, especially since the handles will likely have a few lines of code at most. Sometimes less is more.
    – Andy
    Dec 27, 2012 at 18:10
  • Please provide evidence for your statements "neither of which is good" and "Building one button will destroy maintainability and stability." Dec 28, 2012 at 16:47
  • @JoelGarfield, I'm not sure what evidence would suffice, but if you've ever opened an old VB6 form where they used one form and just turned a bunch of panels on and off you would realize that building one component, to do one thing, is by far more maintainable and stable. A single button with if or switch statements in the code-behind clearly states that as a button I don't know what I do until I take a look at what I look like right now. But a single button, that does something, well it clearly ... does something. Dec 28, 2012 at 16:52

The question of whether it is one button or three buttons where two are hidden is sort of irrelevant to the user experience. It's mainly a programming issue with pros/cons as Darth explains.

I think the better question is: If I want to have one button that does more than one action, how do I make sure the user experience is good?

To which I think the answer is to make sure each action is clearly illustrated to the user, possibly with a color and an icon, and that there are precautions taken to prevent the user from double clicking and doing two different actions. Perhaps when they click an action, the button switches to a spinner for at least a second - during which time it can't be clicked again. Then it switches to the next state, where another action can be done.

If there are two actions, you could use some kind of sliding toggle button.

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.