I pulled out batteries, pipe cleaners, etc in an attempt to figure out something that would work with physical objects. But the question popped up - are the wires and batteries "real" in that there's real charge going through, or are they just symbols for things that will be interpreted by Realtalk? I think we'd want to be able to turn any physical object easily into a symbol that Realtalk understands, maybe by placing a framecode around it, like La Tabla's animation program simply captures any physical object that's in a frame. 

Wires also feel good to manipulate as physical objects in the real world, but maybe there are better affordances to drawing out the wires on a whiteboard or with a marker. 

I also brought out tater tot as a physical object that could move around on the table and follow lines. Tater is slow, but it would be interesting to use a bot as a token to represent moving charge. 

Things that I noticed from the jam are:

• adjacency: alignment and closeness were key in determining the behavior of the cards. Makes a lot of sense. Seems like a definite part of the "building blocks" of being able to conversationally program.
• duplicating: If I want many ANDs, I photocopy them. Or cut a card in half and write AND twice. How do we quickly have many copies of an object, to facilitate conversational programming? Perhaps we have stacks of different colored cards, and we can use those colors to signify different rules. 
• abundance of tokens: Alex went with the assumption that there were an abundance of black and white go tokens. I thought this was interesting. Certainly, paper is a building block of our system. What else do we have an abundance of? Framecodes? Or will the abundance of things evolve as we have recognizers for them? There will probably be a "go stone recognizer" program that gets reused frequently in many subsequent programs. 
• how to use projection in a prototype: For some reason when I was jamming I didn't really have a good way of thinking through how things would be projected. In other people's jams I also noticed that having a way of using projection in the jams would make for a better experience. This makes me want a kind of basic photoshop for projection, for use to create things like when Toby and I quickly mocked up this idea http://media.dynamic.land/objects/c4584d3b61da87e5fbbe1d4cbc18d94cce5e474e/download?extension=1 .
• cards vs color as primitives: In many of the jam ideas, the cards are the primitives that would be adjacent to other rules, have input/output, etc. This is unlike the etoys example where color is a primitive. The distinguishing feature is that if color is a primitive, we get to change behavior of things within cards as well. 
• on-ness: Maybe particular to programming logic circuits, but knowing when something is ON is necessary, and was depicted in many different ways in the jam yesterday. I really liked Alex's and Bret's comment about using projection to signify "on," something is on if it is lit, and that is something that the system understands.
• words: I think we all used words to program the rules. Josh made use of color and shapes, and Alex made use of the go tokens. All these methods are plausible, but it is interesting to think about the interplay of non-words and words to program.

Paula