I have an issue with a nested element that has an interaction which we’ll call interaction_1. The board that the contains the element also has an interaction we’ll call interaction_2. In Preview mode, it seems that interaction_1 is never triggered even if the nested element is visible. Clicking on the nested element always triggers interaction_2 which is the interaction of the board. Below is an image depicting this issue.
Shouldn’t clicking on the element trigger its associated interaction instead of triggering the interaction of the element’s container given the following:
1- The element is visible, meaning that its container is in the background.
2- The board has no layouts associated with it meaning that no Z-order settings (ie- Absolute positioning) is in play.
Just to elaborate on my use case that caused me to post this:
I have a card that contains an image. When I click on this card, the image is to be re-rendered full screen.
On the upper right hand corner of this card, is a star icon that is rendered unfilled (ie- only the outline of this star is shown). When I click on this star, the unfilled star is replaced with a filled star.
When I try to prototype this use case using Penpot’s interaction constructs, clicking on the star causes the image to be rendered full screen which is not what I want.
Can somebody point me in the right direction as to how to do this in Penpot and still keep the star on top of the image card?
What you seem to be trying is to create some micro interaction related to this star. The thing is that Penpot, as of right now (ver 2.2) is not good with micro interactions. You would need two different versions of this card (the one with the star unfilled and another with the filled version) so you would be able to create this interaction. Just remember that the interaction would be changing from Screen A to Screen B and not directly from a component to another.
You can also try using the open or toggle overlay trigger, there the process would be a bit different and might not need to have a whole component just to change a single detail. In this case, just add a trigger to open overlay and add the filled star as the overlay on click, set manual positioning and set it over the unfilled star.
I know it’s kinda sad not to have variant interactions or other easy paths to do it but it is the way to go right now, maybe in the future we will see changes over that.
thanks again, @RenanMayrinckDesign , for replying. I looked up ‘micro interactions’ and what I got is subtle animations for feedback purposes which in some ways is what I want , but as you pointed out, the wanted feedback is doable with Penpot overlays.
As for the Photo card (which is a board with an embedded image), the wanted interaction is simply an onClick interaction that will launch another board with the image blown up. This is also doable in Penpot.
The problem arises when I embed the star into the photo card. Instead of seeing a filled star when clicking on the unfilled star and seeing a blown up image when clicking anywhere in the photo card excluding the star area, what I see is a blown up image when clicking on the star, telling me that the interaction of the photo card is overwhelming the star’s interaction even if the star is visible on top of the photo card.
This seems to be a scoping issue regarding the click areas of nested elements where the container interaction will always override the interactions of nested elements. I can understand that maintaining state across boards is a big deal, but its sort of puzzling why click areas of embeded element is not resolved properly (assuming this is the problem).
I’m going to bring this up to Mario just to confirm that this is indeed a limitation with the current version of Penpot.
You are true, the interactions should work as you expect. But there are some technical limitations that are causing this behavior for now.
We currently render Penpot designs as a SVG structure in the browser’s DOM tree. This has many advantages but also adds the problem of that SVG is not powerful enough to represent all Penpot capabilities out-of the box (for example outside strokes). This forces us to apply some hacks, that allow the designs to be represented with reliability, but have some side effects like this one that are difficult to avoid.
But, as you can see here, we are now working in a deep rewrite of this process. When we have the new rendering engine we expect to have solved those kind of issues.
Thanks, @hirunatan, for replying. Just mentioning ‘DOM’ brought back memories, a lot of it unpleasant, of workarounds I had to do due to that object model when I was doing work for the browser.
I am looking forward for this issue to be resolved.
/Joselito
PS: Not meaning to be a suckup, but I keep forgetting that Penpot is on the browser, which is a testament to how responsive Penpot is despite inherent limitations of the browser.
Well, I’ve figured out a way to do this as a workaround, Hope it will be helpful for you @josel!
If you wrap the whole card in another board and then take the star icon off the hierarchy (right beside the content of the card), both interactions will coexist just fine, as in the example below:
As I poke around Penpot, there is real value in my workflow as a barebones Flutter dev to use Penpot for my wire frames / UI flows instead of using nested and declarative lines of Dart code. You finding a solution to this issue made this even more possible.
