Allow interaction wires/links from objects inside a symbol
I was so excited about the new symbols feature that I made all of my navbars in a design a symbol. This may be one of the most obvious uses of symbols, since every page will almost always have the same navbar. But you can't connect objects inside a symbol. Therefore, you can't connect nav items, icons, logos in a nav bar.
Either allow connects for objects inside symbols, but don't propagate them in all instances, or DO propagate them in all instances. But you HAVE to be able to connect objects inside symbols in prototype mode.
Otherwise, we can only get halfway to easily and efficiently editing UI elements like navbars, sidebars, and such.
Thanks
With this month’s symbol overrides feature, you can now wire from within a symbol.
-Elaine
-
James commented
Hey Peter, I think that in the short term when copying and pasting any graphic or symbol it should copy the prototype link with it. Then, you can consider the option of how symbols might work as a second stage of development. It surely cannot be that hard to copy the prototype link when copying an already linked graphic or symbol?
Re. symbols and linking. How about if the way you copy the symbol dictates it's linkage properties. For example, cmd + c and then cmd + v copies the selected object with the prototype linkage intact and cmd + shift + c and cmd + v = copies the symbol with no linkage?
-
Kyle Schmitz commented
I think you make them propagate the connections across all instances of the symbol.
This would create 'templates' for prototyping much in the same way Invision does it. If I need to add a new page to a current project, I then have to recreate all those connections. With Symbols that 'remember' their links/connections, I just duplicate the page and you have just saved me a TON of time.
-
Paul Waitforit Mooney commented
I am still in the process of adapting my current project and did not realise this issue :-(
In response to your comment Peter, I would like to primarily have all instances act the same so would vote for a universal override, however there are circumstances where we have to make subtle changes to an interaction on a page because of the nature of the prototype to help it imitate real life. I would be happy to break the symbol in that instance to do that as this is a rare case for me and when working on large projects, the prototyping is an absolute pain when I wire up 50+ screens to slide left and I either missed one or two that dissolve, or have to iterate to a push left after feedback (for example).
-
Steve O'Connor commented
"That is, should interactions act more like overrides, separate on each copy of the symbol? Or should interactions automatically apply universally to all copies of the symbol?"
Ask when adding the interaction would most likely be the ideal.
With the option to change that choice in the interaction popover.
-
Anonymous commented
This will be a great advance in symbols. It was the first issue I saw when I tested it.
-
Justin Wilden commented
PAGE LINKS
1. Start by automatically applying links (on all objects) universally to all copies of the symbol.
2. Allow user to override in each separate instance of the symbol if the user wants.
3. Allow reset to original.STATE LINKS
- Symbols have states (layers).
- Allow user to add links to an object within a Symbol to change the Symbol's state (aka Axure). -
Isaac Powell commented
Perhaps the ability to propagate to all instances of a symbol is the default, but with the ability to override. This allows for both macro and micro level control.
Another use case of that is buttons. If I have a 'Go to Store' button as a symbol, with a default connect to the Store screen within the symbol, then it allows me to drag already-connected elements onto my pages, whilst hopefully having the ability to override that connector if I want the button to change it's copy and location.
-
James commented
Yes, please.... Really need the prototype links within symbols.
-
Toon Van de Putte commented
I think that within the current philosophy of XD, the links should be specific to a particular instance of a symbol. This would be in line with how artboards work: a copied artboard does not retain its links.
Ultimately, you'd want to give users some more control over this, but I think the most intuitive solution at the moment would be to be instance-specific. -
Joel Meine commented
Allowing symbols to be grouped or nested inside each other is a phenomenal feature, however without the ability to select a individual symbol that is nested in another symbol and target/link it (as a nav element to another art board) reduces the value of the symbol feature. Currently only the entire grouped/nested symbol can be selected as single whole used as to link/target another art board.
Currently a user must manually create invisible rectangular shapes in each view,overlay them on the symbol and "hack the link" on each art board. vs sourcing the link in the symbol itself.