Conference PaperPDF Available

XLogoOnline: A Single-Page, Browser-Based Programming Environment for Schools Aiming at Reducing Cognitive Load on Pupils


Abstract and Figures

For more than twelve years, our chair has been introducing primary school children to algorithmic thinking by teaching them how to program in Logo. The key element of the proposed didactic approach consists in reducing the extraneous cognitive load on the pupils. We developed and stepwise refined the required teaching materials that allow for introducing only a few instructions in a programming language, which is gradually extended simply relying on modular design. XLogoOnline is our new browser-based, single-page programming environment for schools which is perfectly attuned to our curriculum. We argue that the platform reduces the extraneous cognitive load on the pupils thanks to a heavily-simplified workflow, appropriate for young children, and present evaluations that confirm high usability and acceptance across ages.
Content may be subject to copyright.
XLogoOnline: A Single-Page, Browser-Based
Programming Environment for Schools aiming
at Reducing Cognitive Load on Pupils
Juraj Hromkovič1, Giovanni Serafini1, and Jacqueline Staub1,2
1Department of Computer Science, ETH Zürich
Universitätstrasse 6, 8092 Zürich, Switzerland
2Pädagogische Hochschule Graubünden
Scalärstrasse 17, 7000 Chur, Switzerland
For more than twelve years, our chair has been introducing
primary school children to algorithmic thinking by teaching them how
to program in Logo. The key element of the proposed didactic approach
consists in reducing the extraneous cognitive load on the pupils. We
developed and stepwise refined the required teaching materials that allow
for introducing only a few instructions in a programming language, which
is gradually extended simply relying on modular design. XLogoOnline
is our new browser-based, single-page programming environment for
schools which is perfectly attuned to our curriculum. We argue that the
platform reduces the extraneous cognitive load on the pupils thanks to a
heavily-simplified workflow, appropriate for young children, and present
evaluations that confirm high usability and acceptance across ages.
1 Introduction
It is crucial that young pupils leave school not only as passive users of com-
puters but also with the ability to think algorithmically and solve problems
by programming. This form of learning is constructive, enriches creativity and
teaches precision but is strenuous and demanding by its very nature. In this
work, we reflect on the difficulties children encounter while learning to program
and introduce our two-pronged approach of a programming environment and
curriculum as technical and didactic solutions to reduce cognitive load on novice
1.1 At long last, Computer Science in Swiss Schools
Research and development of programming concepts and languages have a long
and rich academic tradition in Switzerland. Pascal, Modula-2, and later Oberon
were conceived by Swiss computer science pioneer and Turing-award recipient
Niklaus Wirth, with his main objectives being that university students are
introduced to programming using modern and didactically appropriate teaching
It may seem paradoxical, however, that Switzerland is still debating about the
opportunity to introduce computer science as a mandatory subject at primary,
lower and higher secondary school. While the German speaking part of the
country slowly seems to agree on computer science for all children up to 15 years,
the so-called “Plan d’étude Romand” in the French part of the confederation still
completely neglects computer science [
]. At present, higher secondary school
students all around the country are allowed to choose computer science as an
optional subject, usually in the last year of the curriculum. The Swiss Conference
of Cantonal Ministers of Education is finally considering to introduce Computer
Science as a compulsory subject at higher secondary school. For the ongoing
debates a decision is expected for October 2017.
For more than twelve years, our chair at ETH Zurich – together with several
regional partners, among them Pädagogische Hochschule Graubünden [
] and
University of Basel – have been conducting projects introducing primary school
children and their teachers to programming in Logo [
] using our didactic
approach. In the last two years, in the greater area of Basel alone, 96 primary
school classes (1862 pupils) and their teachers were taught how to program using
our teaching materials. Currently, we are even active outside the Swiss borders
and are introducing 8 primary school classes (141 pupils and their teachers) to
programming in the Principality of Liechtenstein.
In the rest of this paper we present XLogoOnline, our new browser-based pro-
gramming environment for introducing primary school children to programming.
1.2 Organization of the Paper
In Section 2, we reflect on the contribution of programming on algorithmic
thinking with a focus on preserving pupils’ working memory. In Sections 3
and 4, we highlight technical and didactic design principles of our curriculum
before honing in on implementation details of XLogoOnline. Section 5introduces
objectives, setup and results of three experiments after which we finally summarize
the key insights of the paper in Section 6.
2 Algorithmic Thinking and Cognitive Load
We consider the expressions algorithmic thinking and computational thinking as
two equivalent and interchangeable ways to state the same concept [
]. Knuth
already reflected 30 years before Wing about the relations between algorithmic
thinking and mathematical thinking, and informally described algorithmic thinking
as his “perception of the most typical thought processes used by a computer
scientist”. Aho captured the nature of algorithmic thinking as follows: “We
consider computational thinking to be the thought process involved in formulating
problems so their solutions can be represented as computational steps and
algorithms” [
]. Irrespective of whether we refer to it in one way or another, we
believe that computer science should be introduced at school “as an independent
scientific subject” and that it should be “studied both for its intrinsic intellectual
and educational value and for its applications to other disciplines” [2].
2.1 Programming is a Key to Algorithmic Thinking
Following the definition of Aho, we are firmly convinced that learning how to
develop well-structured programs is a key element to mastering algorithmic
thinking, and an ideal way to experience scientific methods at an appropriate
level of abstraction. In our curriculum, pupils first learn to write small pieces of
code, which then are tested and revised for improvement. We mainly focus on
programming-in-the-small and the curriculum trains pupils to implicitly formulate
a hypothesis (write a program to solve a given problem), verify their hypothesis
(run and test the program), and successively refine the hypothesis as necessary.
Modular design is both a technique to develop well-structured programs and
an overall problem solving strategy that can be used to tackle any complex tasks,
even outside of computer science. In our programming classes, pupils are explicitly
taught to seek geometric figures for repetitive patterns. They rapidly discover
the advantages of programming and naming such small bite-size elements, and
of reusing them in a proper modular fashion. The pupils learn to successively
decompose problems into smaller tasks which are each solved independently, and
finally reassembled to solve the original assignment.
Learning to program is generally considered to be a complex cognitive activity.
In our didactic approach, programming-in-the-small and modular design require
the pupils to organize their programs into conceptually independent units. This
modularization process is core to teaching computer science: First, it helps to
approach challenging problems by breaking them down into smaller tasks, which
can be solved independently by applying top-down or bottom-up problem solving
strategies. Second, thinking about problem instances in an abstract way helps
identifying structural properties inherent to the problem, and therefore allows
the pupils to classify them into abstract problem classes, with common properties
that can be solved relying on one single parameterized program. This results in
a high intrinsic cognitive load. Educational research highlights, that this kind of
cognitive load is specific to the contents and considers it as immutable [14].
2.2 How we Reduce the Extraneous Cognitive Load
The educational materials we developed consist of the German textbook Ein-
führung in die Programmierung mit Logo [
], the booklet Programming in LOGO
], and Logo programming environments that are tailored for young pupils and
programming exercises with a visual feedback [
]. The main subject of our paper
is XLogoOnline, the most recent programming environment in this suite [
We strongly believe that Logo – despite its age – still is one of the most
suitable languages for introducing novices of all ages to programming. Moreover,
we are convinced, that Logo together with our teaching materials and the pro-
gramming environments allow for a noticeable reduction of extraneous cognitive
load. Regarding knowledge dimensions presented in the Revision of Bloom’s
Taxonomy [
], we argue that our proposed didactic setting lower the mental effort
and preserve the working memory of the pupils:
We massively reduce the impact of factual knowledge: Instead of introducing
pupils to all the instructions and features of a specific programming language,
we deliberately focus on a very limited set of basic instructions and teach
the kids how to gradually extend the programming language by naming their
programs and making them available for reuse. Furthermore, the chosen
syntax is adequate to age and abstraction skills of school children. The pupils
are not merely using a programming language but they are developing their
own, personalized vocabulary to actively interact with the computer.
Conceptual knowledge is introduced in a compact and didactically effective
way: in the eyes of the pupils, a program simply is a sequence of unambigu-
ous instructions that the computer understands and predictably executes.
Furthermore, we focus on only one looping control structure that avoids
variables, and, later on, we introduce the simpler notion of a static parameter,
as a preparation step to the challenging concept of variable. Variables are
postponed to lower secondary school.
The procedural knowledge and to some extent also metacognitive knowledge
developed by children mainly relies on modular design. We use this design
principle as a straightforward problem solving strategy and, moreover, as a
mean to hide nested loops.
Readers who are interested in further details and reflections on our teaching
approach should refer to our prior publications [
]. With the exception of
the textbook, all teaching materials and environments are freely available to all.
2.3 Programming Languages for School Education
The choice of a specific programming language for school education strictly
depends on the targeted educational objectives. We mainly aim at designing
(and not only at using) a language together with the children, and strongly
believe that programming classes are a unique chance to learn being precise in
a semantic but also in a syntactic way. A text-based programming language
such as Logo is inherently well-suited for teaching both precision and modular
design. Block-based programming languages assume that the syntax is a major
hurdle while learning how to program, and therefore try to lower the extraneous
cognitive load by using graphical elements and a drag-and-drop programming
approach. Although the general objectives of programming classes with block-
and text-based languages seem to be similar, the methods adopted for reducing
the cognitive load on the pupils considerably differ and make separate research
on this topic necessary.
3 Technical and Didactic Design Principles
XLogoOnline was designed as a browser application to meet the requirements
of being an easily deployable programming environment which may be used
across platforms. At schools we encounter a plethora of old and modern computer
infrastructures that vary from stationary computers to laptops and tablets, that
have different operating systems, various screen sizes, and all may or may not be
connected to the Internet.
We had to decide upon numerous technical and didactic design alternatives. In
the following, we present the most influential choices we have taken and describe
their impact on the implementation of our platform:
Built-in diagnostics that offer smart hints and pinpoint errors are automati-
cally generated in XLogoOnline and play an important role in the interaction
between computer and pupil. They help to foster a mostly autonomous and
self-driven learning process, and moreover alleviate pressure on the teacher.
XLogoOnline adopts a two-pronged strategy to reduce distractions in the user
interface. First, the chosen single-page approach, which makes all information
for developing and understanding a program visible at one glance, prevents
obstructively layered windows. Second, exhibiting nothing but the most
important features makes for a simple and clear user interface.
Our reactive, browser-based, client-side application relies on state-of-the-art
technologies and runs on a local web-server in offline mode. It uses the local
file system to store and retrieve code from earlier sessions. This enables the
platform to be deployed independent of whether an internet connection is
available or not.
Our programming environment relies on Canvas, a native dot-matrix data
structure for drawing supported by most modern browsers, which does not
pollute the Document Object Model and, moreover, which provides a handle
for conveniently downloading pictures. Our tool makes efficient use of the
canvas by discerning whether flushing the entire drawing to the canvas is
possible, or whether it should be split into sequences (e.g. in case of a wait
command) as the parser is running.
4 Implementation of XLogoOnline
In the following, we explain what goes on behind the scenes when a Logo
instruction is executed by touching upon the parser, the editor and the canvas
and explaining what actions are triggered by a simple press of the <enter>
button in the input field.
4.1 Information Flow
Pupils interact with four main components (Fig.1): they issue commands to
the input field in a line-by-line manner and each line contains either built-in
or user-defined commands. These programs are defined in the code editor and
retrieved from it during execution. Once execution has finished successfully, the
result is visible as a drawing in the rendering component and the command is
added to the history which keeps track of all recently issued commands. Next,
we zoom in on the pertinent implementation aspects of each component.
Fig. 1: Information flow
4.2 Editor
While our curriculum only introduces a very basic set of Logo primitives, pupils
use the editor to extend the set of commands by defining new customized programs.
Programming demands precision and mistakes are inevitable, therefore we provide
helpful suggestions in terms of diagnostics which highlight token classes directly
in the editor by using different colors and inline markers to pinpoint syntactical
errors. Programs are typically declared in the following characteristic form:
TO P R O G R A M N AME :param1 :param2 .. . : p a r a m N
Two especially common mistakes we see in pupils’ programs are due to
mistaken declarations or invocations of programs. The former usually appear
as parameters with missing double-colons, which are interpreted as invocations
to non-existing programs. The latter often manifest as missing spaces between
program names and their arguments, leading to a single program without any
parameters. Calling such a program later causes a run-time error because the
according signature cannot be found. We help identify these classes of mistakes
using syntax highlighting and checking, which we will explain in the following.
Syntax Highlighting
We assign unique colors to each class of syntactic elements
and reflect those in the editor. For instance, built-in commands like fd (for forward)
or cs (for clear screen) are rendered in a different shade than numbers, parameters
and mathematical constants. Over time, pupils become acquainted to this coloring
scheme and common cases of invalid input such as missing spaces or double colons,
become evident. This simple, yet surprisingly effective mechanism helps pupils
resolve basic mistakes autonomously and further enhances their understanding
of grammatical concepts by revealing how the code is interpreted.
Syntax Checking
As the users type in the editor, their programs are continu-
ously and automatically interpreted in the background after a short period of
inactivity. Programs which fail to parse are analyzed further to locate missing
keywords and erroneous numbers of parameters. The exact location and type
of an error is signaled by adding a red cross directly beside the faulty code
which shows a hint when hovered over. Doing so aids pupils and frees them from
concentrating on syntactical details and let them focus on semantics instead.
Next, we discuss the underlying concepts of our interpretation process.
4.3 Parser and Interpreter
The parser starts by validating that programs satisfy the structural requirements
imposed by the language specification. Using a grammar, the sequence of charac-
ters found in the program is transformed into a sequence of tokens by the lexer.
Next, a parser derives a parse tree from the tokens. We label these two processes
as parsing. The grammar is defined hierarchically as a set of recursive rules.
XLogoOnline parses programs starting at the top-level rule and this starting rule
differs in two cases: in the input field only program invocations are allowed; in
the editor, however, the starting rule only permits program declarations. Once
parsed, a decision is made and ill-typed programs are rejected and otherwise
execution continues with an interpretation phase which traverses the parse tree
using a visitor. Each node corresponds to a Logo instruction and execution entails
drawing to the canvas. These two steps we label drawing.
4.4 Canvas
Once a program has successfully executed, the result is shown on a drawing
surface which allows the user to drag with their mouse and explore the painting.
To support panning, we draw onto a large backing buffer consisting of the visible
view port in the middle and its eight neighboring cells. The view port can fill at
most the whole screen, leading to a backing buffer nine times the actual screen
size. The view port consists of two canvases; one used to display the turtle, the
other to draw strokes onto. Strokes are not rendered to the display until explicitly
flushed. This is a costly operation because the whole frame needs to be redrawn
and so, where suitable, we limit these operations and defer the flush to the end
of the execution.
5 Classroom Studies and Performance Evaluation
We evaluated XLogoOnline based on three experiments. First, we measured
the cognitive load experienced by pupils and teachers across several age ranges
while programming in Logo. Next, we compared XLogoOnline against one of its
predecessors in terms of usability. Last, we benchmarked three programs in a
performance sanity test measuring elapsed time for drawing and compilation.
5.1 Programming and Cognitive Load across Age Groups
In a typical classroom, a single teacher will guide and assist the entire class;
pupils learning how to program, however, progress at differing rates. Ideally
pupils should work autonomously while not experiencing cognitive overload. In
order to observe children programming in a real classroom environment, we ran
several introductory lessons, measured pupils’ and teachers’ exhaustion levels
using a questionnaire and examined the differences in cognitive load across ages.
Setup and Participants
We introduced 75 children (23 girls and 52 boys) and
12 teachers to programming in Logo. In groups of 12, the (mostly) novice pro-
grammers spent 75 minutes solving exercises using sequences of basic movement
commands. Each group consisted either of (i) children aged 6 to 9 being exposed
to geometry for the first time, (ii) children aged 10 to 13 more used to text-style
exercises, geometry and abstract thinking, or (iii) teachers who have progressed
even further in their education but mostly lack prior knowledge in computer
science. Our hypothesis is that with increasing age students become more accus-
tomed to abstract thinking and their cognitive load decreases. Cognitive load,
however, cannot be measured in absolute terms; so we instead asked participants
about their level of exhaustion by having them fill out a questionnaire after
programming. Answers were provided along a 4-option Likert-type scale featuring
smiley faces. This subjective, indirect measure was proposed in prior work by
Paas et al [
], which assumed that the felt complexity of a task and the cognitive
load are correlated.
The combined student data confirmed that children indeed feel cogni-
tively exhausted while programming (Fig.2a) reflecting the need for a tool which
eases their learning whilst also not imposing too much extraneous cognitive load.
The more detailed breakdown by age in Fig.2b confirms our hypothesis; the
shifting peaks reflect that teachers are least exhausted, followed in turn by the
older and the younger pupils respectively who showed increased exhaustion.
(a) Overall pupil exhaustion (b) Exhaustion across three age groups
Fig. 2: Questionnaire indicate particularly high cognitive load for young pupils.
Since exhaustion levels proved to be similar and rather high in both student
groups, we require an objective measure which helps differentiating more finely.
For this reason, we plan to run a follow-up study examining cognitive load by
measuring the number of exercises solved in total. Furthermore, we will explore
the influence of different exercise types on the cognitive load of the programmer.
The experiment confirmed that most children experience rather high cognitive
load while programming, which reinforces the need for tailored teaching material
to enable better learning experiences. Children aged 6-9 showed the highest
exhaustion levels, while children aged 10-13 were not only less exhausted, but
we also observed them to be more progressive and able to work without direct
5.2 Usability Comparison of XLogo and XLogoOnline
To understand whether our design choices had a positive impact on user ex-
perience, we ran a second user study and examined the children’s interaction
with XLogoOnline, their understanding of the purpose of selected components
therein and general impression of the user interface. Figure 3shows a side-by-side
comparison of what solving the same exercise would look like in XLogoOnline
and its predecessor XLogo.
(a) Predecessor (native): XLogo (b) Our contribution: XLogoOnline
Fig. 3: XLogoOnline features an uncluttered single-page layout with bigger fonts
and a reduced set of GUI features for reducing the extraneous cognitive load and
in support of a young audience whose fine motor skills have yet to fully develop.
Setup and Participants
A fifth-grade class consisting of 18 pupils, generally
aged 11 or 12 years, participated in this on-site experiment. The class was first
introduced to the traditional programming environment XLogo for three weeks
where they learned about the basic commands as well as the concepts of repetition
and modularization in Logo.
After getting used to programming in XLogo for three programming sessions
which lasted two hours each, we introduced XLogoOnline while covering regular
polygons. After a short introduction, we left the children to solve exercises for
two hours before finishing the experiment by handing out feedback questionnaires
covering three main questions: first, we checked their understanding of the use of
the four main UI components by letting pupils draw connections between pictures
of both user interfaces and descriptions of the components’ purpose; second, we
asked pupils to grade the four components in XLogoOnline on both their visual
appearance and their functionality; last, we asked them to tell us about their
general impression working with the platform.
A vast majority (83% of all pupils) understood the usage and meaning
of the four UI components correctly and could easily transfer from XLogo to
XLogoOnline. We received strongly positive feedback (praises for the syntax
checker, error pinpointing, layout, clarity and comprehensibility) which give reas-
surance that simplifying the user interface in XLogoOnline, adopting a flat design
and equipping it with additional diagnostic tools like syntax highlighting and
syntax checking are indeed beneficial. Some pupils missed certain features XLogo
provided and others found the space usage not optimal, which we subsequently
adjusted according to their needs. We conclude, that the transition between
XLogo and XLogoOnline posed no significant burden on the students.
5.3 Performance Test
It is easy to build complex shapes involving several tens of thousands of drawing
instructions by simply repeating sequences of basic patterns many times over. To
ensure that even these complex exercises in our teaching materials are executed
in reasonable time, we chose three benchmark programs (shown in Fig.4) which
represent a range from short to more time-intense programs and checked their
(a) Cheap (b) Medium (c) Expensive
Fig. 4: Benchmark programs ranging from cheap through expensive
The respective programs were re-run 1000 times in XLogoOnline while mea-
suring their overall execution times. We found an average performance of 20000
drawing instructions per seconds on a four-year old off-the-shelf laptop. Conse-
quently, the running time for simple shapes like the ones shown in Fig.4a and
Fig.4b add up to merely a few milliseconds. Moreover, even the most time-intense
exercises in our curriculum run to completion on the order of seconds, which we
consider satisfactory for the typical classroom setting.
Finally, we investigated the breakdown of execution time between drawing
and parsing to determine the cost of diagnostics, which rely on repeated parsing
of the input. We found drawing to be the more influential factor between the two
phases and that, as programs get bigger, it increasingly dominates the overall
execution time (shown in Figure 5). Diagnostics like error classification and
additional hints are potentially expensive, however, the time spent in parsing
constitutes a negligible fraction of the total time and significantly helps pupils
recover from their mistakes.
Fig. 5: The larger the pro-
gram, the more time we
spent traversing the parse
tree (i.e. drawing) while
building the parse tree (i.e.
parsing) takes only a frac-
tion of the time.
In summary, we found XLogoOnline able to execute all exercises in our
teaching material in reasonable times and parsing to be relatively cheap which
allows for further diagnostics as an additional help for the pupil, supporting a
more autonomous diagnosis and remedy of syntactic errors.
6 Conclusion
Teaching how to program in hundreds of schools, we found algorithmic thinking
and programming to be exciting but exhaustive activities, especially for young
pupils. We introduce XLogoOnline, our new browser-based programming environ-
ment that aims at reducing the extraneous cognitive load on school children. It
is tailored around a curriculum with a deliberately small set of basic commands.
Pupils steadily learn to expand the language with custom commands while
solving algorithmic problems. As a distinguishing attribute, our programming
environment features diagnostics which provide useful feedback to the program-
mer while having an uncluttered and easy to use single-page user interface. The
programming IDE can be deployed at the click of a button using only a web
browser and, thanks to its reactive design, can be run on a broad set of devices
with different screen sizes and platforms. We ran classroom studies investigating
cognitive load during introductory lessons and found a clear need for appropriate
didactic settings which reduce the load on pupils’ working memory. XLogoOnline
was shown to be intuitive and generally approved by primary school pupils.
Future Work
: Our broader goals are to understand what troubles young
programmers the most. Web environments are especially well-suited for collecting
rich data sets, for instance, containing student mistakes. Analyzing this data may
reveal patterns which can be tied back to conceptual error classes and tackled
more explicitly in our curriculum. Further, we are investigating social effects in
programming and have built an early prototype extension for XLogoOnline that
allows pupils to collaborate on exercises by sharing code and drawings with their
Logo-Uunterrichtsmaterialialien & -Programmierumgebungen (Status as of Septem-
ber 18, 2017).
Walter Gander et al. Informatics education: Europe cannot afford to miss the boat.
Informatics Europe & ACM Europe Working Group on Informatics Education,
Juraj Hromkovič, Tobias Kohn, Dennis Komm, and Giovanni Serafini. Combining
the power of Python with the simplicity of Logo for a sustainable computer science
education. In Proc. of ISSEP 2016, LNCS, 9973:155–166, Springer, 2016.
Juraj Hromkovič, Tobias Kohn, Dennis Komm, and Giovanni Serafini. Examples
of algorithmic thinking in programming education. Olympiads in Informatics,
10:111–124, 2016.
Juraj Hromkovic, Tobias Kohn, Dennis Komm, and Giovanni Serafini. Algorithmic
thinking from the start. Bulletin of the EATCS, 121:132–139, 2017.
Juraj Hromkovič. Einführung in die Programmierung mit LOGO. Springer, 3rd
edition, 2014.
Donald E. Knuth. Algorithmic thinking and mathematical thinking. The American
Mathematical Monthly, 92(3):170–181, 1985.
David R. Krathwohl. A revision of Bloom’s taxonomy: An overview. Theory into
Practice, 41(4):212–218, 2002.
Bernhard Matter. Projekt “Programmieren in der Primarschule” (Status as of
September 18, 2017).
Gabriel Parriaux and Jean-Philippe Pellet. Computer science in the eyes of its
teachers in French-speaking Switzerland. In Proc. of ISSEP 2016, LNCS, 9973:179–
190, Springer, 2016.
Giovanni Serafini. Teaching programming at primary schools: Visions, experiences,
and long-term research prospects. In Proc. of ISSEP 2011, LNCS, 7013:143–154,
Springer, 2011.
Jacqueline Staub. XlogoOnline (Status as of September 18, 2017).
Jacqueline Staub. Xlogo online - a web-based programming IDE for Logo. Master
Thesis, 2016.
John Sweller. Cognitive load theory. Psychology of Learning and Motivation,
55:37–76. Academic Press, 2011.
Fred G. W. C. Paas, Jeroen J. G. van Merriënboer, and Jos J. Adam. Measurement
of Cognitive Load in Instructional Research. Perceptual and Motor Skills, 79(1):419–
430, 1994.
... The students seemed to enjoy programming and solution sharing and did not appear to struggle with the language syntax [68]. A variant was used to introduce programming concepts and develop algorithmic thinking skills in students aged 11-12 [26], and a simplified browser-based version with reduced cognitive load has been deployed for use in Swiss schools [27]. A 2007 Taiwanese study found that guided collaboration resulted in significantly better understanding than self-directed learning for sixth-grade students using MSWLogo over a 14-week course [40]. ...
Conference Paper
Full-text available
Computing education and outreach in the K--12 school sector have shown significant growth over recent decades, resulting in a large body of literature focused on the teaching and learning of computing. Despite this extensive literature, we are not aware of global overviews on teaching and learning programming as opposed to computing or computational thinking in K--12. We conducted a systematic review of the literature on introductory programming from 2003 to 2017. In this paper we review the papers that were set in the K--12 context with the aim of exploring developments that have been made in teaching introductory K--12 programming during this period. These include new programming languages, tools, teaching methods, and outreach programs. The impetus for these innovations was often a desire to provide interesting and engaging learning experiences and to ensure an appropriate level of instruction for a particular age group. Many initiatives were driven by changes to national curricula to mandate the teaching of programming. We find that there is a need for long-term studies to identify the most effective pedagogical approaches. We also identify a major need faced by many countries for training and resources to support teachers through the curriculum changes.
... In the context of Logo, some environments (e.g., Turtle Blocks [4] and Robo Blocks [25]) provide debugging support through single-stepping, however, so far no Logo debugger allows programmers to also step backward in time. We address this problem and present a reverse debugger for XLogoOnline [18]. ...
Full-text available
Programming is a creative activity that teaches precision. In Logo, novices write simple programs that draw geometric shapes onto a screen. Logical flaws, however, cause unintended results and pose a major challenge for young programmers who yet need to learn how to search for errors in their code. We discuss the problems novices face when learning to program in Logo. Furthermore, we present a reverse debugger for Logo that enables programmers to step through their code in either direction. Using a stack, previous program states can be retrieved on demand. Our solution balances performance and memory consumption and hence can be used to debug even long and complex programs.
... Programming environments that facilitate programming for non-programmers and/or children are environments that have visual characteristics and block programming, promising simpler and more understandable interfaces [25]. The aim of the usability analysis of these environments is to identify if they effectively fulfill their purpose (i.e., [26]- [28] and [29]). Some studies have even incorporated natural language to support novice programmers [30]. ...
Programmers use various software development artifacts in their work, such as programming environments, design documents, and programming codes. These software artifacts can be studied and improved based on usability and User eXperience (UX) factors. In this work, we consider programmers to be a specific case of users and analyze different elements that influence their experience in this specific context. We conducted a systematic literature review of papers published over the last 10 years related to: (i) the definition of the Programmer eXperience (PX); (ii) the PX, UX, and usability factors regarding the programming environments, design documents, and programming codes; and (iii) sets of heuristics to evaluate the software development artifacts mentioned before. We analyzed 73 articles, and the results obtained show: (i) the important elements that influence the PX are the motivation of programmers and the choice of tools they use in their work, such as programming environments; (ii) most of the identified studies (59%) aimed to evaluate the influence of the PX, UX, and usability on programming environments; (iii) the majority of the studies (70%) used methods such as usability tests and/or heuristic evaluation methods; (iv) 4 sets of heuristics are used to evaluate software development artifacts in relation to programming environments, programming languages and application programming interfaces. The results suggest that further research in this area is necessary to better understand and evaluate the concept of the PX.
... Moreover, the paper describes how we integrated the proposed methodology into our existing XLogoOnline [1] programming environment and how it supports primary school children in rapidly locating and identifying frequent mistakes. In our intention, the proposed approach is expected to facilitate autonomous recovery from programming errors and therefore to smoothen independent learning. ...
Full-text available
Programming classes offer unique opportunities to learn both semantic and syntactic precision, even for primary school children without prior knowledge in computer science. In order to make students progress autonomously, programming languages and environments need to be chosen with care to their didactic quality. This paper introduces four classes covering the majority of what we call structural programming errors. These mistakes are either syntactical errors or the result of invocations that do not match the signature of any user-defined command, and therefore prevent the execution of a program. Furthermore, we present a methodology that allows for detecting as many structural programming errors as possible, and show how we integrated this methodology in our Logo programming environment for primary schools. Finally, we reflect on an evaluation we carried out at school that confirms the didactic benefits of the chosen approach.
... Many modern educational programming environments, like Scratch (Resnick et al., 2009), Alice (Bishop-Clark et al., 2007), and Greenfoot (Ko¨lling, 2010), have been influenced (indirectly) by principles of constructivism, although constructivism is often not explicitly referenced as part of their design rationale. Based on CLT, other environments for novice programmers like CORT (Garner, 2009), ReadJava simulator (Williams, 2014), XLogoOnline (Hromkovicˇ, Serafini, & Staub, 2017) were designed explicitly to reduce cognitive load on its users. Moons and De Backer (2013) combined principles of these two learning theories in the design of their interactive learning environment for introductory programming, and its evaluation showed that it facilitated its users in understanding programming constructs most students find difficult. ...
Full-text available
This article discusses the design and implementation of a new programming tool for Greek novices as a means to improve introductory programing instruction in Greece. We implemented Koios, a new highly interactive and visual programming tool for Greek novices, based on the body of research in the field of psychology of programming. The main contribution of this article is the empirical demonstration of the benefit of this tool in novice programming, compared with two other popular programming tools for Greek novices. The results show that users of Koios performed significantly better than users of the other two programming tools.
... For a more detailed presentation of this topic, see [9,[12][13][14][15][16][17]. The starting point is not to teach a programming language, but rather to combine problem solving with the communication of the designed algorithm to the computer. ...
Conference Paper
Teaching computer science offers more than algorithmic thinking (or more general and as recently presented: computational thinking). To understand this claim, one has to have a more careful look at the development of human culture, science, and technology. This helps not only to recognize that the computer science way of thinking was crucial for the development of human society since anyone can remember, but it helps to make a good choice of topics for sustainable computer science education in the context of science and humanities. This leads to the creation of textbooks that do not focus on particular knowledge for specialists, but offer serious contributions in the very general framework of education.
This article describes an approach to foster computational thinking in different school subjects. Our approach includes several teaching units (packages) that are self-contained and have been designed for university courses attended by prospective and graduate primary and secondary school teachers. Around 30 packages have been designed so far and together cover eight aspects of computational thinking in six different subjects. In this report, some examples are sketched out together with the experiences gathered.
Full-text available
Zusammenfassung In diesem Artikel stellen wir drei Programmierumgebungen vor, welche an der ETH Zürich entwickelt wurden und in einem einheitlichen Spiralcurriculum für den Programmierunterricht vom Kindergarten bis zur Maturität verwendet werden können. Der Fokus liegt auf der selbstständigen Entwicklung funktionsfähiger Programme. Ausgehend von einer Aufgabenstellung beginnt der Prozess der Erkenntnisgewinnung mittels Ausprobierens, Entwickeln einer Lösungsstrategie und deren Umsetzung in einem vollständigen Programm. Dieses wird schließlich getestet, indem es am Computer ausgeführt und nach Bedarf verbessert oder erweitert wird. Unsere Programmierumgebungen unterstützen hohe Selbstständigkeit der Kinder und Jugendlichen in allen Phasen der Herstellung eines Produktes im Sinne eines funktionierenden Programmes.
Full-text available
Algorithmic thinking and problem solving strategies are essential principles of computer science. Programming education should reflect this and emphasize different aspects of these principles rather than syntactical details of a concrete programming language. In this paper, we identify three major aspects of algorithmic thinking as objectives of our curricula: the notion of a formal language to express algorithms, abstraction and automation to transfer proven strategies to new instances, and the limits of practical computability. The primary contribution of this paper are three examples that illustrate how general aspects of algorithmic thinking can be incorporated into programming classes. The examples are taken from our teaching materials for K-12 and university non-majors and have been extensively tested in the field.
Full-text available
The results of two of our recent empirical studies were considered to assess the usefulness of subjective ratings and cardiovascular measures of mental effort in instructional research. Based on its reliability and sensitivity, the subjective rating-scale technique met the requirements to be useful in instructional research whereas the cardiovascular technique did not. It was concluded that the usefulness of both measurement techniques in instructional research needs to be investigated further.
Conference Paper
This paper discusses the situation of high-school-level Computer Science education (CSE) in the French-speaking part of Switzerland through the eyes of Computer Science teachers. After presenting the peculiarities of the educational system in a federal state like Switzerland and its impact on CSE, we try to answer several questions about CS teachers, their profile, and their representations of the field. Recognizing that the primary field of study of most current CS teachers was not CS, we question their representations of CS in search of potential differences between specialists and non-specialists. On this basis, we analyze the distance between CS as it is taught in French-speaking Swiss high schools and CS as its teachers think it should ideally be taught. Finally, we present the important need for continuing education of CS teachers and the fact that, according to them, it should include both technical and didactic aspects.
Conference Paper
Computer science education in K-12 and for non-majors at university often aims at making students confident with computational thinking by introducing them to programming. We are convinced that such programming classes offer a great opportunity to expose students to core concepts of computer science and thereby contribute to a broad and general education. In this article, we describe our approach and experiences with teaching programming at various levels, namely at primary schools, high schools, and universities. We identify a set of goals that allow us to go beyond the pure teaching of specifics of a given programming language, i. e., syntactical details, and shift the focus towards sustainable topics such as algorithms as problem solving methods and their analysis.
Cognitive load theory uses evolutionary theory to consider human cognitive architecture and uses that architecture to devise novel, instructional procedures. The theory assumes that knowledge can be divided into biologically primary knowledge that we have evolved to acquire and biologically secondary knowledge that is important for cultural reasons. Secondary knowledge, unlike primary knowledge, is the subject of instruction. It is processed in a manner that is analogous to the manner in which biological evolution processes information. When dealing with secondary knowledge, human cognition requires a very large information store, the contents of which are acquired largely by obtaining information from other information stores. Novel information is generated by a random generate and test procedure with only very limited amounts of novel information able to be processed at any given time. In contrast, very large amounts of organized information stored in the information store can be processed in order to generate complex action. This architecture has been used to generate instructional procedures, summarized in this chapter.
My purpose in this paper is to stimulate discussion about a philosophical question that has been on my mind for a long time: What is the actual role of the notion of an algorithm in mathematical sciences? For many years I have been convinced that computer science is primarily the study of algorithms. My colleagues don't all agree with me, but it turns out that the source of our disagreement is simply that my definition of algorithms is much broader than theirs: I tend to think of algorithms as encompassing the whole range of concepts dealing with well-defined processes, including the structure of data that is being acted upon as well as the structure of the sequence of operations being performed; some other people think of algorithms merely as miscellaneous methods for the solution of particular problems, analogous to individual theorems in mathematics. In the U.S.A., the sorts of things my colleagues and I do is called Computer Science,
Conference Paper
The key contribution of computer science to general and school education relies on the concept of Computational Thinking. Teaching programming in Logo at the primary school is an appropriate didactic approach towards Computational Thinking, it permits to embed Computational Thinking into a spiral curriculum at a very early stage and should enable specific transfer to related school subjects. The paper describes our concrete experiences in teaching programming in Logo at Swiss primary schools, reflects on didactic visions and consider prospects for long-term empirical research.