Start a new topic

Shared interaction for widget

It'd be nice to be able to save interactions inside widget. For example we create a widget «Main menu» for website. We can use this widget on every page and then we can easy change the set and the order of items of menu across prototype. But it's only visually. Today we have to manually setup "Goto screen"-interaction for every menu item on every prototype page.

3 people like this idea

definitely a missing feature. As a crude workaround you can add the interactions to the „Main Menu“ widget, copy it and paste it to the other screens. Copy/Paste keeps the interactions intact.

We discussed this feature internally and were not sure to what extent we need overwriting (like in the widgets). This means changing a interaction in an instance do we need the same update/revert-machinery for interactions too...

Thanks for mentioning the feature request.


dear antetype team, this feature would be very handy. we are creating a 200 page wireframe with different menus. copying the menus by hand .. oh lord .. hoping the client will not change the site structure. unfortunately i discovered this after we decided to use antetype. of course the program is great(!) but i was a bit shocked finding out about this.. :)

kind regards

Hi Julian,

shared interactions are still on our road map.  The problem is a little bit the granularity of what is a shared interaction, and which interaction should be only available in a particular instance. Maybe not for goto-screen actions, but for other actions it might be needed to have a shared action, and some or more individual actions. For your particular use-case: would you need fine-grained individual/shared-interactions?

Thank you for taking part in the discussion.

thanks for your reply. in our case it would be best if widgets would simply allow sharing interactions except if non-updated. A option shared/individual for an Action within an Interaction would be one step further. kind regards

must say, this is becoming really a serious issue for me because i cant use the privilege of synchronized widgets at all. when i'm updating my nav-header-widget all the interactions of objects in it (e.g. menulinks) are gone... (?) wether they are widgets themselves or not. so this means everytime anything changes in the nav-header-widget i need to manually copy and replace it on every page. mh  to be honest, i chose to use antetype because of its functionality to synchronize objects. manually copying is exactly the thing i wanted to avoid.. :)

kind regards

I can confirm the bug with loosing the interactions after updating the widget. We will have a look into the issue. Thanks for reporting and sorry for the problems.

best regards,



I also would really like this feature, for me it doesn't even need to be very fine-grained in most situations. Even a "global" shared/individual setting that applies for all interactions in the widget would be sufficent for me as a first step.

The workaround with copy/pasting cells kind of works (apart from the bug mentioned), but obviously destroys the widget hierarchy every time you paste something into a widget. (To avoid this, a "copy/paste interactions" option would be cool).

while looking at the problem we discovered one bug, which might be your problem. In the following structure, each screen has the same menu with goto-screen-actions to jump to the various screens:

Moving for example "Screen A" to a different position inside the menu and updating the menu widget removes the goto-screen-action from the "Screen a"-cell on all screens.

We have a fix for this one which preserves the actions. Do you have other scenarios where the actions are lost after update? 

We have code freeze for the upcoming 1.6.2-release, so this will not make it into this release. Just wanted to make sure we don't miss other problems.

I know this does not remove the need for shared interactions. Thanks again for bringing up the issue. 

just for the record, we managed to include the bugfix in 1.6.2 for the problem mentioned above.


Felix, thanks for good news.

Additional scenarios – on your example.

Problem 0 is not about interaction for widget. And it’s not serious, but it’s problem anyway.

0. Duplicate screen ‘c’ and rename current (selected) screen to ‘d’.

Select menu item ’Screen c’ – Surprise. Now the menu item leads to the 'Screen d'. When I rename the screen I thought that new rename the newly created screen (copy). I expected that when I create a copy of it immediately becomes selected and once I can work with it. Perhaps the current behavior makes sense. But due to the fact that the original and the copy and named the same I do not understand that you have selected the original and I change the old screen and all references to it.

1. Duplicate menu item ‘Screen c’, rename it to ‘Screen d’, and update whole menu widget.

Result - OK. All screens have 4 items in the menu.

Now I want add interaction to new (‘Screen d’) menu item and update whole menu widget.

Add interaction – OK.

Update Menu widget – Problem. No green button and no green dot for ‘menu sample’.

2. A similar problem when I want to change the interaction.

Add new screen ’screen a - alternative version’ – OK.

Select menu item ‘Screen a’ and change Action->Screen = ’screen a - alternative version’. – Problem. No green button and no green dot for ‘menu sample’.

Hi Fedor,

the "Problem 0" is due to the change we made in 1.6 to adjust the actions to the copied (or duplicated) screen. Before the change the actions pointed to the original values which was wrong in a lot of cases. Imagine for example a button which collapses an element on the screen. Duplicating the screen did reference the element on the original screen. I have to look again, but yes for goto-screen-actions this behavior is confusing. Yes, we should change the name of the duplicated screen.

If I understand the other problems correctly this is due to our inability to store interactions in the widget. Since the interactions are only available in the instance, changing them does not mark it for update/revert. Maybe we could as a workaround adjust the actions on the other instances, but my feeling is: it would be wiser to implement shared-interactions correctly. I have to think about it.

Thank you for the detailed descriptions.


Login or Signup to post a comment