Hotspots and Feedback
Put yourself inside the mind of a visitor to your interactive piece:

They look at your interface. They are curious. They see something they predict is a gizmo to interact with. They test their prediction it by rolling over this thing with the mouse. Doing that makes some little thing happen. Maybe they were right! Now they are even more curious. They decide to take the leap: they click on the hotspot. Hah! Something big happens. They are rewarded. They like your work! (Or something like that.) This all happens in an instant, and the visitor isn’t even thinking these things. But as the interface designer, you should be.

Here are a few design tips to help this process work. Check your design against these guidelines...

The most important elements in an interface are the hotspots. Visitors approach them in three steps, which your design should respect:

First: “PREDICT”

Hotspots should provide passive clues to their existence.
By “passive”, we mean that the user need only to look at the interface and be able to predict where hotspots might be, by their appearance.

Hotspots should present at least one clue to their existence. Fundamentally, a hotspot’s visual appearance should differentiate it from other non-interactive graphics. Common visual design techniques include the use of shadows, outlines, distinctive colors, or specific design styles. Animation of position, color, or density will draw even more attention to hotspots. It is misleading to design elements which look like traditional hotspots, but are not.

Sometimes, in certain game or artistic interfaces meant to be deliberately mysterious, such techniques need to be very subtle, or not used at all. In those cases, a user will need to work harder to find the interactive elements. But, in a project designed to be used to acquire information, being obscure is not a good idea.

Second: “TEST”

Simple user activity should trigger feedback to confirm the discovery of a hotspot.
While the user “explores” the interface by rolling the mouse around, encountering a hotspot should trigger feedback, ideally of more than one type:

• The hotspot immediately highlights or changes state when user rolls over it.
• The cursor changes.
• Optionally, something else could also happen, such as a quick sound effect.

Customarily the cursor on such a rollover is some sort of "finger", but other shapes are possible if your design remains consistent.

The finger cursor implies “clickable”. Users will expect an open hand to signify that the object the cursor is over can be grabbed and dragged. While the object is being dragged, changing the hand to a clenched fist shape is good feedback.

Take a clue from other authoring programs, which use the cursor extensively to signal what tool the cursor currently represents.

Third: “REWARD”

When the user actually clicks on a hotspot they have discovered and tested, something happens.
A legal “click” works specifically like this:

The trigger for the event occurs when the user mouses-up over the hotspot, but...

• No trigger occurs if user mouses-down on the hotspot
  but mouses-up outside the hotspot, and...
• No trigger occurs if user mouses-down outside the hotspot
  and then drags into the hotspot and mouses-up.

That may sound complicated, but that is the standard “button” model used in almost all Mac and Windows application interfaces. Most users will expect most buttons to behave that way.

The thing that “happens” needs to occur right away. Studies have shown that users get impatient in a matter of seconds. Reward can quickly turn to disappointment.

Some kinds of hotspots feel better when the trigger occurs on the mouse-down, rather than the mouse-up. A toggle switch is one example (click once to turn on, click again to turn off).

Other important interface feedback issues:

1. Every hotspot should provide the same feedback style everywhere in the piece, unless there is a significant reason not to. Users are easily confused, so don’t change the rules on them partway through the experience.
2. The cursor should never disappear. Users are very accustomed to seeing the cursor as an extension of their mouse, and thus their hand. If the cursor disappears, they might also think their computer has malfunctioned. Interfaces which use no cursor at all (such as touchscreens, or where some other input device is provided, or where sensors are controlling the experience) are obviously exempt from this. If you don’t want to see the standard system arrow, try designing your own default “inactive” cursor shape.
3. Fast-moving hotspots? They’re fine for games, or menu designs in which the designer wants to assert supremacy over the pitiful user. Otherwise, don’t do it.
4. Significant navigational hotspots, such as a way back, HOME, or QUIT, should be easy to find, and usually are best located in the same place on every screen where relevant. Especially, don’t bury the option to go back or quit too deeply. Unless you are strapping your user into their seat and taping their eyelids open, they can leave your project whenever they want. Help them out by making your navigation easy for them.
5. Beware of hotspot clusters ("menus") where the function of the hotspots changes from screen to screen. Normally users will honor position over shape in such cases. Don't shift the location of a particular button to new positions on different screens. If a hotspot on a given screen would be meaningless, provide an inactive placeholder.
6. Always provide a way to click to skip introductory sequences. Making the entire screen a hotspot works well, rather than forcing the user to click on some small button in a corner.
7. Don’t make frequently-used hotspots too small. One pet peeve is in “slide shows”, where the forward and back buttons are tiny, and require extra effort to find on each screen. If you don’t want hideously large graphic hotspots, you can always just make the sensitive area of such a button really large, and indicate the rollover with a special cursor.
8. Provide keystroke duplicates for commonly-used interface features. Power-users will appreciate the efficiency of using keys instead of the mouse. Also U.S. Government Accessibility Standards require that certain interfaces be completely usable with only the keyboard.
9. Do not allow a click on a significant action to happen without asking “Are you sure?”. The QUIT button (in standalone, non-web, works) should link to an intervening screen, possibly with credits and copyright info. The intervening screen or popup window should provide a "return" button as well as another, real, quit button. On the other extreme, don’t constantly ask “are you sure” every time the user makes a choice, unless the action cannot be undone or would take a lot of extra work to change.

Again, your particular aesthetic may dictate against employing traditional user interface functionality. Just keep in mind, if your user-visitor-player gets at all confused or frustrated by your work, they can always walk away.

Copyright © 2007 Peter S. Mackey All Rights Reserved