<commit_before>\documentclass[12pt,notitlepage]{article}
\usepackage[bitstream-charter]{mathdesign}
\usepackage{inconsolata}
\usepackage[T1]{fontenc}
\usepackage{microtype}
\usepackage[utf8x]{inputenc}
\usepackage[letterpaper,margin=1in]{geometry}
\usepackage{titlesec}
\usepackage{graphicx}
\usepackage{wrapfig}
\usepackage{caption}
\usepackage{subcaption}
\usepackage{hyperref}
\usepackage{multicol}
\usepackage{booktabs}
\usepackage{tabu}
\usepackage{tikz}
\usepackage{pgfplots}

\newcommand\footnoteref[1]{\footnote{\url{#1}}}
\newcommand\tmts[0]{\texttt{tell me to survive}}

\titleformat{\section}{\normalfont\large}{\thesection}{0.5em}{}
\titleformat{\subsection}{\bfseries}{\thesubsection}{0.5em}{}
\titleformat{\subsubsection}{\normalfont}{\thesubsubsection}{0.5em}{}
\titlespacing*{\section}{0em}{0.75em}{0.3em}

\begin{document}
\begingroup
  \centering
  {\Large \texttt{tell me to survive}: Concreteness Fading and Visual
    Programming in Teaching Object-Oriented Programming\\[1em]}

  <NAME>, <NAME>, and <NAME>\par
\endgroup

\section{Introduction and Motivation}

Much effort has gone towards methods to teach programming as an
overall concept, with systems like Scratch and CodeSpells
demonstrating how visual programming can successfully introduce
students to this field. Our goal is to teach the more specific topic
of object-oriented programming to novice programmers using these same
techniques, focusing on how to abstract and represent ideas such as
method definitions, subclassing, and overriding. Additionally, to
reinforce these concepts to an audience already somewhat familiar with
programming, we will introduce concreteness fading, transitioning
students from visual programming to directly writing code. This will
facilitate the learning of these specific higher-level concepts and
abstractions within computer science, which is important to
effectively educate and train the next generation of computer science
and software development students.

\section{Related Work}

The idea of visual programming manipulating robots or other objects in
a virtual world is not new; we list several games and projects in the
same vein, with some comparison to our project.

\begin{multicols}{2}
\begin{itemize}
\item CodeSpells\footnoteref{https://codespells.org/}
\item Scratch\footnoteref{https://scratch.mit.edu/}/Alice\footnoteref{http://www.alice.org/}
\item Looking Glass\footnoteref{https://lookingglass.wustl.edu/}
\item Hour of Code\footnoteref{https://code.org/learn}
\item LightBot\footnoteref{https://lightbot.com/hocflash.html}
\item Human Resource Machine\footnoteref{https://tomorrowcorporation.com/humanresourcemachine}
\item Blockly Games\footnoteref{https://blockly-games.appspot.com/}
\item BlockPy\footnoteref{https://github.com/RealTimeWeb/blockpy}
\end{itemize}
\end{multicols}

CodeSpells, Alice, Scratch, and Looking Glass are more free-form;
instead of specific puzzles or levels to solve, they simply place the
player in a sandbox. Looking Glass has metaphors for object-oriented
concepts, and covers more of them than our project does, but does not
employ concreteness fading. Hour of Code, LightBot, and Human Resource
Machine take the same puzzle-oriented approach our game does, but also
lack the concreteness fading aspect. Blockly Games is the most similar
to our approach, initially using blocks whose labels transition from
text descriptions to code, then changing to a text editor at the
end. However, it does not present a consistent game, changing the
theme and mechanics every few levels. BlockPy is more advanced,
enabling the player to seamlessly switch between code and visual
programming (and translating one to the other), but does not use
concreteness fading either.

\section{Methodology}

\tmts{} is a purely client-side, web-based game built on
HTML5/JavaScript using Python as its instructional language. The core
concept is manipulating robots in a game world via visual or
text-based programming in order to solve puzzles and accomplish
objectives.

\subsection{Concepts}

\begin{figure}[h]
  \centering
  \includegraphics[width=.6\textwidth]{progression}
  \caption{Concept Progression}
\label{fig:progression}
\end{figure}

We limited our scope to the concepts in \autoref{fig:progression} in
order to limit the game length and complexity, and because of
implementation constraints. This means that advanced topics such as
abstract classes and polymorphism are not covered. This is an
acceptable trade-off because the purpose of this game is not to teach
OOP in its entirety, but rather to ease the conceptual transition for
new programmers.

\autoref{fig:progression} lists the progression of requisite skills up
to mastery of inheritance (our overall learning objective). Mastering
a skill in any given level in the diagram should require mastering
every skill in the previous level. For instance, using inheritance
effectively requires that the user is writing methods across several
classes in the hierarchy, then instantiating different types of objects
with those classes. These individual skills can then be further subdivided
down to the basics of using our click-and-drag block input system.

The level progression slowly moves concept by concept through the
skill tree, trying to introduce only one new concept per level;
otherwise, users are likely to get confused. For example, consider how
new robot types are introduced. At first the player must identify that
\texttt{MineRobot} (and other subclasses) can use functions for moving
and turning from the basic \texttt{Robot} class. Later on, there are
more complex relations, such as the way that \texttt{FrackingRobot}
overrides a function from \texttt{MineRobot}. Moreover, as new
concepts are introduced, old concepts are recombined to make new
puzzles. For example, the \texttt{HeavyLifter} is used in a context
such that it needs to use a function defined in the basic
\texttt{Robot} class. However, it also requires implementing that
method first.

\subsubsection{Concreteness Fading}

Our fading process has 3 stages. Initially, all blocks start off as
textual descriptions of what they do, e.g.\ ``tell \_ to \_'' for
method invocation or ``create a new \_ called \_'' for object
instantiation (see \autoref{fig:block-unfaded}). As the player
progresses, the labels on the blocks are faded into actual Python code,
as in \autoref{fig:block-faded}. Eventually, the player will be given
a text editor and asked to write the Python code themselves. Some
scaffolding always remains; for instance, the object hierarchy view always
remains accessible after it is introduced, and serves as a reference for
what classes and methods are available.

Beta testing found that changes to the blocks should not happen while
another concept is introduced, because otherwise, players are
overwhelmed by the number of new skills required. Thus, some levels
introduce no new object-oriented concepts, and instead, pose a simpler
puzzle focusing on usage of a newly faded block.

\begin{figure}[h]
\centering
\begin{subfigure}{.5\textwidth}
  \centering
  \includegraphics[width=.7\textwidth]{block_unfaded}
  \caption{An unfaded method invocation block.}\label{fig:block-unfaded}
\end{subfigure}%
\begin{subfigure}{.5\textwidth}
  \centering
  \includegraphics[width=.7\textwidth]{block_faded}
  \caption{The faded method invocation block.}\label{fig:block-faded}
\end{subfigure}
\label{fig:test}
\end{figure}


\subsection{Application Design}

Through user testing, we simplified our block interface as much as
possible. For instance, the repeat block was changed from accepting a
block subexpression to just a number. The player does not have access
to more complicated control flow such as branches and for loops. In
fact, even method invocation was simplified by ignoring parameters and
return values. Our goal was to focus more on a basic set of OOP
concepts and the corresponding syntax. Thus, we limited access to
features that would increase the complexity of solution code, while
ensuring that the player must use object-oriented concepts to solve
the level.

To further enforce object-oriented thinking, we imposed a block
limit. Similar to the way LightBot forces players to define functions
due to lack of space, we design levels such that there is no way to
finish within the block limit without defining a method. This forces
players to consider the class hierarchy and actually implement useful
methods they call on objects. Without this restriction, the hierarchy
(and thus our goal of teaching OOP) could potentially be disregarded.
% TODO: did we find a user that actually did that?

\subsection{Evaluation}

We evaluated the performance of the game by administering a pre-test
and post-test to all people who completed the game. Both tests were<commit_msg>chore: discuss getting around restrictions<commit_after>\documentclass[12pt,notitlepage]{article}
\usepackage[bitstream-charter]{mathdesign}
\usepackage{inconsolata}
\usepackage[T1]{fontenc}
\usepackage{microtype}
\usepackage[utf8x]{inputenc}
\usepackage[letterpaper,margin=1in]{geometry}
\usepackage{titlesec}
\usepackage{graphicx}
\usepackage{wrapfig}
\usepackage{caption}
\usepackage{subcaption}
\usepackage{hyperref}
\usepackage{multicol}
\usepackage{booktabs}
\usepackage{tabu}
\usepackage{tikz}
\usepackage{pgfplots}

\newcommand\footnoteref[1]{\footnote{\url{#1}}}
\newcommand\tmts[0]{\texttt{tell me to survive}}

\titleformat{\section}{\normalfont\large}{\thesection}{0.5em}{}
\titleformat{\subsection}{\bfseries}{\thesubsection}{0.5em}{}
\titleformat{\subsubsection}{\normalfont}{\thesubsubsection}{0.5em}{}
\titlespacing*{\section}{0em}{0.75em}{0.3em}

\begin{document}
\begingroup
  \centering
  {\Large \texttt{tell me to survive}: Concreteness Fading and Visual
    Programming in Teaching Object-Oriented Programming\\[1em]}

  <NAME>, <NAME>, and <NAME>\par
\endgroup

\section{Introduction and Motivation}

Much effort has gone towards methods to teach programming as an
overall concept, with systems like Scratch and CodeSpells
demonstrating how visual programming can successfully introduce
students to this field. Our goal is to teach the more specific topic
of object-oriented programming to novice programmers using these same
techniques, focusing on how to abstract and represent ideas such as
method definitions, subclassing, and overriding. Additionally, to
reinforce these concepts to an audience already somewhat familiar with
programming, we will introduce concreteness fading, transitioning
students from visual programming to directly writing code. This will
facilitate the learning of these specific higher-level concepts and
abstractions within computer science, which is important to
effectively educate and train the next generation of computer science
and software development students.

\section{Related Work}

The idea of visual programming manipulating robots or other objects in
a virtual world is not new; we list several games and projects in the
same vein, with some comparison to our project.

\begin{multicols}{2}
\begin{itemize}
\item CodeSpells\footnoteref{https://codespells.org/}
\item Scratch\footnoteref{https://scratch.mit.edu/}/Alice\footnoteref{http://www.alice.org/}
\item Looking Glass\footnoteref{https://lookingglass.wustl.edu/}
\item Hour of Code\footnoteref{https://code.org/learn}
\item LightBot\footnoteref{https://lightbot.com/hocflash.html}
\item Human Resource Machine\footnoteref{https://tomorrowcorporation.com/humanresourcemachine}
\item Blockly Games\footnoteref{https://blockly-games.appspot.com/}
\item BlockPy\footnoteref{https://github.com/RealTimeWeb/blockpy}
\end{itemize}
\end{multicols}

CodeSpells, Alice, Scratch, and Looking Glass are more free-form;
instead of specific puzzles or levels to solve, they simply place the
player in a sandbox. Looking Glass has metaphors for object-oriented
concepts, and covers more of them than our project does, but does not
employ concreteness fading. Hour of Code, LightBot, and Human Resource
Machine take the same puzzle-oriented approach our game does, but also
lack the concreteness fading aspect. Blockly Games is the most similar
to our approach, initially using blocks whose labels transition from
text descriptions to code, then changing to a text editor at the
end. However, it does not present a consistent game, changing the
theme and mechanics every few levels. BlockPy is more advanced,
enabling the player to seamlessly switch between code and visual
programming (and translating one to the other), but does not use
concreteness fading either.

\section{Methodology}

\tmts{} is a purely client-side, web-based game built on
HTML5/JavaScript using Python as its instructional language. The core
concept is manipulating robots in a game world via visual or
text-based programming in order to solve puzzles and accomplish
objectives.

\subsection{Concepts}

\begin{figure}[h]
  \centering
  \includegraphics[width=.6\textwidth]{progression}
  \caption{Concept Progression}
\label{fig:progression}
\end{figure}

We limited our scope to the concepts in \autoref{fig:progression} in
order to limit the game length and complexity, and because of
implementation constraints. This means that advanced topics such as
abstract classes and polymorphism are not covered. This is an
acceptable trade-off because the purpose of this game is not to teach
OOP in its entirety, but rather to ease the conceptual transition for
new programmers.

\autoref{fig:progression} lists the progression of requisite skills up
to mastery of inheritance (our overall learning objective). Mastering
a skill in any given level in the diagram should require mastering
every skill in the previous level. For instance, using inheritance
effectively requires that the user is writing methods across several
classes in the hierarchy, then instantiating different types of objects
with those classes. These individual skills can then be further subdivided
down to the basics of using our click-and-drag block input system.

The level progression slowly moves concept by concept through the
skill tree, trying to introduce only one new concept per level;
otherwise, users are likely to get confused. For example, consider how
new robot types are introduced. At first the player must identify that
\texttt{MineRobot} (and other subclasses) can use functions for moving
and turning from the basic \texttt{Robot} class. Later on, there are
more complex relations, such as the way that \texttt{FrackingRobot}
overrides a function from \texttt{MineRobot}. Moreover, as new
concepts are introduced, old concepts are recombined to make new
puzzles. For example, the \texttt{HeavyLifter} is used in a context
such that it needs to use a function defined in the basic
\texttt{Robot} class. However, it also requires implementing that
method first.

\subsubsection{Concreteness Fading}

Our fading process has 3 stages. Initially, all blocks start off as
textual descriptions of what they do, e.g.\ ``tell \_ to \_'' for
method invocation or ``create a new \_ called \_'' for object
instantiation (see \autoref{fig:block-unfaded}). As the player
progresses, the labels on the blocks are faded into actual Python code,
as in \autoref{fig:block-faded}. Eventually, the player will be given
a text editor and asked to write the Python code themselves. Some
scaffolding always remains; for instance, the object hierarchy view always
remains accessible after it is introduced, and serves as a reference for
what classes and methods are available.

Beta testing found that changes to the blocks should not happen while
another concept is introduced, because otherwise, players are
overwhelmed by the number of new skills required. Thus, some levels
introduce no new object-oriented concepts, and instead, pose a simpler
puzzle focusing on usage of a newly faded block.

\begin{figure}[h]
\centering
\begin{subfigure}{.5\textwidth}
  \centering
  \includegraphics[width=.7\textwidth]{block_unfaded}
  \caption{An unfaded method invocation block.}\label{fig:block-unfaded}
\end{subfigure}%
\begin{subfigure}{.5\textwidth}
  \centering
  \includegraphics[width=.7\textwidth]{block_faded}
  \caption{The faded method invocation block.}\label{fig:block-faded}
\end{subfigure}
\label{fig:test}
\end{figure}


\subsection{Application Design}

Through user testing, we simplified our block interface as much as
possible. For instance, the repeat block was changed from accepting a
block subexpression to just a number. The player does not have access
to more complicated control flow such as branches and for loops. In
fact, even method invocation was simplified by ignoring parameters and
return values. Our goal was to focus more on a basic set of OOP
concepts and the corresponding syntax. Thus, we limited access to
features that would increase the complexity of solution code, while
ensuring that the player must use object-oriented concepts to solve
the level.

To further enforce object-oriented thinking, we imposed a block
limit. Similar to the way LightBot forces players to define functions
due to lack of space, we design levels such that there is no way to
finish within the block limit without defining a method. This forces
players to consider the class hierarchy and actually implement useful
methods they call on objects. Without this restriction, the hierarchy
(and thus our goal of teaching OOP) could potentially be disregarded.

One way around this restriction is to code the solution for an entire
level inside of a method that has been faded to the code editor. We
saw this happen once in our testing. However, in the end, this is
actually beneficial because the user is writes more object-oriented 
python code than originally expected.

\subsection{Evaluation}

We evaluated the performance of the game by administering a pre-test
and post-test to all people who completed the game. Both tests were
{'fraction_non_alphanumeric': 0.06583948133243908, 'fraction_numerical': 0.0032416722557567627, 'mean_word_length': 5.313690896259704, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 16, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7084419', 'n_tokens_mistral': 4757, 'n_tokens_neox': 4588, 'n_words': 2217}