In this last section, we're going to look at how some of our interface elements can have various different states of existence and how they can change from one state to another, in other words, how they can be both static and interactive elements in our interface. The simplest and most common multi-state object is the button. A button has to have different states so it can convey to the user the fact that it's being interacted with. So, first of all, a button can let the user know it's a button by having some kind of state change. So, the user knows it's not just a static element, it's an interactive element. Secondly, a button can also change states to acknowledge the user's action, in other words, to let the user know that their tap or click has really worked. So, let's look at some of these different states for a simple button and look at different ways that they could be visually represented. The button has a normal state when nothing is happening. If you put your cursor over the button, there should be some kind of state change to let you know that the button is live, and this is called the hover state. Then, when you actually click on the button to activate it, there needs to be another state change to let you know that the button has been pressed. Then, the final stage is after you've pressed the button, there needs to be some kind of change from the normal state that it began in so that you know that the button has been clicked on. Not all buttons have all of these states and these states can vary as well depending whether you're using a mouse with the cursor or whether you're using your finger. But for the sake of this exercise, let's keep all four. So, if we add some color to try and denote the different stages, we create a hierarchy should the density of the color and through the contrast with the type. So, our press state and our normal state feel very different to each other. We can change the background color of the button but we can also change the color of the typography on the button as well. We can see from this example that the normal state and the press state of the buttons that have the most visibility, the most contrast. The inactive state has at least contrast because we want that state to kind of be ignored. By changing how we use the color in the background, we can emphasize the action, the activity, in this case pressing, and make that be the most important visual aspect of our four buttons. The trick here is to have the buttons look different enough that they can represent different states but look similar enough so that they can belong to the same family. You also have to consider what kind of background the buttons are going to exist on and whether they're going to need an outline so that they'll stand out on different backgrounds or not. In general, you want to keep the buttons as simple and as clean as possible. You could think about how much contrast you want to have between each state. You can have a lot of contrast between normal and hover for instance or it could be a very subtle change. You could also use Trompe-l'œil effects to create difference between your states. So here, you can see a different amount of drop shadow within the different state changes, as well as a change in the tonality of the buttons background color. So, there are many different ways to formally represent the different states that a button may have, and it's interesting to look at what kind of purpose the state changes have for the user. To begin with, in the normal state, the user has to know that the button is a button. They have to recognize that it's something that they can click on or touch or activate. So, there's a sense of recognition knowing that the button's a button. In the second stage, the hover stage, it's more about conformation. If I put my finger over the button, for instance, I know that something could happen but it doesn't necessarily have to happen until I actually press it and enter the activation stage. Then, the last stage, when the button is inactive, could be termed as rejection because we're no longer interested in that button. We could take some of these concepts and try and apply them to different kinds of buttons and see what happens. As I mentioned earlier, not every button has every state and things are a little different between using a mouse and a cursor and using your finger on a touch screen. But we could take the same stages and apply them to a button with a symbol on it or we could apply them to a button with a logo type on it. There might be a number of different formal ways for us to represent these four stages, and as I said, we might not even use all four of those stages, but this is where the user interface designer gets to decide which is going to work the best. So, let's try and see what happens if we take a totally different kind of button, not just different content on the button but a button that functions in a slightly different way and interacts in a different way. So, here's a toggle button for instance. It only really has an on and an off as its two states. So, the hover state might be the same as the normal state. The activated state is clearly different. When we've slid the toggle all the way over to the right. The inactive stage is the same as the normal and the hover stage. But let's try and slow things down and see what happens when the user really interacts with this toggle switch. There's an in-between stage that happens very quickly where the user is sliding the toggle from left to right to activate the switch and sliding it from right to left to make it inactive. So, there's these hidden stages that happened very quickly, and these take the place of the hover state and the inactive state. If we go to our other set of terminology we recognize the toggle button because of how it looks. Our confirmation is that we can actually move it. Our activation is seeing it come up in green, and our rejection is being able to turn it back off again by sliding the toggle to the left, and the user here is switching their knowledge of the interface between what they see and what they do. So, you see the toggle button, you interact with it to confirm, you see the activation, and then you physically interact with it again to turn it back off. The confirmation and rejection require physical activation by the user. There's no real hover state here because we have a finger instead of a cursor for this kind of switch normally. So, our hover state is converted into one that requires physical activity. It requires us to actually move the toggle from the left to the right. A hover state where the cursor was still is now replaced with emotion state where our finger is active. This is much more common in UI design for mobile devices, and a lot of ways, the motion state has replaced a lot of these conventional state changes. We're much more use to swiping nowadays than we are to clicking. So, if the click this has been replaced by the swipe, it follows logically that the mouse has been replaced by the finger, and I think this gives the user more of a connection to the interface because there's no mouse to mediate that experience. You're actually using your finger right on the screen and that creates the necessity for this motion state, and that in turn means that you have to have a much more fluid relationship between those states. You have to start to think about how your interface elements are going to animate.
