Process
At first, I was unsure what this assignment meant, especially how a programming concept could be translated into a physical metaphor. Once I understood the task better, I came up with several possible ideas. I initially wanted to explore a more complex concept (Idea 1), but I also considered a simpler idea that would be easier to realise in physical form (Idea 2).
Design steps
To make the design process more explicit, I described it in three steps.
Step 1 - Selecting a programming concept
My first step was deciding what kind of programming idea could be made physical at all. I quickly realised that not every concept works equally well as a tangible metaphor. I therefore focused on concepts with a clear, visible structure, such as branching, flow, repetition, or self-reference.
Step 2 - Exploring multiple physical translations
The second step was trying different physical metaphors for those concepts. Here, I moved from abstract programming ideas to possible materials and situations in the real world. This is how I arrived at both the if/else route model and the mirror-based recursion idea. At this stage, the goal was not yet to perfect one design, but to explore which metaphor made the underlying logic most visible.
Step 3 - Evaluating which metaphor best supports understanding
The third step was comparing the ideas in terms of clarity, physicality, and interaction. I asked myself which metaphor makes the programming concept easiest to see and explain, and which one allows a user to interact with it instead of only looking at it. That comparison made the if/else model stronger as a manipulable object, while the mirror recursion metaphor became stronger as a conceptual image.
This design sequence helped me move from an abstract programming concept to a tangible representation. The point was not only to name a concept from programming, but to explore how that concept could become physically understandable.
Idea 1
Figures 1 through 6 visualise an if/else statement in physical form. The model begins with the question, "Is the pen red?", which represents the condition being tested. If the answer is true, the pen follows the "True" branch, leading to the outcome "The pen is red." If the answer is false, it follows the "False" branch, leading to the outcome "The pen is not red." Figures 3 and 4 show a red pen moving through the model and exiting through the true branch, while Figures 5 and 6 show a green pen exiting through the false branch. The forked structure of the model makes the decision-making process visible: one condition leads to one path, while the alternative leads to another. This reflects how an if/else statement in programming evaluates a condition and selects only one of two possible outcomes. In this way, the object becomes a physical metaphor for conditional logic.
Figure 1. Top-down view of the "If/Else" statement.
Figure 2. Sideview of the "If/Else" statement.
Figure 3. Red pen entering the "If/Else" statement.
Figure 4. Red pen leaving the "If/Else" statement through "True/If".
Figure 5. Green pen entering the "If/Else" statement.
Figure 6. Green pen leaving the "If/Else" statement through "False/Else".
Idea 2
This was actually the first and simplest idea I came up with. The mirror images in Figures 7 and 8 visualise recursion through self-reference. The camera captures a scene that contains the same camera and scene again, creating smaller and smaller nested versions of the same image. This is similar to a recursive function, which solves a problem by calling itself on a smaller version of that problem. The image also shows that recursion is not endless in practice: at a certain point, the repeated images fade or disappear, just as recursion must reach a stopping condition to end. In this way, the mirror becomes a physical metaphor for both the structure and the limit of recursion.
Image 7. Recursion (vertical).
Figure 8. Recursion (horizontal).
Reflection
What makes these metaphors useful is that they not only represent programming concepts visually, but also make certain properties of those concepts easier to understand through interaction. In the if/else model, the main insight is that one condition leads to a choice between two mutually exclusive paths. A user can test this by inserting different pens or objects and observing that the same structure produces different outcomes depending on the condition. That makes branching logic more tangible than when it is only written as code.
In the recursion metaphor, the main insight is self-reference: the structure contains a version of itself again and again. At the same time, the mirror image also suggests an important programming idea, namely that recursion is only useful if there is some practical limit or stopping condition. Without that, the process would not resolve meaningfully. Even though this version is less hands-on than the if/else model, it still helps make the idea of recursion less abstract by linking it to a familiar physical experience.
In terms of interaction possibilities, the if/else model is the strongest because users can actively test different inputs, compare true and false outcomes, and possibly even replace the condition card with another one. That means the material could be extended into a small toolkit with interchangeable conditions and outputs. The recursion metaphor is less interactive in a manipulative sense, but stronger as a reflective metaphor that helps someone grasp the structure of repeated self-calls. Together, these designs show that physical metaphors for programming can support understanding by turning invisible code structures into visible and, in some cases, touchable forms. This also fits the constructionist idea from Invent to Learn that learning becomes stronger when ideas are turned into meaningful, shareable objects that can be explored and discussed.