Pliant response for websites
Summary: Users need feedback from websites. Buttons, links, and other interactive elements should respond to elementary user input.
All web designers probably try to account for user feedback, especially in controls like buttons and links, but a lot of websites have strange ways of letting the user know what he can or can't do. There are some de facto standards from the software visual interface world that apply to web design, as well as a few guidelines that make pliant response more effective.
What is pliant response?
Pliant response is feedback that indicates the manipulability or effect of a control. For instance, many physical devices have buttons that, when pressed, cause a small light in the vicinity of the button to illuminate, indicating that something is "on" or "active". In the world of websites, pliant response is typically found in visual form only, especially as what are known as "rollovers". A lot of websites have menus made of buttons whose appearances change when the user moves the cursor over the button area. I'm going to focus on that, and closely related pliant response mechanisms.
Bad pliant response
No pliant response is generally bad. If buttons on a website don't light up, or otherwise change in appearance, then there is often very little to distinguish them from other graphic elements. A lot of websites have graphic text that looks the same as their "menus", which can be confusing, particularly if some of the text is clickable, and some of it isn't.
Another form of pliant response that is particularly bad for users is the "false" pop-up menu. In such an instance, the user rolls the cursor over a button, and elsewhere on the page, a pseudo-menu appears (or something that looks similar to the other clickable elements on the page). However, that pseudo-menu isn't actually clickable, and when the user moves the mouse to click on one of the pseudo-menu choices, it disappears.
One common confusing mechanism involves rollovers that result in a description either appearing elsewhere on the page, or replacing the original button image. Replacing the original image with a significantly different one, like a description of what the button represents, can be useless because the cursor will obscure some of the description. If the user moves the cursor away from the button, it will return to its original state (assuming the author coded the rollover correctly), and the description will vanish. Also, many users follow long strings of text with their cursor, similar to the way many people follow books with their fingers. If the user wants to read a description that has just appeared some distance away from a button, he may move the mouse to follow the text, causing the description to disappear and the button to return to its normal state.
My final example of bad pliant response are rollovers that invert or otherwise drastically change the original image. One of the subtle cues of visual interface design that made the original Macintosh interface so usable was its consistent implementation of buttons inverting upon mouseclicks. When users click on a button in the Macintosh interface, the button inverts and appears to be pressed. The effect only lasts a fraction of a second, but it sends a subtle message to the user: "ah, yes, the button was pressed". Many websites have buttons that invert or appear to be depressed when the user simply rolls the mouse over the button. That isn't so good: the user didn't click (press down) on the image, so it shouldn't appear to be pressed down, or clicked. Windows, and other operting systems also use the same system of color inversion and simulated depression to indicate that buttons have been clicked. Users already expect that kind of response, and most websites and browsers can easily support it.
Good pliant response
Here are guidelines for pliant response on the web:
- indicate what's clickable by designing with distinguishable styles (i.e. buttons that look different than headlines, logos, or other graphic text)
- implement a subtle visual cue for mouse rollovers
- implement a drastic visual cue for mouse clicks
- keep feedback simple: don't try to supplement menu choices with lengthy descriptions
That last point is particularly important: if a button isn't reasonably self-explanatory, redesign it.
My preferred method of following my guidelines begins with a distinct button design that is clearly labelled. The text in that button is slightly dimmed, to around 75-85% opacity against whatever background the button has. Second, a mouseover state of the button is created that is nearly identical to the normal state, except with a background lighter by about 25-40%, and the text is brought up to 100% opacity. Third, a mouseclick state is created that is either a color inversion of the entire mouseover state, or has an extremely dim background and extremely dim text (maybe 10% brightness and opacity, respectively). A fourth, "active" button state should be created, with a "you are here" indicator of some kind. That fourth state allows the menu to remain a constant shape and in the same position from page to page, and separates the active page's button from the other clickable buttons.
If a description of some kind seems necessary, use link titles instead of a complex rollover that displays a graphic description. Link titles will more naturally blend in to the interface of both the browser, and the operating system, if the designers of the browser have done their job correctly.
Some websites have been using on-mouseover underlining of links as a form of pliant response. That's no good: links should always be underlined, and if possible, be a different color than body text. I suggest on-mouseover pliant response similar to what I have suggested for graphic buttons. Link text can lighten when the user moves the mouse over the link, and an active link color that is drastically different than the normal link color will suffice as the on-mouseclick feedback.
It's the little things that make websites easy to control
Effective visual feedback when users want to manipulate a page element is not stricly necessary, but it prevents users from becoming frustrated, and it clarifies use of the website. Eventually, pliant response on websites will include subtle audio clues, and perhaps tactile feedback through hardware (both of which would make manipulability even more clear). In the meantime, however, these little pliant response tips will make users more comfortable with any website.
Adam Baker is a user experience designer who's worked at Google, Apple, BlackBerry, and Marketcircle, and mentored startups in Vancouver.