Skip to content

UX Prototyping & Protopie

  • Principles
    • Educational
    • Figma Integration
  • Patterns, Pitfalls, Ploys
    • Patterns
    • Pitfalls
    • Ploys
  • More …
    • People-Centered Design
    • Thinking about AI
  • Principles
    • Educational
    • Figma Integration
  • Patterns, Pitfalls, Ploys
    • Patterns
    • Pitfalls
    • Ploys
  • More …
    • People-Centered Design
    • Thinking about AI

How to inspect variables inside a component

For many Protopie users components are a little scary. One factor that reinforces this is the fact that the variable tracker does not enable you to inspect a variable that is inside a component.

As a result, when something is not working within a component it can be hard to find a way to see what is happening and what is going wrong.

A common solution to this is to add a text field into the component and have its value be the variable you want to inspect. But this requires that you have space for an extra text field and don’t mind its disruption to your emerging design. You can. of course, show and hide this field as you need to.

An alternative solution is to use a ‘Detect’ trigger and a ‘Speak’ response. Within the component simply add a trigger for detecting a change in the variable of interest (or add one for each variable) and use the response to speak the value of the variable. You can add text around the value of the variable, or have multiple variables spoken in sequence, using the normal string concatenation operator +.

You can keep this code in your component and disable it when it is not needed, and then turn it on as needed. 

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.

The wrong variable type

This pitfall is not a big deal, but it can waste you time as you try to track down why your variable seems to have the wrong value (or no value). It can also bite you in a formula where your variable is of the wrong type for the formula.

Rough, Rapid, Right

Using the wrong mental model for Protopie

Most prototyping tools for designers use the frame-by-frame, or multiple dartboards model. But Protopie is much closer to a developer's object-oriented model of an application UI.

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.

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.

Working with Components

Playing with time

A message sent to the current scene will be received by the object that sent it. But a message sent to Protopie Studio (Connect) will not be received by the pie that sent it. B ut what if there is nothing out there to respond to it?

Using the wrong mental model for Protopie

Working with Components

Receive and Assign hazard

Sending messages to two places

Use Variables

Keep trigger and response names visible

  • Welcome
  • What’s New?
  • About
  • Welcome
  • What’s New?
  • About

info@peoplecentereddesign.org

© 2026 David Gilmore