Martin Colebourne

Several times in my career I have been involved in the design of a visual skin for basic UI controls – usually as part of a much larger project. Designing individual form controls doesn’t seem too hard, or like much of a priority, but actually they are surprisingly complex beasts and it’s easy to get it wrong. At the same time, this kind of detail really matters – a set of clumsy buttons can throw off your impression of a whole product.

One aspect of designing form controls that takes care is figuring out how they should respond to the different interaction states that they can be placed in – for example, what they do when you rollover them with the cursor. This gets particularly tricky when states can be combined, such as keyboard focus combined with rollover.

What shouldn’t be tricky is knowing what these various states are and how they relate to one another for the different controls. However, I haven’t actually found a neat definition of this and each time I’ve worked on this problem the team has ended up wasting time and effort with confusion and miscommunication over the exact properties to be covered. So here is my attempt at creating an all-encompassing, well-structured representation of the control states. Let’s hope I didn’t forget too many!

For this description, I’ve concocted some very simple example controls, with a basic appearance. Don’t worry about the specific design – its just an example. Four controls are shown here: button, checkbox, dropdown and input box. You should be able to see how to extend this to cover the rest.

I’ve identified 5 possible interactive states that a control can occupy:

• Normal – as it sounds, the normal state of the control.
• Rollover – when the cursor is placed over the control.
• Clickdown – what happens at the moment you click the mouse over the control (it lasts for only the length of the click, but is important in signalling that your click was registered by the system).
• Active Edit – the state of the control as you make changes to the content itself.
• Text Selection – how the control looks when you select text during editing.

These states are not enough though. They need to be combined with 3 possible ‘conditions’ of a control:

• ‘Not in focus’ – the state of the control when it doesn’t have keyboard focus.
• Focus – when the control has keyboard focus.
• Disabled – when the control cannot be interacted with – e.g. because it is not applicable at that time.

Here is a simple button used as an example.

Note first that the button has neither an Active Edit state, nor a Text Selection state, since the content of the button can’t be changed or selected. There is also no visual representation of a Rollover or Clickdown state for the Disabled button (such states could be designed, but they are not usually used).

Note that in this example that I have used different types of treatment to signal the conditions – primarily fill effects for the states and stroke effects for the focus. This kind of separation is useful since the two effects can easily be applied at the same time where they coincide – e.g. rollover of a button that is already in focus.

I have shown a distinct visual appearance for each of the valid combinations. However, this isn’t necessarily needed – as an example, Apple’s OSX Lion does not use a rollover state for the majority of its controls. What you support is a design decision – albeit one that may also be informed by time and the complexity of coding all the variants.

This next diagram shows a simple dropdown. In this case, there is an active edit state: the point at which the dropdown is open and you can select a different item.

Note how I have applied pretty much the same visual style to represent the same states as in the buttons shown earlier – this is good practice, since it leads to a consistent overall feel.

This example also shows another detail – there is only one Active Edit state – regardless of whether you reached it via the keyboard or the mouse, as represented by the arrow. This is because, once you click on the dropdown, it automatically takes keyboard focus as it moves into Active Edit state.

An even more complex example is the input box shown here. In this case, there is no Normal-Focus or Rollover-Focus state, since as soon as an input box is placed in focus using the keyboard, it moves directly into Text Selection state. At the same time there is no ‘Non-Focused’ Active Edit or Text Selection state, since, by definition, the control must have keyboard focus in both of these states.

The final example here is the Checkbox. This shows much the same states as the button, except that the whole array of states is duplicated in order to account for the fact that the control can be either unchecked or checked (‘Selected’). This same property of multiple overriding states applied to other controls – notably the radio button, but also buttons that can be toggled between an on and off state and several others.