Is it possible to cancel the disconnecting process?
–
finspinDec 27 '12 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-MattDec 27 '12 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.
–
vszDec 27 '12 at 19:41

@vsz You make a good point. What would you suggest in this situation then as an alternative?
–
DTI-MattDec 27 '12 at 19:57

7 Answers
7

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.

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.

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.
–
BevanJan 18 '14 at 19:10

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.

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.
–
Marjan VenemaDec 27 '12 at 19:35

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'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.

"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.
–
AndyDec 27 '12 at 18:10

Please provide evidence for your statements "neither of which is good" and "Building one button will destroy maintainability and stability."
–
Joel GarfieldDec 28 '12 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.
–
Michael PerrenoudDec 28 '12 at 16:52