The wrong variable type

Sending a message to another scene

This is a very easy mistake to make – sending a message to be picked up by a component, but one that you have in fact placed into a different scene. Although you can send to a different pie, you can't send to a different scene.

Use Variables

Variables are very powerful simplifying tool and they do not seem to have any impact on Protopie's performance.

Arrays and multiple parameters

Protopie seems limited since a message can be sent using only one value as a parameter. However, arrays (written as text strings and manipulated by parseJson) can be used for contexts where multiple parameters need to be passed.

Put code inside components

Protopie code can get complex and hard to follow surprisingly quickly. Putting as much code as possible within your components can keep your main scenes simpler and cleaner.

Viewing variables within Components

The variable debugger doesn't work when the variable that needs to be viewed is inside a component. There are two relatively easy ways to deal with this.

Good Prototyping Practice

IDEO's 3R prototyping principles from the late 1990s still apply - "Right, Rough, Rapid" but in the UX and UI space they are easily misunderstood.

Use Components

It will often seem as though it will be faster to use individual elements than to use components, but in the end the time saving almost always goes the other way.

Keep trigger and response names visible

It is very important to annotate your code with what it is actually doing, but keeping the trigger and response names helps someone new to the project (or you in three month's time.

Arrays and multiple parameters

Working with Components

Use Components

Distinctive initial variable values

Using the wrong mental model for Protopie

Check if your other pie is present