Hover triggers to ALL elements to trigger artboard navigations; not just state changes
Now that the "Tap/Hover Effect" request ()https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12941394-tap-hover-effect?tracking_code=c41a5301558789f85205f7c47ec8b9ca) is officially closed, we need a feature to do what (I believe) the 8952 people who voted for it have been asking for since March of 2016:
A way to assign Hover events as triggers for the existing interactions platform.
Component states is a wonderful addition to XD, but it barely scratches the surface of what designers need for prototyping hover events.
We need to be able to add tooltips, menu pop-up overlays and many other effects that still can only be achieved by transitioning to another artboard. As it stands, to prototype a menu overlay that will ultimately occur as a hover event, we must use the "Tap" trigger and tell the design reviewer "this will be activated by a mouse-over event, we just can't simuate that with our current tool."
Obviously, XD is able to trap the hover event. We just need it to be wired to the transition interactions.
Scott Ehly
shared this idea
8 comments
-
Wojciech Obuchowicz commented
@sherif assaf
Is it possible to do this what you have shown, with hover-hover, not tap-hover?
-
Scott Ehly
commented
@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).
-
Scott Ehly
commented
@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.
-
hossein
commented
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
-
Stephan Lenting
commented
"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.
-
Scott Ehly
commented
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.
-
Scott Ehly
commented
Having given this some more research and testing, the new Hover/States feature can do more than first observed (see download kit found here: https://letsxd.com/states?scid=66539730-3746-42e4-9d83-7bca9bbba35a&mv=social&mv2=owned_social).
Take special note of the volume control. This example shows how you can do some pretty complicated prototyping without navigating to a new artboard and back.That said, sometimes it much easier to simply use several artboards. These examples (linked above) are impressive, but part of the desire to prototype is to quickly get to a visual demo without having to code. These complex combinations of state are, indeed, complex and could often be more easily done with a series of duplicated artboards.
One example of something that could not be easily done with states is a menu structure that opens sub menus on hover. This is more than just changing the state of an image, it's moving things around. The only way to do this with states is to create a component of components of components. [updated: components inside components does not work!]
Sure, maybe it can be done, but it's frankly not worth the effort.Plus, it would be more cumbersome to export a series of screen images. Sometimes, multiple artboards is better.
So, all this request is asking for is to take that hover trigger and connect it to destination boards. This would allow the designer to choose how complex he/she wants to make the project.
Also...
In order to Share for Developers, you still need to have multiple artboards showing the various state combinations in order for the developers to capture all the style data for each.
