Stacks should dynamically shift content in Preview
Create component - + New state (bigger than the default) - Merge the component with another one or another element into a stack -
Preview mode - click the component to change state and the stack doesn't respect padding .
-
Screenshot 2022-01-14 at 12.55.47.png 233 KB -
Stacked components.mp4 641 KB -
interactive-layout.gif 325 KB -
design-mode.gif 657 KB -
prototype-mode.gif 250 KB -
Expanded-Prototype.png 30 KB -
Expanded-Design.png 98 KB -
Adobe XD State Change Padding Feature Request— August 25, 12.21.06 PM.xd 104 KB -
XD Issue.mp4 3480 KB -
2020-06-18 01-27-01.mp4 2266 KB -
Link components.png 58 KB -
Components.png 18 KB -
Components stick.png 30 KB
Please note that stacks is a feature that is intended to be used at design time, and does not dynamically shift the stack in preview. I’m going to rewrite this particular request to be more precisely about the latter suggestion.
-
Anonymous commented
That would be perfect when using expanding components!
-
Ruxi commented
Stacks don't work on this... They work in the file artboard, but not in the preview or on the share link.
Please consider making stacks work for accordion menus because it's too time consuming to use auto-animate if you have a lot of sections in the accordion (also the point is for it to work on one single artboard). -
Stefan Dickerson commented
Yes please! Trees, accordions, progressive disclosure forms, and the like would all come to life without us having to draw up (and wire together) every permutation of open and closed things!
-
Filipe commented
I wish it could work with the stacks. It works when you are editing the file, but when you publish the prototype it doesn't.
-
Anonymous commented
I have the same problem, since the beginning of our project I have some expanding components and it is very important to move the content when the component expands - in design mode it is just perfect, but in preview mode, it isn't.
-
Cyrill Studer commented
Yes, I would like the stack to update when a component inside it auto-animates to a larger or smaller state!
-
Anonymous commented
Absolutely crucial! please add this ASAP. It would help with my workflow immensely and save a ton of time.
-
Torbjörn Hedberg commented
+1 here as well. Works perfectly in the Design mode so it's a shame it doesn't in Prototype mode.
-
Brandon Beiler commented
Constantly run into scenarios where this would be insanely helpful. +1
-
Gabriel Häggebrink commented
+1 Here! Missing this virtually every project I do, would be an amazing addition.
-
Kevin commented
When I launch a preview of a page including a component whose shape changes (addition of an element in the component) it overflows despite the use of the stack function.
-
Phil Bowell commented
In the same way that stacks resizes it would be great if screens could resize their height dynamically. This would allow for auto-animating between different component states and the elements around them to move but retain the spacing.
An example would be in a form that works with progressive disclosure based on selecting different answers. Rather than animating between two screens, it could be between two states of a component and the screens responds dynamically.
-
Mike commented
When you have a lot of vertical content, duplicating artboards to create a dropdown menu requires a lot of effort, especially when each message has an accordion style dropdown menu. It would be nice to have the benefits of Stacks for this behavior.
-
Rigel Closet commented
Auto animate? the point of components is to make everything happen in one art board! please implement this feature, i though stacks will take care of it, until i tried !
-
Antal commented
Expanded/collapsed states are useless as long as preview mode does not adapt to them. A real shame and lost some hours due this particular design...
-
Jovana commented
Since the stack dynamically expands (changes) in design mode, I have spent some time understanding that this does not happen in Preview.
I can understand why people might think this is annoying to have by default, but it could be an additional option when setting up a stack..Anyways, it would really be incredibly useful to have this behaviour in the preview too.
-
Almasi commented
I'd like this feature also, it feels like a natural fit for Stacks. What happens now is the opened state overlays the content beneath the closed state.
Elaine, this will not currently work (with auto-animate or otherwise) unless we put all the page's content into one giant component and manually position the content for each state. This precludes making a non-scripted flow.
FWIW, I hope I'm wrong, but I can't get this to work. Yes, I have the most recent version.
-
Florian Pürschel commented
It is so sad that this feature is missing. I have a list with a lot of expanding elements. When changing the state to "expanded" everything adjusts just fine in design mode. Unfortunately it does not adjust in preview which forces me to add 2342346456 additional artboards to present every possible combination of expanded elements. This is really really annoying
-
Luke commented
I could really use this feature in prototype now. I have a sidebar with a ton of filters where I have expanded/collapsed states. Right now the expanded state in prototype just goes over the other elements.
-
Payton commented
The Problem: I have two components A & B. In A's default state component B is y px beneath A. Component A size expands or contracts by z px and changes to a new state. Currently, component B is now y + z px from the bottom of component A.
The Solution: Components that can change shape between states should "push or pull" other components by fixed padding defined assumed by the system or defined by the designer. This behavior should be able to be chained between multiple components & other objects.
Applications: Expandable lists, expandable cards, & my quality of life improves.
Savings: No need to create an endless number of artboards to express simple behavior between components or super long write-ups to hand off to a developer.
Current Time Cost: Per component, n, that has a number of states, y, on the artboard a designer has to create (n*y)! number of artboards to describe the screen behavior. This is a massive pain in the butt! It costs countless hours of write-ups and reconciliation with developers.