This would be the most helpful feature for game design and wireframing aswell.

It would be really helpful to have the option of linking a Hover state to an overlay artboard.
So you could have a tooltip or further information popping up on hovering.

For the record, as with nearly every feature I have requested or voted on in this forum, you can already do this in Figma.
They have a much more robust array of events including MouseEnter and MouseLeave.

For the record, as with nearly every feature I have requested or voted on in this forum, you can already do this in Figma.
In fact, Figma has a much more robust array of events including MouseEnter, MouseLeave, etc.

It would be nice to have "hover" as an option for triggers in the prototype mode. That way we might be able to transition to a different artboard just by hovering on a element. This can be useful to create some animation inside an element.

@Adobe
Please merge this with the other request (mentioned in my comment below https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/38972416-hover-triggers-to-all-elements-to-trigger-artboard).

That story already has 64 votes. I'd hate for this to wait another year or 2 building up support when it's the request I intended to make almost 2 years ago when I first posted/commented on Hover triggers.

It is clear see now that the mistake we made in the original request was using the word "Hover" rather than "MouseOver".

Because of this, I have created a different request with a more accurate name:
https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/42009670-add-mouseover-and-mouseout-to-list-of-triggers-for

Note to Adobe:
If you choose to merge this request with the one referenced above, please retain the newer name that describes this a MouseOver Mouseout rather than hover.
I'm actually the author of both of these requests (not sure how I managed to log in with 2 names...probably due to a work account being added).

Hopefully, between the 2 of these, we can get enough attention to the problem. My fear is that by keep this request alive with a name that references the "Hover" event, it will not receive the attention it deserves because of the impression that "Hover" events have been dealt with through the introduction of States.

This is actually a duplicate of an existing request with a less appropriate name: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/38972416-hover-triggers-to-all-elements-to-trigger-artboard

As of this writing, significant number of use cases for hover events still require navigation to another artboard.
There will be an inevitable temptation on the part of Adobe to interpret this request as already handled by the States feature which when live in XD 24 (https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12941394-tap-hover-effect).
States are excellent for small changes like hover states on buttons (it would constitute a great waste of overhead to generate a duplicate artboard for every hover event on every button). So, kudos for the States feature.

However, more complex transitions still require navigating to another artboard.

Example: 3D Transformations (introduced in XD 34).

Of course, when we say "Hover", we really mean "OnMouseOver". It is clear see now that the mistake we made in the original request was using the word "Hover" rather than "MouseOver". One can only imagine that the reason XD does not include "Hover" in the list of Triggers for Destination Transformations is because a hover event would be terminated the moment the calling artboard is exited or when the destination artboard is displayed. This would cause a looping between artboards; no fun!
However, if the “OnMouseOver” event were a trigger that could navigate to another artboard, then a corresponding “OnMouseOut” event could be used to trigger a return to the first artboard.

Win/Win!

Another example of complex transitions that are not adequately handled with States:

Another nice addition in XD 34 if the ability to have nested States. In other words, the ability for a component to enact a hover state while it is already rendering a hover State. This was achieved by officially supporting nested components.
https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/38968075-hover-inside-hover-nested-hovers

While this provides the literal behavior of hover within hover, it fails to produce a user experience that is comparable to what would occur on a web page.

Example [see attached image]:
- We create an icon that, when hovered, produces an overlay or dropdown.
- Now we can hover over the new overlay and trigger a secondary hover event.
- So far, so good.
- However, the dropdown causes the parent component to render a larger rectangle which defines a scope that is equivalent to a <div> that encompasses the entire component. This larger rectangle includes a good bit of area not visibly covered by the original icon or the resulting overlay.
- In a real-world implementatin (on a web page), the hover event would be terminated if the mouse cursor moves away from the original icon in any way other than to move over the newly generated overlay.
- In XD, the cursor can now move over a non-existent [attached image] area above and to the right of the overlay without cancelling the hover event because that invisible area is considered part of the component.

Note: I have had similar issues attempting to simulate an overlay dialog (documented in this request: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/41912431-honor-layers-z-order-in-prototype-interaction )
The desired behavior would be to click anywhere outside the dialog to make it disappear. XD doesn’t appear to provide this ability. If a Tap Trigger is assigned to the larger layer beneath the overlay, the overlay layer fails to hide the proper portion of the background layer. The result is that by adding a Tap Trigger to the background, it is effective active across the entire overly; causing any Tap Triggers on the overlay layer itself to be swallowed up by the background Trigger.

@Adobe
I would like to rename this request to something that would better articulate the desire but I don't seem to have Edit ability this late after original post.

A better name would be "Add OnMouseOver and OnMouseOut to list of Triggers for Destination Transformations".

When I said "Hover", I really meant "OnMouseOver".

One can only imagine that the reason XD does not include "Hover" in the list of Triggers of destination transformations is because a hover event would be terminated the moment the new artboard is displayed. This would cause a looping between artboards; no fun!

However, if the “OnMouseOver” event were a trigger that could navigate to another artboard, then a matching “OnMouseOut” event could be used to trigger a return to the first artboard.

If would be great if the hover doesn't only present in states, rather in the artboards too

Yes, I'd really need the feature to be able to preview rich-tooltips and sub-nested menus, and it would play beautifully with the Auto animate feature! (I work for videogames, that sort of thing is commonplace.)

There are a lot of reasons to do this. Marvel and others support this, and it would open up possibilities like 1) depicting common hover interactions with graphs and other visualizations, 2) soft-enforcing mandatory fields in forms,and (I guess my least favourite) 3) simulating that browser trick where you're trying to leave a site with a "before you go" message.

Where the (usually awesome) component hover state functionality doesn't work is when the hover targets are irregular shapes and/or don't cover the space where we want something to appear on hover. Today, I'm trying to depict a tooltip in the footer reminding you that you might want to save your work, triggered by hovering a large L-shaped navigation region in the screen.

I use Adobe XD to design interactions for games. This feature would be very welcome for my purposes.

@sherif assaf

Is it possible to do this what you have shown, with hover-hover, not tap-hover?

@Sherif Assaf

I've been evaluating your example some more and I think it misses the point (mostly, I didn't make my point very clear).

As best I can tell, the "Amazon Accounts" example uses a tap trigger to show the overlay and then the mouse over for the item highlights.

Although this can be achieved by states, it still requires a tap trigger. To do what I'm trying to accomplish, you would need cascading hover events. As shown in my menu example, I had set hover triggers inside hover states so that mouse over would bring out the pop-up which, in turn, contains components with hover states.
The problem is that the components that are visible as a hover state (triggered by an earlier hover) will not fire a second hover state. One of the 2 must be triggered by a tap.

I'm attaching the XD file that should provide what I need, but does not because the highlighted hover state of the menu item components will not fire the over trigger when they are only visible as a state triggered by an earlier hover.

Another flaw in this method is that even if it worked properly, having hover states that include pop-outs makes it very difficult to move from one icon to the next. The mouse must completely exit the region of the pop-up before it can trigger the icon next to it. If you run the example I've attached, you'll see that you can't go from one menu icon to the next and have them behave as expected. You will always have to move the cursor out of the range of one pop-up to engage a new one.

Also, I'm beginning to understand why Adobe doesn't provide a hover trigger that navigates to another artboard. Presumably, if this were done, it would require a backward navigation when the mouse exits the hover zone. While this is certainly an added level of difficulty, it still seems manageable (and preferable).

@Sherif Assaf

That's pretty impressive.

Could you attach an XD file to explain how this is achieved?
I spent half a day on this and could never get the hover event to fire on the pop-up overlays.

What was missing from the [not Amazon] example I posted is the need to have the pop-out menus respond to hover as well. I didn't show it because I couldn't achieve it.

Also, the way I was going about it would be far to cumbersome to be of value.

Depending on how you managed your example, I would still argue that simply adding Hover to the list of triggers for any element would solve the majority of situations better and easier.

In the Blog posted for this latest release (https://theblog.adobe.com/xd-november-2019-update-coediting-more/), under the heading "Hover Trigger" I found the following:

"You can also choose to manually apply the hover trigger to any element in prototype mode using the trigger dropdown in the Property Inspector. "

This may have meant to say "any component" but it says "any element". If this were true, it would be exactly what I'm requesting; the ability to add the Hover trigger to any element and do something other than just change the hover state of a component.

this is very need . and very good feature. please vote.

Hi Scott and Stephan,

Thanks for your feedback.

You could achieve the desired behaviors that you listed with component states in XD. I have recreated both examples in the attached file. We're working on improving our nested hover interactions.

Please let me know if you have any questions.

-Sherif

"Obviously, XD is able to trap the hover event. We just need it to be wired to the transition interactions."

Agreed, that's the only thing we actually need for this to work. I'm disappointed in how hover works, still can't really design a proper dropdown menu right now.

I've attached a couple animated GIFs to illustrate the need.

The first (AmazonHover), shows typical behavior for a registered user on Amazon.com when moving the mouse cursor over "Accounts and Lists".

Notice that the hover displays a large overlay and covers the remainder of the screen with a semi-opaque gray scrim to indicate modal behavior. In addition, once the overlay is visible, the individual links on the overlay also respond to the hover event; changing the color of the links.

This is the kind of behavior we need to simulate in an XD Prototype.
The second GIF show what I've managed to simulate so far using Hover and Component States.
The pop-up overlay is an additional element visible only in the Hover state of the base component.
I had to make the internal elements of the pop-up nested components so that they would also be able to interact as Hover state elements.

Unfortunately, the nested components will not fire the hover event (presumably because they are governed by an existing hover state interaction).
If I were to create a second artboard in which the Hover state of one of the base elements (menu icon) were already set to Hover, then the internal nested components would behave as desired.

Also, because the pop-up is embedded in the menu icon component, I can't fire the Hover of any other menu icon until the mouse has completely cleared the area taken up by the pop-up overlay.

None of this would be an issue if I could use multiple artboards and simple assign the Hover event of the menu icon component call a second artboard with that icon preset to its Hover state. Or, better yet, have the overlay only exist in the second artboard so as to not clutter or overcomplicate the menu icon component.