Header from https://www.gorillasun.de/
Today's workshop began with a brainstorming question about "what is computational thinking?". There were many answers given regarding decomposing a problem into simpler ones and solving the subproblems, trying to think like a computer does.
Overall, a well-rounded answer to that question would be:
Computational thinking is a way of problem-solving where the solution can be represented with computational software and algorithms.
Below the definition is given for clarity, and then the activities of the workshop are analyzed. Overall, the main goal of this workshop was to explore visual programming environments and then create our own artefacts with a blockly-based environment.
According to Wikipedia, Computational thinking (CT) refers to the thought processes involved in formulating problems so their solutions can be represented as computational steps and algorithms. In education, CT is a set of problem-solving methods that involve expressing problems and their solutions in ways that a computer could also execute. It involves automation of processes, but also using computing to explore, analyze, and understand processes (natural and artificial).
Blockly is the library behind many well-known block-based coding platforms, such as Scratch or Microsoft MakeCode Editor.
I wasn't aware of Blockly and I was happy to see that it is open-source. This made a great idea flow come to my head, especially with Scratch Blocks about experimenting and (why not?) try to make a mini block-based environment myself!
Your task is to choose one Blockly-based programming tool and create programmable content that the tool supports. The content can be animations, games, phone apps or just doing tasks as instructed.
NOTE! Use AI as a guide when thinking about how to use the tool. Below are some sample prompts:
Example 1: "Ask me three programming skills questions for a primary school age child. Always wait for my answer. I will use the code.org tools and I hope you will support me based on the questions you ask."
Example 2: "My task is to program an animation in Scratch. My experience is limited. HELP"
Example 3: "I want to create something using xxxx tool. Could you give me ideas on what content I can create using xxx."
From the available tools, I chose MIT App Inventor to create my mini application. I had never worked with that tool before and I wanted to explore its functionalities.
The idea of the mini app was that it was meant to be an assistive app for people with speaking difficulties and/or other disabilities when they are inside the classroom.
My thought process was that I wanted to create something useful but feasible. I asked Claude for an idea that would be helpful to people with disabilities and combined the results with some of my own additions. You can read the full conversation with Claude here.
The application has 5 buttons with small phrases that express common needs that students have inside the classrooms. When pressed, they trigger a text to speech, so a voice is created for the student.
I tried to make the application accessible using high-contrast in colors and the text-to-speech functionality.
Here is the link: https://gallery.appinventor.mit.edu/?galleryid=30c72bce-d581-4ccd-b0f3-52c7be1c62f3
Reflect on your own learning experience in graphical programming (e.g. using block-based programming environments such as Scratch). Answer the following questions:
"How has graphical programming helped you to break down complex problems into smaller parts? Give a concrete example of a situation where you used programming to solve a problem. What did you learn from this experience?"
My first experience with graphical programming was in lower secondary school when we used the turtle logo environment in Informatics class.
Aside from that, my learning experience was inverse because I first learned text-based programming in my bachelors degree and then towards the end of it, I experimented with graphical programming, first as a learner and afterwards, as a teacher.
The transition from a text-based to a visual way of programming, even though a common assumption would be that it is much easier than the opposite, I can say was also quite challenging at first. I believe it is very common whilst coding, especially in large projects, that you are not completely aware of what you are doing,or it might get to this brain-frying point where you are debugging for many hours and then suddenly something works and you have no idea why it does. On the other hand, in visual programming in my opinion you are kind of "forced" to understand the logic behind a solution, which sometimes makes it challenging to put together! I remember having a (not huge, but noteworthy) learning curve when I first got involved in Scratch, even though I had experience in all kinds of programming concepts like variables, functions, etc. It was just a very different way of thinking and of going about solving a problem which needed some adjustment from my part.
A concrete example of a situation where I used graphical programming for problem-solving is this:
Towards the end of my bachelors degree, I had taken upon a course called Computer Music. Our evaluation for that course was based solely on a group project that we had to design and implement. The topic was at our discretion, the only prerequisite was that it had to be relevant to music (and computers).
My team decided upon creating a tool that would take a text file as input and, through algorithmic processing, would output music. For that purpose, we used a visual programming language called Pure Data.
At a first glance, this was a very primitive software, offering basically nothing but a few buttons as an interface.
However, thinking about it retrospectively, this project and this software made me search for information more than most projects I had been involved in until that point, and the problem-solving process was overall like a game of connecting the dots. It included a lot of trial-and-error, almost deafness from unwanted sounds produced directly into my headphones, but overall it was very engaging and it helped me visualize the input->process->output system step-by-step and decompose the problem.
This patch "reads" each line of a text file iteratively (in our case this file had been preprocessed to include ASCII values) and extracts them as separate message boxes into another patch.
This patch implements a text to speech functionality with added effects on the voice like echo and reverb.
"How have you managed your own learning process during the graphical programming process? For example, how do you monitor your progress and make corrections when you notice errors in your program? How do you feel that the programming tool helps you to do this?"
In my own learning experience, I used consistent testing as a method of keeping up with my progress and adjusting my strategies. Again, in comparison to text-based programming, I would say that visual programming tools are very helpful for activating SRL processes such as monitoring and control, because visualizing the steps towards the solution gets much easier, as well as predicting the outcome of a command because you are visualizing the movement of an animated character. In text-based editors correspondingly, there are debugging tools which are really helpful for monitoring the problem-solving progress, but again, in larger projects it is common that a person might be writing a large block of code all at once without testing it, therefore those same SRL processes might not be activated immediately,and the errors that appear afterwards might not be that obvious to "catch" and fix.
"Have you ever had moments when you found graphical programming tasks particularly difficult? How have you managed to stay motivated and keep going? How has receiving feedback on the program (e.g. error messages or malfunctioning algorithms) affected your motivation?"
I believe that the times that I've found graphical programming tasks difficult were simultaneously the times where the task was very uninteresting. Having a visual environment does not necessarily assist in the learning process more than an unplugged or text-based environment. However,one more specific moment was in my first interactions with Scratch. I remember being very frustrated because I couldn't figure out the movement of the cat (the animated character that you're programming). Specifically I remember running the commands in my head and visualizing the movement, and then running the code and it doing something completely different,with usually the cat ending up being upside down. I think it was especially frustrating because of SR and metacognitive processes that I was activating at that time in the Forethought Phase (Zimmerman, 2002), in which I had evaluated this task as an easy task for people with novice programming skills and I put myself on a higher level, but then failed to make it work.
As for receiving feedback from graphical programming environments, personally I cannot recall times where made a big difference to my level of motivation. If the feedback I was getting was constructive or included hints then it might had impacted me positively to continue working on the task because I felt that I had some sort of guidance but it would not significantly raise my motivation.
"How do you think the problem-solving and self-regulation skills you have learned through graphical programming can benefit you in the future, for example in other subjects or in life in general?"
For me, working on graphical programming environments and practicing my problem-solving skills had a very positive impact on my confidence as a teacher in STEM education. Before that, even though I had programming experience I felt anxious when kids had questions regarding the coding blocks because I hadn't understood the visual programming logic well myself. After having worked on visual programming for a while, I felt that my viewpoint had expanded and I was more comfortable in facilitating activities in such environments but also explaining programming concepts effectively (e.g loops) to kids using the platform itself and scenarios based on it.
As for the self-regulation skills, now I'm slowly realizing what SR processes I was activating at the time that I was working on graphical programming. I think I'm at a very initial stage yet that I cannot transfer this acquired knowledge to other situations because I'm still gaining awareness around it, after having recently explored the theoretical foundations of SRL.
Zimmerman, B. J. (2002). Becoming a Self-Regulated Learner: An Overview. Theory into Practice, 41, 64-70. http://dx.doi.org/10.1207/s15430421tip4102_2