Hover connecting artboards
If would be great if the hover doesn't only present in states, rather in the artboards too
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.
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.
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.
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.
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.