To LI or not to LI… that be the question…

This post on X from @Headteacherchat and the article by Joee Winter in Issue 27 (July 2025) edition of the Raspberry Pi Foundation’s “Hello World” magazine reminded me that following a senior colleagues lesson observation in Summer Term 2023 where I was attempting to teach a lesson about spreadsheets, I was questioned about why I did not explicitly set out the lesson’s Learning Intention or Outcome.  In not doing so meant, as my senior colleagues highlighted, members of the class I was teaching not being able to articulate exactly what it was they were meant to be learning.  Whilst I understand the importance or expectation of setting out Learning Intentions or Outcomes as well as “Success Criteria”, teaching Computing, and I would suggest for other subjects too, the actual learning dynamics are so much more than just focusing on a single statement.

Take for example the use of count-controlled loops and nested loops when teaching repetition in shapes in Year 4 (8 to 9 year olds for our international connections).  A forensic level reflection of this lesson reveals as teachers we make assumptions about a wide range of declarative (I know that…), procedural (I know how…) as well as conditional (I know when…) knowledge:

1.  Sign in or log in: the ability to exercise their procedural knowledge of using a keyboard to type in either a generic user name and password so that every individual is able to access a device or to be able to recall the personal user name and password each has been issued with. Setting the focus of the lesson on the use of count-controlled loops might mean that it would be of greater benefit to simply have a generic log in process but that might mean compromising with safe access to the web unless the devices are supervised with some classroom management software to track, trace and control what web content can be accessed.

2.  Recognise how to access Scratch: whether this be as an app on the device or the web based version. Using the Scratch app has the added advantage of requiring the learners to focus on the task than be distracted by finding games created by other users.  Using the web based version of Scratch also means expecting the children to “know that” they need to use the browser on their device and “know how” to go to the Scratch website.  For some children may be less familiar with the use of terminology like ‘browser’ and ‘address bar’ where the children end up needing time to access the Scratch website by using a search engine instead.  To bypass this time consuming process, the browsers at the school I work for have been set up with a home page which contains a link to the Scratch landing page.

3.  Understand the relevance of the sprite: for repetition in shapes, the children need to “know that” the sprite is acting as a proxy for a cursor. It might therefore be useful to explain or demonstrate how they are essentially learning about how to control a robot that has a pen holder capacity to move and create shapes and patterns.  Some children may also inadvertently click into the background area of Scratch which contains none of the blue motion blocks, delete the sprite or decide they want to use a different sprite.

4.  Position and direction: this can be the most abstract part of repetition in shapes. To say that a count controlled loop to repeat 4 times can be used to draw a square by using “move” n number forward then “turn” 90 degrees opens up potential scope for significant misconceptions about position and direction that will affect the outcome of the shape.  Some children will inevitably try to use very large values to move forward.  Starting from the origin, lines of more than 180 pixels will mean the shape is not fully displayed so that a logic error occurs with the pen function failing to plot a regular polygon that the program is intended (and lesson) to create.  It is important therefore to specify a range of values and remind the children that they must “know that” higher values above an upper limit will enable the program to run but the ‘output’ will not be as intended.  To make this abstract concept more tangible, I have previously compared this construct with programming a drawing buggy a distance greater than the size of a sheet of A4 or A3 paper to address this commonly made misconception.

5.  Pen size and pen colour: Scratch has the capability to not only change the value of pen size but to change the pen size too during a program for artistic effects. However, this creates a commonly made misconception that higher values will display correctly.  Increasing the pixel size of the pen or using the change pen size block will enable the program to run but generate an output that does not correctly meet the success criteria even though the count controlled loop is correct.  This commonly made misconception is perfect opportunity for learners to exercise their both their procedural knowledge of “knowing how” and conditional knowledge of “knowing when” to fix or debug the program.

Given these multi-level layers of learning, demonstration of declarative knowledge and practice of procedural knowledge, it is arguably too simplistic to focus on a single statement setting out the learning intent for any lesson and better to focus on the expected output or outcome by evaluating the children’s efforts on “what went well” and “even better if…”  But that might be considered a wholly different teaching approach open to more debate on social media… a bit like a loop function running on repeat…