In an artboard model for building a UI prototype, the same object may well recur multiple times across various artboards. The underlying ‘run’ model dates back 25 years or more to a movie frame notion of animating through the frames (or artboards).

But Protopie lives much closer to a software model in which the scene represents a functional activity for the user. Within a scene objects may appear, disappear, move or change value but the prototype stays on the same scene throughout.

For example, in Figma one might create the graphical view and then create variants of that view and then link the animations together. With AutoLayout too one might end up with the object structure closely reflecting the graphical layout.

In Protopie it is the interactional elements that need to be reflected in the structure, and the prototype itself needs to know what state it is in (e.g. which tab is active). This leads to a very different workflow than you might follow in tools such as Figma – with Figma you don’t really want to create variants of a component until the graphical aspects are relatively complete, whereas in Protopie you would focus on creating the interactions first and then adjusting the graphics later.

A common pitfall is to start one’s Protopie pie with lots of scenes and lots of shared objects between them an d then to use ‘Jump’ responses to move the user forward.

At the beginning of building your pie, it is really important to think through the possible scenes and to consider ways to reduce it down to as few as possible. Or maybe to as many as possible, with no duplication of objects and functions between them.

This pitfall has implications when you import your layers from Figma or other tools. The way you choose to layer objects is very different in the two mental models – creating components out of imported layers can be very complex, because the elements may not be close to each other in the imported artboard.