Playing is finding joy in open-ended exploration, without being concerned with a specific outcome. Play allows ideas to be reimagined through new representations, avoids following conventional ways of thought, and uses rules and limitations as means to creativity. Used in conjunction with other imaginative skills, it leads to the transformation of ideas, by altering modes of representation or finding connections across (and above) disciplines (Root-Bernstein & Root-Bernstein, 1999).
While I initially considered play as an underutilized skill in creating algorithms, I found that it can be one of the most useful ways to be creative in problem solving, such as with my proposed activity that uses playing with a simple programming tool to introduce algorithms to elementary and middle school students. While it uses open inquiry to allow the students to freely explore how instructions are constructed, I kept some constraints and broad goals in place to promote deep or hard play. The only way to construct the algorithm was through the blocks available in Scratch, and with each of the challenges, students were given the freedom to explore but needed to apply what they learned towards increasingly complex goals.
Scratch provides an easy to use entry point for young students to create programs using natural language and drag-and-drop blocks of code. The interface uses natural language instructions that allows projects to straddle the line between algorithm and program: once the blocks have been snapped together, they describe a method to solve a problem, but Scratch encourages students to play with the algorithm through easily modification, and the results are instantaneous – the blocks can even be changed while the program is running. In my experience with Scratch, allowing young students to start with a drawing algorithm provides an introduction to the value of play when coding.
The idea of drawing through algorithms is at least half a century old. In Mindstorms: Children, computers, and powerful ideas, Seymour Papert (1980) promoted using the LOGO language to create patterns with students of all ages, and Scratch is the spiritual successor to LOGO. Papert also adapted constructivism, the idea that learners construct knowledge through experiences, into his own theory of constructionism, where learners create a meaningful product to develop new knowledge. Scratch is a great tool for use in constructionism, which is innately linked to the idea of hard play.
I’ve come to realize that play has a critical role in developing new algorithms, or as I explored in the previous posts on modelling, problem solving in general. Early in this project, I would find sorting algorithms described rigidly in mathematical terms. What was hidden from me was the process by which these algorithms were developed. Like any math problem, tweaking the knobs to see what results is an important part of problem solving, especially if the problem appears intractable at the beginning.
Programmers are increasingly finding ways to play not just with the end result of an algorithm, but with the implementation. Code provides another material for play. As I touched on when exploring abstraction, Stanford has been holding code poetry slams for the past two years. The idea of using code to make creative expressions demonstrates the joy in pushing the limitations of languages intended for a specific use. As with many materials, the users quickly find ways to subvert the intended use and use it on other creative ways. Some code poetry is simply meant to be read, yet it still must compile, and in some cases, actually perform some task. Others, such as the ChucKu, add the additional restrictions of a haiku format, but require the poem to output a sound. These are ideal examples of how multiple modes (visual, audio, logical) can be used together when playing.
Hackerspaces, such as i3Detroit, are community-driven places that not only foster creativity, but also the related ability to innovate. In a previous class, I explored the relationship between creativity and innovation as seen in the graphic below. Two needed ingredients for innovation stood out to me when considering this space: resources and culture.
The initial appeal of these spaces is simply the space and tools available, both valuable resources. I joined while still living in an apartment, so some projects were simply not possible without a larger area to work within. i3Detroit is housed in a converted warehouse, with different zones such as the woodshop, electronics, welding, crafts, 3D printing and computing workplaces. Each zone is set up so that there is space for several people can collaborate and keep project materials within the area until the project is complete. For creativity to flow, barriers need to be removed, just educators try to do for their students. Tools such as laser cutter and 3D printers opened up new methods to complete projects and required developing new skills, such as becoming familiar with CAD software. The wealth of experiences that can be gained allows for new connections to be made.
To model is to gain a deep understanding of an object, a process, or idea by representing essential information by physical or virtual means. This can be done as a preliminary sketch in the act of creation, but it can also be used to represent knowledge that would otherwise be difficult to experience first-hand. Often modelling makes use of dimensional thinking, which is the translating or conceptualizing across dimensions of space, time, or any other range of related values (Root-Bernstein & Root-Bernstein, 1999).
Models of instructing computing machines to aid in problem solving have existed for over 150 years. When modelling a computer algorithm, I chose to explore its place across multiple sets of dimensions. The most obvious would be of scale and thus visibility,starting with that which can be viewed easily, such as the general solution to a problem and its implementation, then proceeded into that which is usually hidden , such as low level instructions, or microscopic in the case of transistors. This model also explores proceeding from the general to the specific, as implementing an algorithm is to use your own creativity in how to best do that, as my recipe analogy suggests. Parallel to this progression is starting with the virtual, such as an idea of how to accomplish a task, to the physical, with the actual tools being used to help complete that task.
If an algorithm is itself a model for understanding how to accomplish a task, the difficulty lies in creating a model to represent what is a model already, just as I found when trying to abstract an abstraction. Not surprisingly, the two skills of modelling and abstraction rely on each other, as a model is a useful abstraction. To accomplish this goal, I’ve decided to focus on the transition from algorithm to implementation, or in computing, creating a program based on an algorithm. Part of this process is accomplished by a person, the rest by a computer, so this lends itself well to computational thinking.
To gain a better understanding of how an algorithm is transformed into a program, I created a model that views this across physical scale, from the large to the very small; transitions from digital to physical; and demonstrates changes in logic, from the abstract to the specific. It elucidates what occurs behind the scenes when a program is executed, and shows how layers of abstraction in a computer provides human with the ability to intuitively instruct them.
As I found with many of the thinking skills for creativity presented in Sparks of Genius, algorithms and modelling are closely related. Composer Igor Stravinsky’s advice to an author encountering issues during the act of creation was to find a model, or “a predecessor what had already solved his type of narrative problem, then modify the solution to his own ends” (Root-Bernstein & Root-Bernstein, 1999, p. 230). This describes the role of an algorithm in general problem solving: an established solution to be used as reference for solving particular problems. Think of a recipe as an established way to create a dish; cooks may use it as a starting point and modify it provide their own personal interpretation. This reflects the idea idea that creativity is finding a “variation on a theme” (Henriksen, Mishra, & Deep-Play research group, 2014).
Algorithms lie on one end of the spectrum of problem solving techniques, where following step-by-step instructions can accomplish well-defined tasks, but most learning is much messier. We therefore often look for other, less rigid techniques while still keeping algorithms on hand as models of prior solutions. Moving along the spectrum into ill-defined tasks, heuristic approaches can lead to “good enough” solutions. This includes using “rules of thumb”, trial and error, and making educated guesses (Simon & Newell, 1958). On the opposite end of the spectrum lie solutions arrived at by chance. While these are by their nature unpredictable, they can be prepared for through diverse experiences and have led to discoveries ranging from penicillin to silly putty.
Much like other popular programming options for younger students such as Scratch and SNAP, Alice offers users the ability to create interactive scenes by combining blocks of code. While many of these graphical programming environments include elements of object oriented programming, Alice brings it to the forefront and is integral for effective programing of complex interactions. Unlike other popular options, Alice’s scenes are rendered in three dimensions and offers control over many details of the character models. This is both liberating and limiting, as it provides a wealth of options that younger students would likely find overwhelming.
Embodied thinking rejects the notion that the mind exists separately from the body, but instead recognizes that an awareness of all aspects of the human body, the exertion used in movement, emotional responses, tactile understanding, and gut instinct all play important roles in the act of creation. The related skill of empathy allows one to take the place of another, attempting to feel what they feel, even for an inanimate object, to gain insight into their state of being.
I chose to integrate embodied thinking as it relates to my topic of algorithms in a way that would best serve my end goal of creating an experience that would allow museum visitors understand programming in a relatable way. For that reason, I decided not to follow the well established path of creating a kinesthetic activity that allows learners to act out how data is manipulated in an algorithm, which was my first thought and I think of limited use. Instead, I created a stage show that uses multiple levels of embodied thinking.
Programming can be intimidating, but by allowing students and museum visitors to take on roles of characters engaged in computational thinking, they can gain an understanding of how an algorithm works in a visceral way. Visitors can not only view but also participate in a stage show where they can work alongside museum staff to act out a basic understanding of computer programs. During the play, characters will use motions to reinforce what each part of the algorithm does, further embodying the concept being learned.
Programmers solve problems. They accomplish this by working with or taking inspiration from computers to find solutions to problems, but they don’t do it alone. They have a set of thinking tools that will allow them to accomplish their tasks more easily called computational thinking. The play will explore different computational thinking skills as well as basic tools available to programmers. Even the play itself is an example of computational thinking, as actors are using a simulation to gain a better understanding of algorithms, just as a computer may be used to run a simulation to better understand a problem.