\section{Introduction}

Computational thinking~\cite{wing2006computational} is an important aspect of education, and programming is a primary method in order to teach it~\cite{lye2014review,geldreich2018off}. Establishing an elementary understanding of algorithmic thinking early on is important to successfully achieve computational thinking, but also to counter common preconceptions against programming and computer science that influence the gender imbalance later on~\cite{metz2007attracting,madill2007developing,steele1997threat,sullivan2013gender}. Programming is also increasingly used as an instrument to teach other topics. The best methods for teaching programming early on, however, are still being explored.

A common approach to introducing children to programming concepts is by using ``unplugged'' activities that require no computers~\cite{bell2009computer,faber2017teaching}, for example by letting the children impersonate robots executing sequences of instructions. A challenging next step is to transfer concepts learned with unplugged programming to programming with computers. Physical computing with programmable devices such as robots is a possible intermediary step, as they have a tangible, real-world impact through their actions~\cite{zaharija2013introducing,demo2008concrete}.
However, this requires schools to have access to appropriate hardware, and teachers need to have the confidence and knowledge to manage hardware devices and to support children in using them.



While computational thinking is already integrated into the curriculum in many countries from the earliest stages on, German and Austrian\xspace primary schools currently do not touch upon the topic. In an endeavour to help local primary schools with the introduction of programming concepts, we therefore visited eight primary schools from October 2018 to October 2019. During these school visits, we used the Ozobot Evo\footnote{https://ozobot.com/} programmable
robots in two-hour workshops. Ozobots are small programmable robots for which
initial experience reports are generally
positive~\cite{fojtik2017ozobot,van2018best,vzavcek2019development}.
The Ozobots have several advantages: They bridge the gap between unplugged
programming and physical programming, as they can be programmed with pen and
paper as well as on a tablet or desktop computer; they are very small and
portable, and can easily be moved from one school to another;
the programming environment is very flexible and the level of difficulty can be adapted from pre-reading stage up to complex
programming concepts.


In this paper, we describe the workshop format we developed for our outreach activity, and share our experience of interacting with children, teachers, and Ozobots.
Overall, the children were enthusiastic as one would expect, both when interacting with pen and paper as well as with tablet computers. The Ozobots proved to be better suited for their pen-and-paper mode than programming with a tablet computer.



\section{The Ozobot Evo Robot}



Figure~\ref{fig:bot} shows an Ozobot Evo robot. The robot can make sounds, has multiple lights that can flash in different colours, and it can move. It has sensors to detect the colour of the surface it is driving on, and proximity sensors facing to the front and back.


\begin{figure}[t]
	\centering
    \vspace{2em}
	\includegraphics[width=0.7\columnwidth]{ozobot_hand}
	\caption{\label{fig:bot}The Ozobot Evo robot: Small, easy to handle, with a soft plastic cover that makes it sturdy. The colourful fingers of the child in the picture are a common result of the pen-and-paper mode of interaction.}
\end{figure}

\begin{figure}[t]
	\centering
	\includegraphics[width=0.7\columnwidth]{action}
	\caption{\label{fig:malen}Ozobot robot moving along a line with embedded colour codes. In this example, green-blue-red increases the counter by one (the symmetric colour sequence red-blue-green decreases the counter).}
\end{figure}


\begin{figure}[t]
	\centering
	\includegraphics[width=0.7\columnwidth]{ozoblockly}
	\caption{\label{fig:ozoblockly}The OzoBlockly programming environment in a web browser: Categories of blocks are shown on the left, and clicking on a category opens a drawer of blocks available. At level 1 (``Pre-Reader'') only a few blocks are shown, but many more blocks are available at increasing levels.}
\end{figure}


There are two main ways of interacting with an Ozobot: In the line-following mode, the robot follows coloured lines it senses with its bottom sensors. While doing so, it changes its lights based on the colour of the line it is following. Lines may contain special colour sequences, which represent commands (e.g., turn left, turn right, go fast, dance, etc.) Figure~\ref{fig:malen} shows an example of the robot following a line while increasing a counter. The main categories of commands are related to speed (from snail dose to nitro boost), special moves (spinning, zigzagging, etc.), directional movement (turning, jumping lines, u-turns, etc.), counters (e.g., counting colours, counting crossings, increasing/decreasing counters), timers, and commands to indicate success or completion of a task\footnote{https://play.ozobot.com/print/guides/ozobot-ozocodes-reference.pdf, last accessed March 15, 2020}.

Ozobots can also be programmed via the OzoBlockly app\footnote{https://ozoblockly.com/, last accessed March 15, 2020} (Figure~\ref{fig:ozoblockly}). The programming environment follows the standard block-based approach with a toolbox of different categories of blocks on the left hand side of the screen.  OzoBlockly supports five different levels, where in the easiest level blocks are purely graphical with icons and only a few numbers instead of text, so that programming can be done even at pre-reading stages. The basic commands are reminiscent of the Logo~\cite{logo} programming approach, and mainly control the movement of the robots. At the highest level, the programming language supports even complex constructs such as functions with return values. OzoBlockly programs can be transferred to the robots by ``flashing'', which means holding the robot face down on the screen while the program is transferred by a colour sequence. When using a tablet rather than a desktop computer, the Ozobot Evo can also be controlled via an app and a bluetooth connection. The app contains not only OzoBlockly, but also various functionalities such as a remote control. The bluetooth connectivity is one of the central differences between the Ozobot Evo robot and the cheaper variant, the Ozobot Bit: The Ozobot app to program robots using a tablet computer can currently only be used with the Evo, while programming the Bit always requires flashing programs, and thus a web browser for operation\footnote{There is a separate app for the Bit which is focused on the line-following mode.}.






\section{Programming Workshop Format}

Our outreach activity was organised in the form of two-hour workshops at the primary schools, targeting children in grades 3--5. We visited eight schools between October 2018 and October 2019. Each workshop was supervised by 2--4 project participants, and the class sizes were around 20--25 students (sometimes covering two classes at once). 
In this section, we describe the sequence of activities conducted at the workshops. These activities are based on a selection of teaching material found in the large collection available online\footnote{https://ozobot.com/educate/lessons, last accessed March 16, 2020} as well as our own ideas.

\subsection{Activity 1: Getting to Know the Ozobots}

After a brief introduction of the organisers, we discussed with the children what a robot is, what robots they know, and how they look like. Typically, they expected robots to be large and humanoid. Then, we handed Ozobots to them (one robot for two children). As initial activity, we asked the children to find out what equipment and capabilities the robot has, and how to turn it on. After a while, we let the children tell us what they had discovered and wrote down the correct suggestions on the blackboard. This activity proved to be helpful in order to set realistic expectations, for example, the robots do not have elastic springs and therefore are not able to jump (which was particularly useful to understand for when the children were later introduced to ``line jumping'' commands, which refer only to switching from lines to follow rather than physical jumping). Ozobots have a single button that is not entirely obvious and took the kids a while to find. They discovered the wheels and the USB charging port quickly, and once they had managed to turn on the robot, they discovered the lights and sounds the robot can produce. The proximity and colour sensors are not obvious and needed some explaining; this immediately lead to the second activity.


\subsection{Activity 2: Line-Following}

To explain how the robot uses the colour sensor, we handed out the first worksheet\footnote{https://storage.googleapis.com/ozobot-lesson-library/3-5-basic-training-color-codes/3-5-Basic-Training-Color-Codes-full-version.pdf, p. 24, last accessed March 16, 2020}, which consists of a black line with gaps in it. The children received coloured pens and were asked to fill the gaps and observe how the robots behave. There were two learning objectives: First, the children were supposed to discover that the Ozobot follows lines, and while doing so, the lights glow in the colour that the colour sensor detects (white instead of black, as only exception). Second, the children got a feeling of how thick the lines have to be so that the robot can detect them. The first worksheet was followed by a second one\footnote{Ibid., p. 25} that also consists of lines with gaps, but this time the gaps are intentionally located at corners and bends in order to practice drawing appropriate lines the robot can follow. Children that completed the task quicker than others were allowed to use the time for extending the lines or drawing their own lines on the back side of the paper.

\subsection{Activity 3: Introduction to Commands}

Before starting the third activity, we discussed the experience of the second activity with the students to make sure everyone had noticed how the colour sensor works. This lead to the third activity, which is concerned with how the colour sensors can be used to control the robots. To introduce the children to this concept, the third handout\footnote{Ibid., p. 26} contains a circular line with two gaps, and two colour codes that the children need to draw into the gaps. Once the children had had some time to try out these codes, we discussed with them how the two codes caused the robots to behave. Each code consists of a sequence of three colours; in this first example, both codes are symmetric, so that the robot behaves identical regardless of the direction in which it traverses the code. With the fourth handout\footnote{Ibid., p. 27}, the children again received a line with two gaps and two corresponding codes, but this time only one code is symmetric, while the second one has a different effect depending on the direction of traversal (in one direction it slows the robot down, in the other it accelerates it). Again, we discussed this with the children after they had experimented with the handout.


\subsection{Activity 4: Discovering Randomness}

The fifth handout\footnote{Ibid., p. 28} consists of two basically equal paths, each containing a crossing which leads to three different colours; in the second path, there is a gap for inserting a command. As first activity, we tasked the children to conduct an experiment where they start their robot ten times on the first path, and keep track of how often the robot moves to each of the colours. Once completed, we collected the data on the blackboard, to see which colour was targeted most of the times (to simplify the counting, we only asked each child or pair of children which colour was visited most frequently). Since the Ozobot makes a random choice at a crossing unless instructed otherwise, the result is different every time. After explaining that the robot chooses randomly, we handed out tables with the main colour codes that the Ozobot can handle%
, and turned to the second path on the handout. After explaining the different commands on the command table, we chose an arbitrary colour (usually the one that was least frequently visited during the previous experiment) and then tasked the children to select and draw a command that will make the robot go to that colour every time.

\subsection{Activity 5: Controlling the Robot}

At this point, the children had an understanding of the capabilities and the behaviour of the robots and they knew how to use colour codes as well as which commands the robot can understand. We thus handed out a challenge, chosen from the many available tasks on the Ozobot website. In these challenges, there typically is a scenario (e.g., the road from home to school\footnote{Ibid., p. 29}) with a clear objective (e.g., get the robot from home to school) and many obstacles that require the use of colour codes (e.g., dead ends, road works, etc.) Solving such a challenge sometimes took a while, and it was useful to be prepared to handle mistakes (either by handing out a new sheet, or by using white stickers to cover incorrect commands). Children who completed the task earlier than others were allowed to create their own racetrack on the back of the handout.


\subsection{Activity 6: Introduction to Programming}

The next activity was the transition from pen-and-paper commands to sending commands via programming. This activity was done without robots (we tried to use this time for recharging the robots a bit). We discussed the general concept of sequences with the children, and introduced the commands in the OzoBlockly format using large paper printouts\footnote{https://storage.googleapis.com/ozobot-lesson-library/ozoblockly-training-k-1/ozoblockly-training-k-1.pdf, pp. 14-20, last accessed March 16, 2020} of the easiest OzoBlockly level, which consists of graphical blocks. Using these printouts, we focused on the computational thinking concept of \emph{sequences}~\cite{brennan2012new}: We pinned sequences of commands on the black board, and then asked the children to execute the programs (which typically consisted of walking, turning, and making happy/sad faces). While one child executed the program, the other children were tasked to judge if the execution was correct or not. Finally, we demonstrated the OzoBlockly app on a tablet computer, showing how the same commands can be arranged in sequences there.


\subsection{Activity 7: Programming the Ozobots}

In the final activity, each pair of children was given a tablet computer (and a recharged Ozobot, if necessary). We explained how to connect the tablet computer to the robot via bluetooth, and how to use the OzoBlockly app. Then, we gave the children a handout consisting of the first coding challenge\footnote{Ibid., p. 13}. We used the Ozobot challenge where the robot has to go from the start position to its room in its house, and pre-loaded the OzoBlockly app with an incorrect implementation of the sequence of instructions, leading to the robot erroneously ending up in the forest. The task for the children was to correct the program so that the robot successfully walks to its home. Consequently, the main computational thinking concept reinforced by this activity is again \emph{sequences}, as well as the computational thinking practice~\cite{brennan2012new} of \emph{testing and debugging}. Once the task was completed, the children were given the chance to get creative at producing an exciting program. Over the course of the workshops, we refined this activity to the task of programming the Ozobot to perform a dance.

\begin{figure}[t]
	\centering
	\subfigure[Incorrect program (starting point)]{
	\begin{minipage}[t]{0.45\columnwidth}
	\centering
	\includegraphics[scale=0.2]{programming_task1}
	\end{minipage}
	}
	\hfill
	\subfigure[Expected correct solution ]{
	\begin{minipage}[t]{0.45\columnwidth}
	\centering
	\includegraphics[scale=0.2]{programming_task1_solution}
	\end{minipage}
	}
	\\
	\subfigure[A workshop participant conducting the programming activity]{\includegraphics[width=0.8\columnwidth]{programming_task1_katharina}}
	\caption{The first OzoBlockly programming task we used in our workshops: The task is to let the robot move home safely. The starting point is an incorrect program that erroneously moves the robots to the forest. The correct solution requires reordering the rotation instructions as well as replacing the emotion command at the end.}
\end{figure}

\begin{figure}[t]
	\centering
	\includegraphics[width=0.8\columnwidth]{programming_task2}
	\caption{\label{fig:dancing}The Dancing on Ice activity: Two teams of children each programmed a Ozobot robot to perform a joined dance routine. One of the Ozobots is decorated with a unicorn skin.}
\end{figure}


\section{Additional Activities}




\subsection{Programming Olympic Games}

In addition to the school workshops we organised an  event themed as ``Programming Olympic Games'', where we invited four of the classes previously visited during workshops to the University of Passau\xspace. Within two days, the students were able to demonstrate their skills acquired in the workshops and competed against each other in four ``Olympic disciplines''.

The prime discipline was the \textit{Ozobot on Ice} activity. The children were
given 20 minutes to rehearse a choreography for two Ozobots performing a pair
dance on ice. As can be seen in Figure~\ref{fig:dancing}, the children used
OzoBlockly for this. Some of the criteria for evaluation
included the synchronicity of the two Ozobos and whether they moved within the
ice rink or surpassed the line.

We further included two disciplines using BeeBots, which are programmed with buttons with arrows for each direction and a go, cancel and stop button, located on the back of the robots. The BeeBots move in 15cm-steps and usually, they are used with BeeBot mats which display a grid to facilitate the navigation. The user interface only supports sequences of commands to be programmed, which matches what all children had learned during the workshops. The children had no problems in applying their Ozobot experience to the BeeBots. We used BeeBots for two activities: In the \textit{Rallye Dakar with BeeBots} children had to navigate the BeeBots along a racetrack using their sequencing skills, by entering the right commands into the robot so that the BeeBot reaches the finish line of the racetrack in one pass. In \textit{BeeBot Bowling} no BeeBot mat was used and so the children had to correctly estimate distances. The goal of this game was to enter as many commands that are needed for the BeeBot to knock over the cones (empty plastic bottles). 








\subsection{Ozobots in CoderDojos}

Independently of the project underlying this experience report, we organise a CoderDojo\footnote{https://coderdojo.com/} at the University of Passau\xspace at regular intervals. In the two-hour programming club young programmers aged 8 to 18 voluntarily come together to learn programming and have fun. The children usually work on their individual projects by themselves, with mentors always available to help them with their problems. Some of the children wanted to work with the Ozobots. The workshop format we had developed works well with classes where everyone works on the same project, but in our experience it did not work well in the CoderDojo setting. Introducing Ozobots required one of the instructors to be present all the time, as we had not prepared any tutorials in German and the more complex blocks require a level of English skills which not all of the children had. Some of them ended up having fun with the remote control 
instead of programming the robots.

\subsection{Unsuccessful Activity}

With one of the classes we tried the ``Modeling animal habits'' lesson\footnote{https://portal.ozobot.com/lessons/detail/modeling-animal-habits, last accessed March 16, 2020}. After introducing the concept of point-counter colour codes using one line without crossings as depicted in Figure~\ref{fig:malen}, we gave the children the handout consisting of a map of crossing lines with empty spaces for colour codes. The task was to use point-counter colour codes and let the Ozobot count from five to zero points, taking into account the non-orthogonal design of the crossings and which route the Ozobot will most likely take. The children understood the task well and filled the map with suitable colour codes. After counting from five to zero, the robot is supposed to stop and blink red. However, not in all cases it did, even though the solution of the children was correct and the robot had passed the required amount of colour codes in the right order. As this lack of instant positive feedback disappointed the children and explaining the point counter colour codes was time-consuming, we did not repeat this exercise in successive workshops.

\section{Lessons Learned}


\paragraph{\bf Pen-and-Paper Drawing.} The children are fascinated with drawing creative patterns for the robots to follow with the Ozobot markers (which can be replaced with regular markers once they are out of colour). When producing handouts or using other paper, make sure not to use standard printer paper but thicker paper, otherwise the desks will be coloured.

\paragraph{\bf Pen-and-Paper Tasks.} When given tasks where children have to fill in colour codes, mistakes will be made. It is important to either have white stickers to allow corrections, or to have spare copies of the handouts. In the worst case, a reasonable workaround is to draw detour lines to allow the Ozobots to bypass erroneous solutions.

\paragraph{\bf Programming with OzoBlockly.}
Programming the robots with OzoBlockly worked well as the icons are self-explanatory and the students intuitively understood how to drag and drop blocks. Once the complexity and length of programs increased, it turned out that deleting blocks was less self-explanatory and often needed explicit instruction. In Scratch~\cite{maloney2010}, hat blocks can be used to specify at which point in time a sequence of blocks, a \textit{script}, is executed. OzoBlockly does not have such event handler blocks and in combination with scripts which were not deleted, this led to unexpected robot behaviour, as the order and number of scripts executed is unclear when more than one script is present in the editor.

\paragraph{\bf Understanding the Repeatable Nature of Programs.}
Some of the children did not intuitively understand the repeatable nature of programs. In Activity 7, the task was to get the robot from a fixed starting point to the house. Some of the children tried to use the editor as remote control by running several different programs until eventually the robot reached the goal from wherever it stopped after execution of the previous program. When moving the robot back to the fixed starting point and running the current program again, the robot did not reach the house. After explicitly hinting at the goal to write one coherent, repeatable program with the robot starting from the fixed starting point, the children usually got it right quickly. When using BeeBots at the Olympic Games, the same misunderstanding happened, but again the children understood well after additional explanations.

\paragraph{\bf Correct Programs Appearing Erroneous.}
In Activity~7, sometimes the execution of a program did not succeed even though the program was correct. The reason was that in consecutive executions the robot usually did not have the exact same direction at the starting point, therefore ending at a slightly different position at every execution. However, as soon as the children had understood, they could differentiate between the usual small deviation present even for correct programs and programs which were indeed erroneous, leading to the robot obviously missing the end point.

\paragraph{\bf Complexity of Programs.}
Using the pen-and-paper mode made it easy for the children to understand how to use colour codes to program the robots. As in Activity~4 they already had to think about the temporal interplay of commands, the transition from drawing to programming with commands seemed quite easy for them. However, due to the limited amount of time, the complexity of the programs the children created with the OzoBlockly editor was limited. Most of the time, we did not introduce loops or conditionals. In the cases where we did, the children had created very long scripts with repeating blocks and were happy and eager to learn about a better solution for their code.

\paragraph{\bf Labeling Robots.} It is helpful to name all the robots, and to add stickers with their names to them. Not only for matching tablet computers with robots and connecting via bluetooth the name labels are true life savers, the children also identify much stronger with their robots if they have names. We used two different sets of robots, one set with robots being labeled with numbers, and the other set with robots having real names such as ``Fred'', ``Lena'' or ``Bobo'', and in every class the favourites were the ones with names.

\paragraph{\bf Remote Control.} In some of the classes we demonstrated that the robots can be controlled using the remote control functionality in the OzoBlockly app. As it is easier and apparently more fun to use the joystick than to create programs, some children started playing with the robots rather than programming them. We recommend to hide the remote control functionality and hope that the children do not discover it themselves. If they do so, one has to try to convince the children not to use it. For example, you can tell them that they miss out on practicing to be a cool programmer when only playing with a toy that even toddlers can handle.

\paragraph{\bf Bluetooth Kills Battery Life.} While Ozobots can easily survive 90 minutes following lines, the bluetooth connection seems to drain batteries extremely quickly. We found it necessary to recharge robots before switching from drawing mode to programming mode, and even then do the robots not last very long. Thus, we also recommend to turn off Ozobots during phases of discussion or instruction, and to plan for breaks where the robots can be recharged. Ideally, having spare robots to replace robots with dead battery is helpful.

\paragraph{\bf Preparing Programs for Students.} The erroneous programs used for Activity 7 had to be created manually on every tablet computer, which was a time-consuming process. We strongly recommend to try the newly launched Ozobot classroom platform\footnote{https://ozobot.com/educate/classroom, last accessed March 16, 2020} as it claims to solve this problem. We have not tried it yet because it was launched after the end of our outreach activities. As an alternative, one can let the students copy the erroneous code, which is also printed on the handout, into the OzoBlockly editor themselves. This way, the tablets do not have to be prepared in advance, and the students can practice drag-and-dropping the blocks without having to think about the code they want to write.

\paragraph{\bf Pairing Robots and Tablets.} It is officially recommended that each tablet computer is matched with exactly one robot. We found this not to be a viable solution since robots run out of battery too quickly when connected via bluetooth. However, when connecting different robots and tablet computers, it frequently happens that the app refuses to control the robot until it has been ``updated'' -- even if the robot is already completely up to date. Performing such an update requires a working internet connection, which may not be available during outreach activities. Also, both duration and success of these updates were rather non-deterministic, which led to some robots not being usable with tablets at all. The Ozobot support was not able to recommend an alternative at the time we contacted them. Another problem which occurred repeatedly was that an already connected robot was not available in the editor of the tablet computer. Our solution to cope with this bug was to exit the editor and then open it again.

\paragraph{\bf Checking Which Codes Are Needed.}
The colour code reference sheet we used in our workshops (the English basic version\footnote{https://files.ozobot.com/stem-education/ozobot-ozocodes-reference.pdf, p. 1, last accessed March 19, 2020}) does not include the code for ``pause'', even though this is needed for Activity 5. Also, the codes for the counters needed in the ``Modeling animal habits'' lesson are not included on the basic sheet. We chose to draw the missing codes on the blackboard. As an alternative, one can use the more detailed sheet\footnote{Ibid., p. 2}, but it might be easier for the students to orient themselves when having less codes to look at. A German version of the colour code reference sheet\footnote{https://drive.google.com/file/d/19UBAsQ2\_SEXBaZJgfbIxD8gH-lgTYkfh/view, last accessed March 19, 2020} has been released after our activities. In any case, we recommend checking which codes are supposed to be used for the activities planned, so that one can provide the students with the information they need.

\paragraph{\bf Language Barriers.} The OzoBlockly app supports several languages, but the set of languages available is very limited. One of the reasons why we used the pre-reader level for the introduction was indeed that German is not a supported language. Although we contacted the Ozobot company, their response was that additional languages will be added only once there has been sufficient demand. At the time of this writing, apparently this has not been the case for German, but we hope that this will change in due time.

\paragraph{\bf Preconceptions against Programming.}
Overall, most of the children were excited to work with  robots, and for both boys and girls, being good at programming was something worth striving for. Girls who did a good job at programming were happy to receive positive feedback and be called good programmers. We did not recognise any gender-specific preconceptions against programming or computer science, and boys and girls were particularly fascinated by one of the robots which we decorated with a unicorn skin (Figure~\ref{fig:dancing}).



\section{Conclusions}

Introducing children to programming concepts at primary school level aims at fostering computational thinking skills and overcoming preconceptions and gender imbalance. In order to support this endeavour, we organised programming workshops  at local schools. Due to their size and functionality the Ozobot robots turned out to be well suited for this task. Despite some challenges such as battery life, on the whole our experience was overwhelmingly positive.


Our workshops so far were limited to two hours, and thus only allowed us to teach basic programming concepts; in most cases we covered no more than sequences. 
A particular feature of Ozobot robots is their dual mode of operation in a pen-and-paper mode as well as block-based programming mode. In our experience the pen-and-paper mode is a great way to introduce children to the abilities of the robots, and to build up enthusiasm for robots in general. 
While the relevance of the initial activities in pen-and-paper mode with respect to computer science learning taxonomies~\cite{fuller2007developing} can clearly be argued, it remains unclear whether the concrete skills learned during this mode of operation support the subsequent learning of more advanced concepts related to programming.

Therefore, as a next step we would like to explore the use of Ozobot robots when continuing with introducing further concepts and gradually progressing learners to more advanced programming. With each of the five levels in the OzoBlockly app the complexity increases, and the top level seems equally well suited for older learners. Due to the possibility of viewing a JavaScript representation of OzoBlockly programs, it is even conceivable to use Ozobots throughout the learning process, up to text-based programming.

\section*{Acknowledgements}
This work was supported by Kleinprojekt NB-23 ``Grenzüberschreitende Förderung der Informatikbildung'' funded by the \\ INTERREG-Programm Österreich-Bayern 2014--2020.

\balance
\bibliographystyle{ACM-Reference-Format}


