Rethink the component system
In a design system we need hierarchy and inheritance. At this point XD handles these a really poor way.
Important principles:
Embedded / nested components
If I embed a component and change it, the change should be the new default, so when I make new instances of the master, the subcomponent should NOT be reset.
States
If I create a new state, and change the elements / subcomponents, only the property changes I made should be saved in the new state. ALL OTHERS should be exactly as in the master. This should work in the property level, so if the master state has a regular font style, and on the new state the font is bold, all the other things - text content, font family, size, position, etc. should still come from the master - so these should CHANGE once the master is altered.
Component resize
Now the component’s boundaries are defined by the contained elements. This is a really bad idea. Components need some kind of frame, artboard in order to make them easier to use in responsive / interactive scenarios.
- There are static components like logos, icons. Now we have to cheat and create a standard 24x24px invisible background element to make them exchangeable.
- There are elements, which have several states with different sizes. The artboard for the states should be able to follow the size changes automatically plus there should be manual control too.
- The artboards should be able to be stacked and push / pull others when needed (like an accordion). For stacking the uniform margin is not acceptable, as in the reality the margins are changing between elements.
We’ve added support for nested components and have improved states and resizing. Feel free to file a new ticket if you’re interested in additional features.
Please note for future reference that UserVoice works best if you have each idea in a separate ticket.
-
Andras commented
Another thing about states:
Once real inheritance is established between master state and its child states another problem will occur: we'll need more master states and their own child states.
The actual model is basically only a container - like a bag: you throw things into it and they behave quite independently. Once the states will really be dependent upon the master we'll find that this is a limiting thing, and we need to copy the whole component in order to make variants. But this would make no sense. We're duplicating again and flooding the file with more or less identical components. This is why we need more LEVELS of hierarchy of states so the master still can 'rule the world' and variants can inherit their own unique features down to child states as well. -
Andras commented
- Another resize bug is the one I call 'last element comes up' in groups... If we create a simple list from a group of fixed height list-line elements and try to reduce the vertical size, the last element "comes up" as we decrease the size. This should not be so. It makes list creation a tough task. The last element should stay at the original position as it's constraints were set to top left right. See attached images:
-
Andras commented
An addition to the 'Component resize' section:
- When we have a component where all the states have the same size, ALL of the states should be resized automatically if we resize any of them. This would be a natural behaviour. Let's say we have a card with 4 states. If we create a new variant and play with different sizes we do not like to adjust the size when we switch to a different state. This would make sense for animation too... How many times did I have to readjust button sizes when realised that in 'hover' state the buttons are separated from the other states so the size and the text should be updated...