I'd like to see an option in Prototype mode where i can choose to animate text a little easier. There will be new options where you can choose which text animation you want and also which interval time that should be used

The text animations i'd like to see in that dropdown menu are:

• As whole (default)
  This is how it is now.




• Per paragraph
  Animate the text by paragraph.




• Per line
  Animate the text by line.




• Per word
  Animate the text by word.




• Per letter
  Animate the text by letter.

For each option could be considered to have an option for ignoring whitespaces.

Having such option gives tons of new possibilities to animate your content. Like the highly requested text input simulation. With the option to animate by letter you can create that typing animation easily. Or fade in text by line to have a smooth transition for your text blocks.

I believe this is something that Adobe XD needs to have as it gives you more control over prototyping text effects.

TL;DR: Art boards with transparent fills should continue to overlay the previous art board's underlaying board.

I can think of many use cases that have required a significantly higher number of art boards, assets and hours to accomplish than should be required. The feature I am requesting would address all of these issues in a simple and intuitive way.

Let's say I have art boards A, B, and C.

'A' displays my application, with 100s of assets, text, components, etc.
'B' displays a modal over the application in state 1, the default state.
'C' displays state 2 of the modal, which has been dynamically expanded to show a number of additional fields as the user fills out the modal.

Behind the modal (out of focus), there are 100s of elements that are on screen but remain exactly the same for all three boards since the modal is the only interactive element.

I am able to use an overlay transition between A and B no problem. So I design 'A' using a transparent art board to avoid having to duplicate the hundreds of items that remain constant between A and B.

Now here is the issue. I want to use an auto-animation between B and C to show additional fields in the modal. But I can't! Because doing so would make the underlying art board (A) that B is overlaying disappear. After the animation C will be displayed over a black background.

The workaround I use is to avoid the overlay transition entirely, and include a carbon copy of the contents of art board A in both B and C. This not only significantly increases the number of elements in the file but also makes any changes to art board A significantly more time consuming.

But wait! It gets worse. Let's say the modal isn't only accessible via screen A. Let's say there are screens A, D and E where the modal can be opened. Well now in order to have two different states of the modal, you need to recreate both B and C over top of A D and E. And just that quickly we are up to 6 art boards just for a modal that transitions between two states.

Here is what I am proposing:
Option 1 (Fewer art boards, fewer assets): Once an overlay transition is used, the underlying art board should persist as the 'background' for subsequent transitions until a transition is made to a non-transparent art board.

Option 2 (Same number of art boards but at least fewer assets): Allow an art board to be re-used as a 'background' element, so that the contents don't need to be repeated in other art boards.

Right now, the creation of a carousel or 'choose one item' list requires you to have a different COPY of your artboard for each possible iteration of that carousel/list. If you want to showcase 3 multi-artboard interactions in a mockup (if each carousel has 5 images, you need to copy your artboar 125 times, just to show that, without any other bells and whistles).
In contrast, if you could have an artboard group that is JUST the possible states for 1 carousel, then group those artboards into a single component. Then you only need 1 main artboard (for your app/webpage) and 15 mini-boards (3 components, each with five possible states).
This single feature can VASTLY broaden the utility of Adobe XD. Most of the buttons and such required for this are already there, so it wouldn't complicate the UI much. Even the simple option to swap a component with another component from your pasteboard on Tap or Dra, etc, would be a massive relief.

Please remove, or add option to remove, the animation from Hover state back to default when a Tap trigger is attached to a component that is in Hover state.

This animation is unnecessary when navigating to another artboard and can cause all manner of irritation if the artboard to which one is navigating shows the component intentionally in hover state.

Example:
- An image control has a hover state
- When in that hover state, the user can click to cause an action.
- The action is simulated by a navigation to another artboard
- In the destination artboard, we would show that image control in its hover state as an indicator that it is currently active.

As XD is currently implemented, clicking on that control will cause it to animate from hover state to default state (as it leave one artboard) and back to the hover state as designed in the destination artboard.
It is currently impossible to animate a smooth transition between artboards leaving the component in hover state.

We need to be able to set prototype interactions based on visible content.
Currently, if a larger object [a] is covered (via z-order) by a smaller object [b], a prototype interaction assigned to [a] will be active when the cursor hovers over [b]. This is not the typical expected behavior with regard to click or mouse over events.

Example:
In the attached image, there is a modal dialog [b].
We would want to assign Tap interactions objects within the dialog.
We would also want to assign a Tap event to the area outside the dialog. In this case, tapping outside the dialog should close the dialog.

However, because the Tap interaction assignment on the region beneath the dialog [a] will fire regardless of the fact that the dialog [b] is an object group placed above the background region [a] in z-order, the desired effect cannot be achieved.

We've even attempted to create an exclusion mask on the region [a] beneath the dialog [b] so that the area covered by the dialog would not be considered viable. This did not work either. The entire exclusion group is considered active for the Tap event.

If, however, the layers (z-order) of objects was taken into consideration, then only the visible portions of the region beneath the dialog would be eligible to activate the associated Tap interaction.