Teacher Notes: Session 1 - Instructions & Systems

These notes are background for Session 1, with teaching prompts and a few possible directions. They can also be shared with students who want to go a bit deeper.

Why this session exists

Students often find it surprisingly difficult to invent a simple rule. If you ask them to create a generative system, they tend to jump straight to an image, an effect, an animation, or some complicated piece of code.

The idea of this session is to move further back and ask:

What actually happens?

Even something as simple as:

Place two points and connect them.

already contains a lot of decisions.

Where are the points? Who decides? Can they overlap? What connects them? Does the line stop at the points? What happens after that? Can the process repeat? When does it stop?

So formulating the rule is already part of the design.

I think the class should move through something like:

instruction → execution → outcome → comparison → revision

and eventually:

human executor → computer executor

The instruction spectrum

I wouldn’t present rules as a simple opposition between precise and ambiguous.

Instead, use the examples to gradually build a spectrum:

specified → constrained → interpretive → poetic

The main question underneath all of this is:

Where does the author keep control, and where do they allow interpretation?

This will come back later when we talk about randomness, parameter spaces, agents, interaction, AI prompts and generative media.

Sol LeWitt: where is the work?

I would use LeWitt to establish the relationship between:

idea → instruction → execution

A good way to do this is to show the written instruction before showing the visual result.

Ask the students to quickly sketch what they think the instruction might produce, then show them one execution.

Some questions:

It would be useful to bring several wall-drawing instructions rather than just one, so students can compare how much each instruction seems to determine.

I would also avoid presenting LeWitt simply as the “strict rules” artist. Many of the wall drawings actually leave quite a lot of responsibility to the person making them.

Useful source:

Conditional Design: designing conditions

Conditional Design changes the relationship from:

author → instruction → executor

to something closer to:

rules → participants → interacting decisions → evolving outcome

The interesting thing here is that every action changes the state of the system for the next person.

So it introduces quite a few computational ideas without needing any code:

The important distinction is between:

designing a composition

and:

designing the conditions from which a composition can emerge

I would bring the Conditional Design book and let students browse it. There’s probably no need to turn the whole archive into slides.

Some questions:

George Brecht: from image to event

Brecht is the first point where the category starts opening up quite a bit.

With his Event Scores, an instruction doesn’t have to generate a visual composition anymore. It can generate an event, an action, a sound, or a situation.

I would show Water Yam visually first. The box of cards makes the idea of a collection of executable propositions pretty immediate.

Then focus on Drip Music (Drip Event).

The Getty Scores Project is particularly useful here because it includes:

Rather than spending a lot of time explaining Fluxus, I think it would be more interesting to compare different realizations.

Questions:

This is also a nice early bridge toward sound and time-based work later in the semester.

Alison Knowles: the ordinary as a generative system

Make a Salad works well because students immediately understand the basic action.

You don’t need any specialist art knowledge to understand what “make a salad” means.

But at the same time, the score can produce radically different events depending on:

The Walker article is useful to project because it has a lot of documentation from different performances.

Ask:

What needs to stay constant for this still to be Make a Salad?

This connects quite directly to generative coding.

If a program produces thousands of different outputs, what makes all of them outputs of the same system?

I think this example also helps with another important point: a simple rule isn’t necessarily a weak rule.

Yoko Ono: when execution becomes imagination

Ono works well at the end of this reference sequence because she pushes the idea of an instruction the furthest.

In Grapefruit, a score might be:

I would use the MoMA object page as a visual reference for the book itself, and the Moderna Museet text for a bit more conceptual background.

The interesting discussion isn’t really whether these are “real instructions”.

Instead, ask:

A useful follow-up is:

What would happen if we made this instruction perfectly precise?

Quite often, the poetic quality would disappear.

This sets up an important idea that should come back throughout the course:

Precision is not automatically better.

The designer chooses where precision is useful and where openness is useful.

The five examples as a progression

I think I would teach them in this order:

  1. Sol LeWitt: specify
  2. Conditional Design: constrain
  3. George Brecht: produce an event
  4. Alison Knowles: structure an everyday action
  5. Yoko Ono: activate imagination

I wouldn’t spend equal time on all five.

A possible rhythm could be:

The goal isn’t to turn this into an art-history lecture.

The point is to gradually destabilise the students’ idea of what a rule can be.

I would finish this part with:

How much should a rule determine, and how much should it leave open?

Then move into making and executing rules.

From one rule to a system

I think this is one of the most important demonstrations in the session.

Build a system live with the class.

Start with:

Place a point.

Ask them what’s missing.

Then:

Place two points.

Then:

Connect them.

Then add repetition.

Then a constraint.

Then a stopping condition.

I wouldn’t invent all of the rules myself. Ask the class what could come next.

The point is to show that:

Complex outcomes can emerge from simple relationships.

Students need to feel that they’re allowed to start with something extremely simple.

Useful vocabulary

When students get stuck, these words can help:

I would treat these as scaffolding, not as a checklist. A system doesn’t need all eight.

Common student difficulties

“I don’t know what rule to make”

Ask:

What is one thing that can happen?

Then:

What can it respond to?

Then:

Can it happen again?

The rule becomes complicated immediately

Try removing rules until something interesting still happens.

They describe a picture rather than a system

Ask:

What could change while the rules stay the same?

They use randomness whenever something is unspecified

Ask:

Do you want the decision to be random, or do you want the executor to decide?

These aren’t the same thing.

They think unexpected execution means failure

Try to redirect from:

They did it wrong.

toward:

What information did your instruction actually contain?

An unexpected result is useful. It tells you something about the system.

Human to Human

Keep the visual vocabulary quite constrained:

The executor shouldn’t see the intended result, and for the first execution they shouldn’t be allowed to ask questions.

The discomfort here is useful.

When comparing the results, focus on:

Ask students to revise only the rules that had the biggest effect rather than rewriting everything from scratch.

Human to Computer

I wouldn’t let this final part turn into a JavaScript lecture.

The computer is just another kind of executor.

Keep the p5.js vocabulary very small.

The useful comparison is that a human might understand:

Draw a circle near the centre.

but code forces the student to decide what “near” means, what “centre” means, how big the canvas is, and how big the circle should be.

Avoid loops, randomness and animation for now. Those belong in the following sessions.

Connection to later AI work

I think it’s important to explicitly return to Session 1 once generative AI is introduced.

Compare:

human-readable instruction

p5.js code

AI prompt

These create three quite different relationships between author and executor.

Questions to come back to:

This makes the early no-AI exercise directly relevant to the later AI part of the course rather than feeling like a separate introduction.

Sources worth keeping open during class

The detailed links are collected in examples.md.