Living Museum of Learning
From Drawing to Structure
Ivy is on Day 3 of a 14-day experiment designed to see what can emerge when learning is given continuity, room for exploration, and increasingly open-ended problems.
She had finished her regular homework too quickly, so I gave her a bonus:
Create a new iOS project in Xcode and draw something like a Rubik's Cube.
She immediately connected the task to an earlier p5.js experience and asked:
“How to make the view 3D, like the thing we did in p5js?”
I deliberately did not take her into 3D graphics.
“No need for 3D. Just 2D. How do you show a Rubik's Cube in 2D, like on paper?”
She replied “ok,” then created her own draft in AutoDraw and asked whether it was the right representation.
It was. 💯
What made this particularly interesting was that she had not touched Swift for roughly two months.
Yet she was able to return to UIKit, create a UIView, work inside draw(_:), use UIBezierPath and CGPoint, construct the cube from lines, and use loops to generate the repeated grid structure.
The second half of the class moved from drawing to abstraction.
We returned to an earlier p5.js project and examined:
line(p7[0], p7[1], p7[2], p9[0], p9[1], p9[2])
Instead of immediately writing a function, we looked carefully at what the expression was actually doing.
The first abstraction Ivy proposed was:
connectVertices(v1, v2)
That was already a meaningful step: she had recognized that the operation was really “connect these two vertices.”
Then, step by step, we pushed the abstraction one level further.
The vertices themselves did not need to be passed around. The important information was which vertices we meant.
That led to:
connVertices(n1, n2)
Now the function expresses the intention—connect vertex n1 to vertex n2—while hiding the coordinate-level implementation.
The long concrete expression had become a small, reusable idea.
Two projects that looked completely different began revealing the same underlying habit of mind.
In the p5.js project, Ivy learned to look at repeated concrete operations and discover the abstraction underneath them.
In the iOS project, she started with a visual object and discovered its geometric structure: faces, grid lines, repeated cells, and coordinates.
Then the next step became obvious.
A Rubik's Cube is not merely a picture. Its cells can be numbered.
The drawing can become data.
The geometry can become a model.
And the model can eventually become something a program can manipulate.
This is especially striking because Ivy did not begin by being taught “how to build a Rubik's Cube.” She was given an open-ended question and had to construct the representation herself.
Day 3 produced several different kinds of learning at once.
1. Transfer
After two months away from Swift, Ivy was able to transfer concepts she had learned previously back into a new project. The knowledge had not disappeared; it could be retrieved when a meaningful problem required it.
2. Representation
When the task sounded like a 3D problem, Ivy initially thought in terms of 3D technology. By asking how the object could be drawn on paper, she was pushed toward representation rather than implementation.
3. Geometry
Her independent UIKit code showed that she could express a visual structure through coordinates, line segments, repeated offsets, and loops.
4. Abstraction
The journey from
line(p7[0], p7[1], p7[2], p9[0], p9[1], p9[2])
to
connectVertices(v1, v2)
and finally to
connVertices(n1, n2)
was a journey from implementation details toward a meaningful interface.
5. Modeling
The next challenge—indexing the cells on all six faces of the Rubik's Cube—moves the same thinking from code into data. She now has to decide how a visual object should be represented systematically.
6. Independence
Perhaps the most important observation is that much of the work happened without step-by-step instruction. The teacher supplied constraints, questions, examples, and occasional guidance. Ivy supplied the exploration.