Multi-State Dynamic Graphic Buttons

I had a client request recently to toggle an image button to a second image on mouse over. Under normal circumstances, this would not be difficult to accomplish since you can assign one image to the Normal state, and a different image to the Hover state, like so.

However, if you go this route, you can’t use container fields as the source for the images, but instead must make static file selections, like so:

Since this button would be appearing on dozens of layouts throughout a 20+ file solution, the client wanted to be able to store the two images in container fields, so an authorized user could easily swap in new container images (in browse mode, not layout mode) and have the changes ripple through their entire solution.

Demo Files:

• dynamic graphic button, v1
• dynamic graphic button, v2
• dynamic graphic button, v3

Incidentally, you can easily test the “dynamic” part by inserting your own images into the Normal and Hover container fields…

Also, if you’re familiar with the “use a dummy tool tip to invoke a plug-in to fire off a script” trick, it was not seriously considered due to latency. When users hover on/off the button the image needs to toggle immediately, which brings us to demo #1:

Dynamic Graphic Button, v1

Given these two images in container fields…

The button should display the “Normal” image when at rest…

…and the “Hover” image on mouse over with no delay:

We’ll get to how it works in just a second, but for the moment, notice that “Dynamic” consists of the “Normal” field precisely overlaid on top of the “Hover” field — like so (except here the fields are partially de-overlaid to make clear what’s going on):

What didn’t work: At first I attempted to use a transparent fill for the hover on the upper image, but that’s just the fill and does not hide the upper graphic. I also played with “hide object when” but couldn’t figure out a zero-latency method to toggle it via mouse on and mouse off.

What worked: With two overlaid containers, I defined the upper (i.e., the “Normal”) container as a button and configured the hover state like so. Note: you don’t see img_normal in the screen shot, because the padding settings for the hover state have rendered it invisible, but img_normal is the selected field:

So now, in browse mode, when the user hovers over the button, img_normal disappears and img_hover becomes visible. And as soon as the mouse is moved off the button, things revert to normal.

What about the pressed state? It’s good enough for the client’s needs; they see a shaded version of the “normal” image and they’re happy.

But that’s not quite right is it? Wouldn’t it be more logical to see a pressed version of the “hover” image?

Dynamic Graphic Button, v2

Apparently Jonathan Mickelson at Thought Development felt the same way, because I sent him demo #1, and he sent me back an improved version along with the following remarks:

Great technique, using padding to push the image out of the way on a state change — notice I didn’t just say hover. To achieve your desired pressed state, use the same technique on the Pressed state. This keeps the original image from popping back in. Then add an inner shadow of your color preference, with transparency to “color” the pressed state of the underlying image they “pressed”, a-la… these settings:

You can do this on the other states as well, including tinting the hover image a little too, as you can see in the modified demo file I’ve attached.

So, in demo #2, Jonathan is using identical Inner Shadow settings for both the hover and pressed states, except that hover gets 10% opacity, whereas pressed gets 20%.

And sure enough, when the button is pressed…

…we see a more deeply tinted version of the hover image. Thank you and nice work, Jonathan!

Dynamic Graphic Button, v3

Interestingly, the v2 technique has zero latency in FM 14, but has about 1.5 seconds of latency in FM 13, and it turns out that the inner shadow “blur” is the culprit. Our final demo today shows a couple approaches one might use to achieve a zero-latency dynamic image button pressed state in FM 13.

a ) we could dispense with the inner shadow, and configure the pressed state like so:

Or, b ) if we’re okay with the maximum button size being 100×100, we can achieve the shaded effect without the latency-inducing-in-fm-13 blur, like so:

Again, thank you Jonathan Mickelson for pointing this out. It seems appropriate that Jonathan should have the final word about this technique:

Without blur, the max transparent overlay that can be achieved is 100pt x 100pt, due to the 0-100 range on offset.