Using the Return key with Back and Next buttons on web-sites

When it boils down to it, most sites on the web are just gloried data crunchers. Users enter information, which the system churns up and splits out again at some point in the future, potentially to a different user.

If a site requires a lot of information, it is common to see multistage wizards, with each stage asking for a small portion of the information. Each stage usually has a Back button and a Next button. Convention and common sense dictate that the Back button should be on the left, and the Next button on the right as in the following example:

Type something here:
… and here:

NB: The onclick events return false to prevent the page from actually submitting.

This all seems to works fantastically, and even uses tabindex to ensure that the user tabs onto the Next button before the Back button… until someone comes along that prefers to use the Return key to submit the form, instead of using the mouse or tabbing to the Next button. In this case, the Return key will call the first submit button it can find, which in this case is the Back button. This is not the expected behaviour! Put the cursor in one of the input fields and click Return to see this in action.

One solution to correct this would be to use floats and/or JavaScript to try and reverse the order the buttons are displayed in while still having the Next button placed highest in the HTML to ensure that it would respond to the Return key. However, if a user disables CSS and/or JavaScript this solution will fail. A simpler option is to create a hidden submit button as the first element within the form, which performs the desired Return key operation. The order of any other (visible) buttons on the form is then irrelevant.

The following form demonstrates this:

Type something here:
… and here:

Again, put the cursor in one of the input fields and click Return to see this in action. The only downside to this is that the user will see another submit button if they disable CSS, but in most cases I think it is still the best solution.

Basic fluent interface

Fluent interfaces seem to be everywhere these days, probably because they can be used to produce highly readable code. They use method cascading/chaining to achieve this, whereby method calls are made one after another on the same object reference.

Good examples are the LINQ component in .NET and Fluent NHibernate, obviously!

Here is a really simple example to demonstrate how you would go about writing a fluent API, in which values can be added to or subtracted from a numeric value. This is encapsulated in a Number class:

public class Number
{
    private int currentValue;

    public Number(int value = 0)
    {
        currentValue = value;
    }

    public int Value
    {
        get
        {
            return currentValue;
        }
    }

    public Number Add(int value)
    {
        currentValue += value;
        return this;
    }

    public Number Subtract(int value)
    {
        currentValue -= value;
        return this;
    }
}

Note that each of the chained methods returns the current instance, via the this keyword.

The Number class can be used as follows:

public static class Program
{
    public static void Main()
    {
        var number = new Number();
        
        number.Add(1).Add(2).Add(3);
        Console.WriteLine(number.Value);

        number.Subtract(4).Subtract(1).Add(2);
        Console.WriteLine(number.Value);

        Console.ReadLine();
    }
}

As an aside, adding the ability to multiply and divide would significantly increase the complexity of this class, since the order of operations would need to be taken into account.

However, hopefully my example shows how fluent APIs are put together.