Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Imagine you'll have always a button labeled "Continue" in the same position in your app's GUI. Would you rather make a single button instance that takes different actions depending on the current state?

private State currentState = State.Step1;

private ContinueButton_Click()
{
    switch(currentState)
    {
        case State.Step1:
            DoThis();
            currentState = State.Step2;
            break;
        case State.Step2:
            DoThat();
            break;
    }
}

Or would you rather have something like this?

public Form()
{
    this.ContinueStep2Button.Visible = false;
}

private ContinueStep1Button_Click()
{
    DoThis();
    this.ContinueStep1Button.Visible = false;
    this.ContinueStep2Button.Visible = true;
}

private ContinueStep2Button_Click()
{
    DoThat();
}
share|improve this question
1  
I favor the first approach over the second one. Having multiple buttons for what is essentially the same operations is really awkward; you'll have to stack them on top of each other and hide and show them as needed for each step. The button always means the same thing anyway; it means Next. –  Robert Harvey Sep 6 '12 at 19:35
    
The second approach gets uglier faster than the first. Imagine there are more steps and then you'll realize. –  Jader Dias Sep 6 '12 at 19:45
    
But the first approach seems to be more difficult to debug. –  Jader Dias Sep 6 '12 at 19:45
    
How many different states? Can they change often? Does state affect something else than those buttons? –  Euphoric Sep 6 '12 at 20:21
    
If you use a few pictures with example UI states instead of example code the question will be clearer. Also, this question (after correction) would be better off in UX.SE than here –  Danny Varod Sep 7 '12 at 0:06

3 Answers 3

My proposal is to have a single button, but instead of the switch statement, have a listener interface which is implemented by classes that processes the clicks, and on every click, change the listener that is now responsible.

class myForm extends Form {
   ClickListener listener1 = new ClickListener_page1(this);

   private Continuebutton1_Click() {
       listener1.click();
   }
}

class ClickListener_page1 implements ClickListener {
    Form form;

    public ClickListener_page1(Form form) {
       this.form = form;
    }

    public click() {
        page++;
        // here goes all the stuff to process page 1
        form.listener1 = new ClickListener_page2(form);
    }
}



class ClickListener_page2 implements ClickListener {
    Form form;

    public ClickListener_page2(Form form) {
       this.form = form;
    }

    public click() {
        page++;
        // here goes all the stuff to process page 2
        form.listener1 = new ClickListener_page2(form);
    }
}
share|improve this answer
    
It avoids the clutter caused by multiple buttons while keeps it easy to debug –  Jader Dias Sep 6 '12 at 19:48
    
This seems unnecessarily complicated for little additional benefit over the switch approach. –  Robert Harvey Sep 6 '12 at 19:50
1  
Actually, instead if instances of an interface, where the interface declares just one action, in C# I would prefer the use of delegates or Action<> variables, which makes the code probably simpler than using a switch. Don't know if Java has something like that. –  Doc Brown Sep 6 '12 at 20:11
    
@DocBrown right; in Java, anonymous classes could be used to avoid creating too much code. –  user281377 Sep 6 '12 at 21:04

I've stumbled upon this in the past. I had a button changing its label (from Next to Finish) but otherwise keeping its position. I used two distinct buttons.

In general, I prefer using different physical buttons and playing with their visibility, instead of using a single button and changing its behavior. The rationale is simply that the former is easier to understand and maintain. Imagine expanding your problem to multiple buttons which can have different behaviors in different contexts and having to change the listeners on those buttons when the context changes. This can push you into an artificial pattern of having to save references to, or re-instantiate your button listeners, or devise artificial click handling schemes.

That said, in some cases the logical model dictates the use of an action with contextual results, such as "Save". If that action is prominently displayed in a global area, such as a header, such as it is always visible, then I believe it makes sense for that action to remain shared. Of course, in such a case, the action delegates to the screen currently displayed in order to achieve the action, so, again, logic dictates your outcome.

If there is a different logical action, different listeners, little relationship between the actions, these are strong indicators of the need to use different buttons and adjust their visibility based on context.

If, on the other hand, the actions have a common pattern (as supported by the button label - probably your case), then use a single button and investigate the possibility of delegation to the current context to achieve the action.

[It's interesting to think about, in the latter case, dealing with common pattern actions where some require more user input (actions that should have an ellipsis (...)), and some do not, in which case it becomes tricky to use the same button.]

share|improve this answer
    
Visibility should not constitute a strong force in the decision. After all, altering visibility is only one of the ways in which we conceptually swap actions. We could just as well choose to disable the alternative actions (some might argue that it is preferable to do so, since the user learns that the actions are at fixed locations, and she is exposed to more of the action model at all times). The fact that we choose to alter visibility sure gives us the opportunity to merge otherwise distinct actions, but we should resist this temptation. –  Mihai Danila Nov 7 '12 at 16:42

If the operations are the same just on a different context (e.g. all are next or all are appply or all are send) you should use the same button.

If the operations are different (e.g. volume up vs. channel up or adjust equalizer) do not use the same button or position.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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