Abstraction Systems for Translating and Customizing a Blocks-Based Programming Language
by David Wu S.B., C.S., M.I.T., 2017
Submitted to the
Department of Electrical Engineering and Computer Science In Partial Fulfillment of the Requirements for the Degree of Master of Engineering in Electrical Engineering and Computer Science
at the
Massachusetts Institute of Technology ·Ma ·~ (J,.int. 1.,0\i)
©D-.v;o
Wv
io,i
The author hereby grants to M.IT. permission to reproduce and to distribute publicly paper and electronic copies of this thesis document in
whole and in part in any medium now known or hereafter created.
Signature redacted
Author:
_ Department of Electrical Engineering and Computer Science
·
Signature redacted
May 25, 2018 Certified by: _ _Eric Klop'rer, Director of the MIT Scheller Teacher Education Program Thesis Supervisor May 25, 2018 Accepted by: _ _ _ _
Signature redacted
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
/ AUG 2
oz~~J
LIBRARIES
Katrina LaCurts Chair, Master of Engineering Thesis Committee
ABSTRACT
StarLogo Nova is a tool that allows users to analyze complex systems by programming agent-based models with a block-based programming language. It can be used in education to study complex systems in a more modern way and is accessible to anyone who has access to the internet. However, there are still a few barriers that reduce StarLogo Nova's impact. First, it is only available in English, so users who are not fluent in English will have difficulty using the powerful tool. Second, novice users who are unfamiliar with programming may find it hard to learn how to program their models, which diminishes their ability to study the science concepts they are trying to model. This thesis takes steps to remedy these problems. First, I develop a system for translating StarLogo Nova into different languages. Then, I work with a fellow researcher in the Scheller Teacher Education Program (STEP) lab on the development of custom blocks: user-defined blocks that can be used to simplify the modeling process. Our design of custom blocks is made with the novice user in mind, creating a more intuitive custom-block creation experience than currently exists in other block-programming languages.
ACKNOWLEDGEMENTS
I would like to acknowledge various people who have journeyed with me as I have completed this thesis. First, I owe enormous gratitude to my advisor and mentor, Daniel Wendel for his consistent support throughout the different phases of this thesis.
My sincere thanks goes to my fellow researcher in the STEP lab Hyeonsu Kang, who worked with me on the development of custom blocks.
Finally, I would also like to thank my family for proofreading my thesis and offering unwavering support throughout my life.
1. Introduction 9
2. Background 11
2.1 Introduction to StarLogo Nova 11
2.1.1 Computational Modeling 11
2.1.2 StarLogo 12
2.1.3 StarLogo TNG 12
2.1.4 StarLogo Nova 13
2.2 StarLogo Nova Interface 13
2.2.1 Agents 13
2.2.2 StarLogo Nova Interface – Project Page 14
3. Developing a Translation System for StarLogo Nova 15
3.1 Translation in Other Websites and Block Programming Languages 16
3.2 Project Page Translation 17
3.3 Structure of StarLogo Blocks Relevant to Translation 18
3.3.1 Blocks 18
3.3.1.1 Block Labels and Arguments 18
3.4 What is Difficult about Translation of Blocks? 19 3.4.1 StarLogo Nova Specific Challenges 19 3.4.2 General Localization and Translation Difficulties 20 3.5 Design Decisions and Implementation for Block Translation 21 3.5.1 Where to Separate Model and View for a Block Label? 21 3.5.2 General String Translation Method 22 3.5.3 Handling Dynamic Labels – Procedure and List Blocks 24 3.5.3.1 Removing Dependency on Parsing Labels 25 3.5.3.2 Handling Translation of a Changing Label 26 3.6 What Other Parts of the Project Page Interface Need to be Translated? 27
3.6.1 Translating Page Names 28
3.6.2 Argument Translations 30
3.6.3 Widget Translations 30
3.6.4 Default Project Template Translations 32 3.7 Full Project Page Translation Pipeline 33 3.8 Translation of the Rest of the StarLogo Nova Website 34 3.9 Proof of Concept – Spanish Translation 35
3.10 Future Work 36
4 Custom Blocks 38
4.1 What is the purpose of custom blocks in StarLogo Nova? 38 4.2 Procedure-Call Blocks vs. Custom Blocks 39 4.3 Custom Blocks in Other Block Programming Languages 41
4.3.1 Scratch 41
4.3.2 Snap! 43
4.4 StarLogo Nova Custom Blocks Design 44
4.4.1 How does a user create a custom block? 44
4.4.2 Custom Block Compilation 50
4.4.2.1 StarLogo Nova Compiler 50
4.4.2.2 Designs Considered for Compilation 51
4.4.4 First Prototype 54
4.4.5 First Prototype Issues 56
4.4.5.1 Custom Block Context Issues 56
4.4.5.2 Customizing a Procedure Block? 58
4.4.6 Future Work 59
4.4.6.2 User Interface Plans 59
4.4.6.3 Sharing Blocks Between Projects 59 4.4.6.4 Viewing and Editing Custom Block Implementations 60
4.4.6.5 Testing and Usage 60
5. Results 60
List of Figures
Figure 1: Project Page Interface... 14
Figure 2: The Workspace... 15
Figure 3: Project Page – SpaceLand (top) and Workspace (bottom) with English Interface Elements... 17
Figure 4: StarLogo Block Specifications... 18
Figure 5: Label for Agent Create-Do Block... 19
Figure 6: Procedure and List Blocks with Dynamic Labels... 20
Figure 7: Javascript Block Object with Label Attribute... 20
Figure 8: Dictionary with English Strings as Keys………... 24
Figure 9: Procedure Block with Two Parameters and List Block with Three Parameters... 26
Figure 10: Page Names………. 29
Figure 11: Arguments for Agent-Create-Do Block……….. 30
Figure 12: StarLogo Nova Widgets……….. 31
Figure 13: Dropdown Language Selection………... 33
Figure 14: Translation of “The World” Block to Spanish……… 34
Figure 15: Translation Tags in Django Template………. 35
Figure 16: Translated Homepage of StarLogo Nova………... 36
Figure 17: Spanish Translated Workspace and Drawer………... 37
Figure 18: Procedure-Call Blocks……….... 40
Figure 20: Scratch Defining a Custom Block……….. 41
Figure 21: Snap Block Editor……….. 43
Figure 22: Scratch Block Customization Sequence……….... 46
Figure 23: Right-Click Menu for Block Customization………. 48
Figure 24: StarLogo Customization Process……….. 49
Figure 25: StarLogo Compilation Structure………... 51
Figure 26: Compilation with Extra Expanded Blocks Layer………. 53
Figure 27: Compilation with saved Compiled AST Nodes………... 54
Figure 28: First iteration of Custom Block Creation Editor……….. 55
1. Introduction
For the past two decades, the MIT Scheller Teacher Education Program (STEP) lab has worked to bring a computational modeling tool into classrooms so that students can learn about science by designing and building their own models of systems [1, 5, 4]. The latest iteration of this tool, StarLogo Nova, aims to increase the accessibility and usability of the original StarLogo agent-based modeling tool. StarLogo Nova brings StarLogo to web browsers and allows users to create models through a graphical block programming language.
The STEP lab would like StarLogo Nova to be usable by students around the world for education, and it has already been used to teach short camps in India and some South American countries. However, since StarLogo Nova is currently only provided in English, students who are not fluent in English see limited benefits. In order to provide StarLogo Nova as a resource
globally, I worked on a system to facilitate the translation of StarLogo Nova into other languages.
This translation system not only helps international students make use of StarLogo Nova, but it also benefits English-Language Learners (ELL) in the United States. In 2015, the
percentage of public school students in the United States who were ELLs was roughly 9.5 percent [10]. Many classes in the US contain a mix of students who have various fluency levels in English, and having a system that enables them to share and compare StarLogo Nova projects in multiple languages will greatly help them collaborate and discuss the models they build.
While translation will improve the experience of building models for students who are not familiar with English, it does not solve problems that arise from unfamiliarity with a different type of language that even fewer students at the high-school level and below have learned – a
programming language. In a two year study run by Gallup and Google, only 40% of principals in K-12 schools within the U.S. reported having at least one Computer Science class available in which students can learn computer programming or coding [11]. While the block-based nature of StarLogo Nova’s programming may be easier for novice programmers to learn, there is still a large vocabulary of computer science related terms that need to be learned in order to create a model in StarLogo Nova. Although there is a lot of merit in teaching students these computer science terms through StarLogo Nova, in the context of building models unrelated to computer science, we want to enable users to define a vocabulary that is close to the topic being modeled in order to bridge the gap between what students are trying to do and what the StarLogo Nova system can understand.
Creating a system to build new vocabularies of blocks is our second project to help further improve the effective use of StarLogo Nova in science classrooms. This system will allow users to define custom blocks with labels that make sense for the specific model they are creating. While custom blocks in block-programming languages are not new, our approach to implementing this functionality explores a more user-focused approach that strays away from the usual procedure metaphor used for custom blocks.
In this paper, I will first cover the challenges and decisions made in implementing a Translation system for StarLogo Nova, and then discuss the process of designing a system for the creation of custom blocks. Both systems aim to improve StarLogo Nova by providing users with alternative representations of the built-in StarLogo Nova blocks so that they can express what they want to do using terms that they can better understand.
Before going into the details of the implementation of these systems, however, I will first review the background and purpose of StarLogo Nova.
2. Background
2.1 Introduction to StarLogo Nova
2.1.1 Computational Modeling
Complex adaptive systems (CAS), systems where a perfect understanding of the individual parts does not automatically convey a perfect understanding of the whole system's behavior [9], are at the core of many problems studied today. Since these systems are composed of many individual components that adapt or learn as they interact, mathematical tools that are typically used to study systems often fall short of fully explaining the development of a CAS and the emergent behavior that may appear. Advances in technology have led to the development of computational modeling as the primary method of studying these systems [2]. Researchers can use computational modeling to study a CAS by simulating the interactions between all the individuals that compose the system.
Technology such as computational modeling has become prevalent in studying all fields of science. However, the way most high school students learn about science has not yet changed to match this trend. Students often learn about complex systems in classrooms as collections of facts or equations to be memorized, leading to misconceptions about how these complex systems work. StarLogo was created under the belief that bringing computational modeling tools to secondary school science courses would both modernize these courses and provide students with a deeper understanding of complex systems that would have stemmed from the development of their own models [1].
2.1.2 StarLogo
StarLogo was developed in the 1990s as a programming language and environment specifically designed to support simulation, design, construction, and testing [5].
This simulation system was meant to be used as a learning tool for students with little prior knowledge in modeling. With StarLogo, students can learn complex concepts by creating their own models as opposed to using a “black-box” model built by someone else as much of the popular modeling software did at the time. Additionally, StarLogo was founded on agent-based rather than aggregate-based modeling because agent-based models are both suitable for the subjects often taught in the K-12 classrooms, and easier for novice students to grasp [1]. While there was much success with StarLogo experiments conducted in classrooms, the MIT STEP lab has continued to iterate on StarLogo to provide greater accessibility and applicability [1].
2.1.3 StarLogo TNG
StarLogo TNG was released in 2008 as the next iteration of the StarLogo agent-based modeling tool. The goal was to provide an interface to agent-based modeling that was more accessible, more appealing, and easier to learn for novices than the original StarLogo [4]. The major changes were the addition of a 3D visualization of simulations using OpenGL graphics and a shift to a block-based graphical language, allowing users to fit together “blocks” of code like a puzzle. Block-based programming has become an increasingly popular way to introduce programming through tools such as Scratch and Alice [3]. With a pallet of commands that can be dragged and dropped, block-based programming eliminates the need to memorize syntax and provides visual cues for what blocks can be fit together. This approach creates an easy to learn
and more visually appealing way of coding for novice users, which is appropriate for the target audience of StarLogo.
2.1.4 StarLogo Nova
StarLogo Nova is the newest version of the StarLogo modeling tool. It takes the 3D visualization and block-programming approach of StarLogo TNG and brings it to the web browser. With StarLogo’s modeling tools on the web now through StarLogo Nova, teachers can bring the ability to create computational models to their classrooms without needing to download specific software. StarLogo Nova was released in beta form in 2014. Since then, development has continued in order to increase the accessibility and usability of StarLogo Nova for students in science classrooms.
2.2 StarLogo Nova Interface
Before I can discuss my work on the system for the translation of StarLogo Nova and the development of custom blocks, first I must define StarLogo Nova specific terms and components that are relevant to these systems.
2.2.1 Agents
StarLogo Nova is an agent-based modeling system. This means that models in StarLogo Nova are built by simulating the actions and interactions between autonomous individuals, also named Agents
, in order to assess their effect on the system as a whole. Users of StarLogo Nova
create programs that control each agent within the model they are creating by arranging a series of blocks in a logical order.
2.2.2 StarLogo Nova Interface – Project Page
The interface for the project page, where students can program and view their models, consists of two main parts. The top part is called SpaceLand
, a 3D world where Agents follow
programs. Agents
in SpaceLand can exist on top of a flat green surface called Terrain.
Figure 1: Project Page Interface
SpaceLand also contains Widgets
which consist of buttons, data boxes, graphs, and other
interactable elements. Users use Widgets
to interact with the model while it runs.
Below SpaceLand
is the Workspace. This is where a user can construct programs to run
their models. On the left side of the Workspace
, there are Drawers. The Drawers contain blocks
Figure 2: The Workspace
The right side of the Workspace
consists of pages where the blocks can be put together in
a logical sequence to write a program. There are two default pages, “The World” and “Everyone,” that have special meaning. Every other page represents behaviors and traits for
Breeds
within a StarLogo Nova model. A user can define a name for a Breed and program
actions for Agents
of that Breed on that page. For example, a user can create a Breed called
Turtle by creating a page named Turtle. Then, blocks on that page all reside within the scope of the Breed
Turtle. The programs written on the Turtle page are all essentially prepended with an
“if I am a Turtle, then...”. A block stack on the Turtle page that performs the function “set my color to green” will run for every Turtle in the model and set each Turtle’s color to green.
3. Developing a Translation System for StarLogo Nova
In order to bring computational modeling to students not fluent in English, the website must be easy for anyone to translate into foreign languages. My goal is to provide a system for the translation of StarLogo Nova into any language by adding an additional layer of abstraction
to the programming blocks and widgets. In the end, translators will only need to be presented with the strings they need to translate and the context of these strings, which makes their job more straightforward.
3.1 Translation in Other Websites and Block Programming Languages
The translation of websites is a problem that has been explored thoroughly over the last decade. The typical solution involves three steps. First, all strings within the website are
extracted and compiled in a single file. Next, this file is sent out to translators who return a new file that contains translations for each string. Finally, all the strings within the website are replaced by their translations in the appropriate language.
Block-programming websites use this system as well. While block-programming projects consist of a large amount of user input, the interesting quality of block-programming languages is that most of the user-input involves moving around predefined blocks with predefined strings. This means that the user-created projects can actually be translated by extracting pre-defined stings from blocks.
In Scratch
, a popular block-programming website, this system of string replacement is
used for translating both the website and blocks within user-created projects. Strings within the system are marked and then extracted to a separate file. Scratch
then makes use of an online
web-based translation platform called Transifex which allows the distribution of the file containing strings from the system to anyone who wishes to help translate Scratch
. This string
replacement system works consistently for translation into any language and has the added benefit of allowing translators to work directly with strings rather than having to search through code for strings. For StarLogo Nova, the translation system I built follows this string replacement
convention, and the difficulty in implementing this system came primarily from changing parts of the StarLogo Nova system so that it could support multiple languages.
3.2 Project Page Translation
StarLogo Nova is built on the Django web framework, so for most of the StarLogo Nova website, strings can be translated as they are in any other Django-based website: static strings within the web page templates are replaced by their translations. The main StarLogo-specific area that must be translated slightly differently lies on the project page, where users interact with blocks to build and view models.
Figure 3: Project Page – SpaceLand (top) and Workspace (bottom) with English Interface Elements
As the user interacts with different elements on the project page, many of the strings that need to be translated are dynamically written on the page rather than statically rendered with templates when the web page loads. The most important elements for users to understand on this page are the blocks themselves, so I began this project by first focusing on how to properly translate the words on blocks.
3.3 Structure of StarLogo Blocks Relevant to Translation
3.3.1 Blocks
The blocks used in StarLogo Nova are defined using a general block-based
programming framework called Scriptblocks. In Scriptblocks, a block is a Javascript object with some attributes. StarLogo Nova stores over 100 specifications for blocks in JSON format that can be passed to Scriptblocks in order to create block objects. These specifications contain information about predefined attributes for different types of blocks. In order to translate the text on a block, the important attributes to consider are the label and the arguments.
Figure 4: StarLogo Block Specifications 3.3.1.1 Block Labels and Arguments
Every block object has a label, which will appear as a text string on the block after the block is drawn. These labels are all defined in English within the block specifications of
StarLogo Nova. Labels for blocks in StarLogo Nova may contain placeholders for variable arguments. Because each block is meant to represent a piece of code, many blocks need to accept user input to specify the value for an argument. Each argument within the string representation of the label is identified by the ‘@’ symbol. A block argument with the name arg0 would be
referred to in a label string as ‘@arg0’. For example, the ‘agt-create-do’ block has a label defined in the block specification “create @arg0 @breed(s)”. With user input, this could become “create 5 Turtles.”
Figure 5: Label for Agent Create-Do Block
3.4 What is Difficult about Translation of Blocks?
3.4.1 StarLogo Nova Specific Challenges
The main difficulty in beginning the translation of blocks is that some blocks have functionality that depends on their English label. For example, StarLogo Nova has a Procedure block tp which users can add parameters and a List
block to which that users can add list items.
When reloading one of these blocks, the label is parsed to determine the number of parameters and list items for each block in order to determine what names can be used for the default string that is added to the label when a new parameter or list item is added. This parsing functionality will be affected if the label is in another language. Additionally, the labels for these two blocks are dynamic, which makes it difficult to translate as the label can change based on user input.
Figure 6: Procedure and List Blocks with Dynamic Labels
Another issue is that the label of a block is saved in English within the block specification when the block is saved. When loaded, the saved specification is read and the block is recreated with its label set to the saved English text again. This label is written on the block when it is drawn, so having the label itself saved and reloaded in English is undesirable for translation.
3.4.2 General Localization and Translation Difficulties
There are also more general translation challenges to keep in mind that are less specific to StarLogo Nova. One significant issue is that the ordering of words in a sentence is not always the same. In some languages, sentence structure is significantly different with verbs and nouns appearing in different orders. For sentences where variable words can be placed within the text, it is important for translators to be able to move the location of these variables within their translations.
Translated sentences might be of different length in another language as well, causing style issues. The standard font in another language might be smaller. In addition to having translations for text, CSS styling might need to be provided on a language-by-language basis as well if the text varies significantly in size or length when translated.
3.5 Design Decisions and Implementation for Block Translation
3.5.1 Where to Separate Model and View for a Block Label?
A major decision to be made for block label translation was at what point to actually translate the label.
I considered two options for where to translate block labels. One option was to leave the label attribute of the block object stored in English and then translate the label only when the block is actually drawn. The other option was to translate the label upon initial creation of the block based on the default block specification and then have the block object contain the label already translated.
Figure 7: Javascript Block Object with Label Attribute
The difference between the two is whether or not the Block object in our system internally has a label that matches the label it displays when it is drawn in the view.
Initially, I implemented the latter of the two options with the internal label saved in the language the user wished to view it in. I first removed saving the full specification of blocks, opting to save blocks by name and a few other unique attributes. All blocks have default
specifications keyed by name, so saving only the name and not the full specification still allows me to rebuild the label from the base specification for a block with that name. The benefits of this are that I know for sure what every label will be in English and can provide translators with the exact strings from the default block specifications that need to be translated. Then I translate the labels that are specified in the block specification and recreate saved blocks with their label attribute translated.
After some thought, however, I realized that the first implementation I considered follows the Model-View-Controller paradigm better, creating a clearer distinction between the external representation presented to the users and the internal representation maintained by our system. If the block object we saved is considered part of the model, we can always maintain the internal functionality and labels in English and only translate the string once it is being written to the view. I maintained the implementation where labels are reloaded from the default specification; however, I moved the actual translation of the label to only occur upon being displayed on the web page.
3.5.2 General String Translation Method
As described earlier, the common way to translate strings in applications is to mark strings that need to be translated in code and simply replace them with their translated string in the appropriate language when pages are loaded. This method handles the possible reordering of words in a different language within a string by simply replacing the entire string. In order to
provide translations with which to replace English strings, a mapping between English strings and their translations is necessary. Storing this mapping of strings separately from the actual code is useful in that it allows translators to focus solely on the translation of these strings without needing to look for where the strings are located. They also can translate without
understanding how the code works. For strings on the project page defined in Javascript, I chose to store these mappings in JSON format, one for each language. There were two options I decided between for keying these JSON dictionaries.
My original plan was to allow coders to specify unique variable names for each English string they add to a block. They could then add the variable name to English text mapping to the English “translation” file dictionary. Translators could use this English file as a base to build up their own dictionaries for different languages.
One advantage of this strategy of mapping English strings to variables is the use of unique keys to avoid conflicts between sentences that use the same words but have different meanings and different translations. Another effect is having all actual English strings located in one place in the same file, so changes to text can happen in the same file. Having all English strings in only one place is both a pro and a con depending on how confusing it is to change the text out of the direct context of the location the text will be located.
In the end, however, in order to keep strings simple and readable for both translators and developers, I decided to forgo the intermediate mapping of English strings to variable names and instead key dictionaries containing translations directly by the English strings to be translated. This way developers do not need to come up with variable names and can just mark the strings to be translated while translators can immediately see what they need to translate without the added
layer of a variable name. In order to handle the issue of conflicting keys, I provide the option of adding a secondary key for context. When there is more than one translation for a string, the system can then look to the secondary context key to retrieve the correct translation.
Figure 8: Dictionary with English Strings as Keys
As described in the earlier section about Block Labels and Arguments, the strings for block labels also contain placeholders for arguments marked by the “@” symbol. The names of these arguments are not translated as these will be replaced with input elements once the label is actually written on the interface. Translators can move these argument placeholders wherever they want within their translated string if the sentence structure in the language requires it.
3.5.3 Handling Dynamic Labels – Procedure and List Blocks
While the general string translation method works for most block labels, as in the
translation difficulties section, Procedure and List blocks have labels that are dynamic. Users can add lines to the label by adding parameters to Procedure blocks and list items to List blocks. For these blocks, the string replacement method for translation does not directly work. Furthermore, the old implementation of these blocks relied on parsing the label to determine how many parameters or list items the block had before adding and deleting parameters. In order to be able to translate the labels for these blocks, I needed to first remove the existing dependency on parsing the label and then handle the user added changes to the label.
3.5.3.1 Removing Dependency on Parsing Labels
The reason both Procedure and List blocks have dynamic labels is that both of their labels essentially contain lists of additional lines that can vary. In the case of Procedure blocks, there is a list of lines representing parameters to be passed into the procedure the block represents and for List blocks there is a list of lines representing items contained in the list the block represents. However, instead of the block storing an actual list to represent the lines contained within the label for each block, the string representation of the label is the only part of the block that contains the information about what names in each list should be displayed in the label. Since this is the case, in order to determine names for new parameters when adding items to these blocks, the original implementation of these blocks had to parse the label in order to determine what parameter names were already in use.
In order to remove the dependency on parsing labels to determine what additional lines are added for each block, I decided to have each of these blocks store an actual list of IDs for each line. Each ID is enough to represent an entire line in the list of lines within the label of a block. For example, a procedure block might have two parameters – Parameter 1 and Parameter 2. Then the lines in the label that represent each parameter are, “@minus1 @param1
@paramtype1” and “@minus2 @param2 @paramtype2.” So all I need to know to retrieve what lines I need to add to the label of the block is that the block contains a line with the ID 1 and another with the ID 2. This pattern within the label for Procedure blocks also appears within the label for List blocks.
Figure 9: Procedure Block with Two Parameters and List Block with Three Parameters
Based off this structure, if I keep a list of line IDs, I can rebuild the label for both Procedure and List blocks without having to save the full label and then parse the label again.
To represent a list of IDs, I created an ExtendableList object. An ExtendableList is essentially a Javascript array, but it keeps track of the largest ID added to the list so that when a new item is added, we can generate a new default name for the item that does not interfere with any already existing items. So if a List or Procedure block has items 1, 5, 3, and 7, the
ExtendableList object keeps track of the fact that 7 is the largest number added to the list, and when a new item is added, it will have the ID 8.
I save this ExtendableList as a hidden argument within Procedure and List blocks. When these blocks are loaded, rather than parsing the label to find IDs, I can simply retrieve the ExtendableList which contains all the IDs for elements in the block.
3.5.3.2 Handling Translation of a Changing Label
Although the label for Procedure and List blocks as a whole are dynamic, they are still composed of separate static strings. We must add a line to the label for each parameter or list item the block has, but each line itself has a given format that can be translated beforehand.
Saving an ExtendableList containing element IDs handles the issue of knowing what these lines to be added to the label are. We can then rebuild the list portion of the label by adding new lines for each item of the list containing the proper ID. It turns out that each line that can be added to the label for both Procedure blocks and List blocks only contain argument placeholders so each individual line does not need to be translated. Instead, we only need to translate the beginning and ending of the string that is in English and then insert the strings for each line that needs to be added in between. However, if in the future this changes to contain English words, this format allows those lines to be passed to a translator so that the block can still be fully translated.
For List blocks, there is no ending line so we can add lines for each element after the translating just the beginning. For Procedure blocks, we translate the beginning of the string, “procedure @procname\n”; add the dynamic number of lines depending on what we have saved in the ExtendableList for the block, and then translate the end of the string, “@plus add
parameter \n@code \nreturn @returntype.” The final line may have an extra argument
placeholder for the value of the argument if the procedure actually returns a value, which leaves two different ending strings to be translated for each situation.
Altogether, this fully translates both List blocks and Procedure blocks by breaking their labels into the base static strings that compose them, translating each of these static strings, and then putting them back together in the correct order.
3.6 What Other Parts of the Project Page Interface Need to be Translated?
While block labels are the most prominent user-facing strings that need to be translated, the StarLogo Nova interface has many other elements that also must be translated. There are
buttons, widgets, page names, right-click menus and more. However, this leads to another decision of what actually should be translated.
The short answer is that we want to translate every StarLogo Nova provided string while leaving user input alone. As it is extremely easy to lose context from user input, best-effort translations of anything a user types are likely to fall short, so in general it is better to leave user input alone. Unfortunately, this means that if a user wants to share their project with someone that speaks a different language, the elements that they name in their own language will not be translated, but we feel this is better than providing a translation with the incorrect
meaning.
There are some cases where deciding what to translate is not as straightforward as ignoring user input though. These cases generally mix user input with StarLogo Nova provided strings. One such area is the name of a new page in a project.
3.6.1 Translating Page Names
A user can create and name new breeds of agents in their StarLogo Nova model which creates a new page. In this case, since it is user input, we should not translate any of the pages they name. However, every project by default has an “Everyone”
and a “The World” page.
These default names lead to a somewhat interesting problem. We definitely want to translate the “Everyone”
and “The World” page titles as they are not user input, and it is really important for
users to be able to understand what those page titles refer to in order to develop their models. These are surface level translations, however, and the internal representation is still the English words. So if we do translate these titles, there end up being some issues with page name
Figure 10: Page Names
For example, the “Everyone”
title will be translated to “Todos” in Spanish. Now, if a
user in the Spanish locale wants to name a page the English word “Everyone,”
we cannot let
him. It conflicts with the internal English name of the “Everyone”
page which cannot be allowed
as two pages cannot have the same name. Additionally, “Everyone”
is especially important as a
page and it functions differently from other user-created pages. So we must notify the user that he cannot name the page “Everyone”
because the name is already taken despite him only seeing
the page named “Todos.”
Furthermore, he might want to name a page “Todos.” Technically the
“Todos”
page is internally named “Everyone” so the name “Todos” is available for the user to
use. However, it appears to the user that a “Todos”
page already exists despite the system
allowing him to create a page with the same name. In this case, we must prevent naming conflicts with every translation of “Everyone”
when the user wants to name a page. If we take
this approach of preventing naming conflicts with every translation of a word, then that means that an English user cannot name a page “Todos
” because it means “Everyone” in Spanish even
if the user does not know the meaning which can lead to further confusion.
For the time being, to address this issue, I maintain that the default page titles will be translated, while users are only prevented from naming pages by the English names “Everyone” and “The World.”
While this does allow a user to potentially see pages named “Todos” in their
this is too confusing or whether we should continue to resolve name conflicts between the default pages this way.
3.6.2 Argument Translations
Block arguments are another area where user input mixes with predefined strings. As described earlier, block arguments allow users to specify parameters for their code. For example, for a create block, users can specify the name of a breed for what type of agent they want to create and a number for how many to create.
Figure 11: Arguments for Agent-Create-Do Block
The general rule followed here, as usual, is that user input is not translated while statically defined strings are. This means that mostly predefined lists that users select options from are translated such as colors listed in the color block, and shapes listed in the shape block. Some lists, however, have input that changes depending on users. Specifically, any block that has a list argument containing traits will have a mix of predefined default traits such as shape, color, and size and user-created traits. I handle this similarly to the issue of page names. The default words are translated, while anything else is left alone allowing for lists with mixed language options.
3.6.3 Widget Translations
The last interactive parts of the project page to be translated are the widgets. Widgets allow users to have their coded models respond to input while the model is running, or to
monitor information in their model. They can draw line graphs based on data within their model, or have pieces of code that work upon pushing a button.
Figure 12: StarLogo Nova Widgets
In general, the names of these widgets are all user specified, so those do not need to be translated. Most of the translation work comes in translating the interface used to create each widget. However, after receiving some feedback from our Spanish translator, an interesting problem came up where there were some widgets’ names that he asked us to translate. Every project is loaded from a default template project which comes with default “Setup
” and
“Forever
” button widgets and I was asked to translate these buttons. I had some reservations
about this as these buttons are different from default page titles and default traits. The default traits are always shape, color, and size and the default page titles are always “Everyone
” and
“The World,
button widgets can be deleted or renamed by users. These buttons are essentially user input that we do not want to translate in case we translate out of context. For this reason, I decided not to translate the widget names in the default template.
3.6.4 Default Project Template Translations
As described in the previous section, when a project is created it is loaded from a default project template that already contains some preset English widgets. I also decided not to translate the names of these preset widgets. In this case, why not provide different default templates for each language?
Providing starter templates for different languages is an option I considered and is one that we can potentially implement in the future. The reason I would prefer to use the same base project template, however, ties into the fact that we want StarLogo Nova projects to be shareable between users with different languages and still be the same project. This is an important distinction to make. A user that creates a project in English should be able to share it with someone in a different language without making a copy of it so that they can switch between languages within a single project. More significantly, when we introduce real-time collaboration, we want users to be able to work on the same project in two different languages at the same time which cannot happen if what is seen in a different language is actually just a copy of the original project. If a project is loaded from a starter template with a different language than English, then it is loaded from a copy of the starter rather than the same one being loaded in English, which can cause problems when comparing and sharing these projects across languages.
That said, while I ruled out translating the default template widget names and creating different language default templates in this first implementation of translation if user feedback about this feature is poor, these are reasonable options to implement and test.
3.7 Full Project Page Translation Pipeline
With this translation system, users can begin by choosing their language from a dropdown displaying the enabled languages for StarLogo Nova. This ties into Django’s own internationalization system for web pages and sets a server-side language code to the selected language. The framework defaults to the user’s browser language based on the browser’s Accept-Language header.
Figure 13: Dropdown Language Selection
With the language selected, when a page is loaded, the client receives information from the server about what the current language code is. Any strings defined in Javascript are passed to a translate function which simply does a dictionary lookup on that string in a stored dictionary for that language. The string is then replaced by the translated string for the current language.
As we currently only have Spanish and English enabled on the site, we only store one dictionary at the moment. For English, we do not need a dictionary as it is the default language that we use to develop the site. Since there is only one dictionary and it is relatively small, I currently load the Spanish dictionary as a static text file with the client. In the future, if we need
to support other languages, we can keep the dictionaries on the server side and then the client can request the dictionary for a given language in JSON format.
Figure 14: Translation of “The World” Block to Spanish
3.8 Translation of the Rest of the StarLogo Nova Website
For the rest of StarLogo Nova, I rely on Django’s native internationalization framework to handle translation of static templates. Strings that need to be translated are compiled in dictionaries keyed by English strings similarly to how it is done for the Project Page Javascript translations. Each string in a template to be translated is marked for translation as shown in the figure below.
With Django handling the translation of static strings in templates, the entirety of StarLogo Nova is now translatable.
Figure 16: Translated Homepage of StarLogo Nova
3.9 Proof of Concept – Spanish Translation
In order to show that the full translation system works, I worked with Cristián Rizzi Iribarren, one of our Spanish-speaking partners from Argentina who is an expert StarLogo Nova user, to translate the full site into Spanish. I sent Cristián the dictionary files for mapping English words to Spanish containing only English keys, and he filled them out with the corresponding Spanish translations.
Figure 17: Spanish Translated Workspace and Drawer
The translation system with Spanish translations has been released on the StarLogo Beta server and tested by a few Spanish speakers with positive feedback.
3.10 Future Work
While the translation system has been tested by a few people on the beta server, in the future it would be useful to have more user testing and feedback. User feedback can help better decide what parts of the interface make sense to translate and what does not quite feel right.
Additional features such as using the search bar in different languages to find the same project could be an interesting project as well.
Since we want this system to work for all languages, it would definitely be useful to test how the system works with languages with significantly different syntax and structure than English. Will string replacement still work as well with Chinese characters? Additionally, with more languages that have varying word sizes and standard fonts, more specific CSS might need
to be added on a per language basis. Currently, as Spanish is very similar to English, we do not need any specific CSS as simply adjusting our CSS to cover both English and Spanish text is enough. However, for significantly different languages we can have language-specific CSS by altering the class element for HTML elements in the websites templates based on the language code variable stored on the server.
Another related project that can be developed is creating a user interface for translators to translate strings. At the moment, translators need to be sent files with a list of English keys, and they need to map all the keys to their translations within that file. It could be a lot easier on the translators if an interface is built to process these dictionary files and present the English words to the translators one at a time.
Altogether there is still a lot of work that can be done to improve the StarLogo Nova translation system in the future.
3.11 Translation System Results
Overall, the translation system developed for StarLogo Nova met three major objectives. First, the system makes it easy for translators to see what needs to be translated by following the standard convention of isolating strings within the system for translation. Second, areas of StarLogo Nova that depended on the English language were altered so that functionality no longer depends on the text on the blocks. Finally, projects are only translated on the view-level so that a project can be opened in multiple different languages, allowing for real-time
4 Custom Blocks
With a functional translation system, I next began working together with Hyeonsu Kang, another researcher at the MIT STEP lab, to create a system that allows for the creation of custom blocks. Custom blocks are a way for users to create and name their own blocks to be used in their programs. For example, a user might want to create a custom block for random walking that contains the functionalities of the move forward and turn blocks within a single block. This system can help us make a vocabulary closer to the topic students are modeling in order to help students better express what they are trying to accomplish by using blocks that have less
computer-centric labels.
In some ways, custom blocks are similar to translated blocks in that they can be viewed as a cosmetic change that lies over existing StarLogo Nova blocks. The main difference is that a custom block may represent a whole stack of StarLogo Nova blocks while a translated block always represents a singular block. The first question we tried to make clear in deciding how to design custom blocks was what we want custom blocks to be used for within StarLogo Nova.
4.1 What is the purpose of custom blocks in StarLogo Nova?
For StarLogo Nova, we have a few specific goals we want custom blocks to help us achieve.
The first and foremost use for custom blocks in StarLogo Nova is as an abstraction tool. Both programming and modeling are difficult, and using custom blocks to abstract the smaller programming and modeling details away can potentially help students understand the science concepts behind the models they are creating without being bogged down by learning how to use
the StarLogo Nova system. In designing the functionality of custom blocks and how users interact with them, this is the primary concern we keep in mind.
An additional use for custom blocks is to be able to condense the number of blocks that appear in the code and allow for easy reuse of code without copying full stacks of blocks. Sometimes coding will require the creation of large stacks of blocks that fill up a whole screen, so being able to reduce the congestion of the programming area by creating reusable custom blocks to represent larger stacks is extremely convenient for users both reading and writing the block code.
A third possible long-term benefit is providing expert users the possibility of creating blocks that do not depend on existing StarLogo blocks. Perhaps custom blocks could be used to import existing Javascript libraries to perform tasks not possible currently in StarLogo. While the security of a user inserting their own Javascript would be an issue that needs to be resolved, the ability to code outside the confines of StarLogo blocks can definitely be useful and a potential option to leave open when designing custom blocks.
4.2 Procedure-Call Blocks vs. Custom Blocks
As already stated, the base functionality of custom blocks is to represent and run the code of another stack of actual StarLogo blocks. In this case though, StarLogo Nova already has a Procedure-Call block system that performs this functionality. Users can define procedure blocks that contain a stack of blocks and then use a call block to run that stack of blocks. What is the difference between Procedure-Call blocks and custom blocks?
Figure 18: Procedure-Call Blocks
There are two major benefits for custom blocks over the existing Procedure-Call blocks. The first is that it provides the user with the ability to create a more descriptive name for their procedures using more natural language. Instead of a block named “call: Jump” that takes in one parameter for how high, we can have a custom block that says “jump Five feet.” Users also can potentially customize color and shape of blocks which can provide further details about the actual functionality of their custom blocks.
Figure 19: Customized Jump Block (left) and Procedure-Call Jump Block (right)
An additional benefit is that custom blocks can hide their implementation outside of the
Workspace
. For Procedure-Call blocks, a Call block must call on a Procedure block with the
implementation existing in the Workspace
. Custom blocks can represent the whole procedure
model, they can potentially view the implementation of a custom block by right-clicking and expanding the implementation of the custom block rather than digging through the Workspace
to
find where a procedure is defined as they currently have to with Procedure-Call blocks. From an educational standpoint, hiding the implementation is a useful abstraction for students that are focusing more on studying a model of science rather than learning programming techniques.
4.3 Custom Blocks in Other Block Programming Languages
Custom blocks aren’t completely new. Scratch
and Snap! both have their own versions of
custom blocks, and in designing custom blocks for StarLogo Nova, I started by looking into how they work in these other block programming languages.
4.3.1 Scratch
Scratch introduced custom blocks to its language in version 2.0. Their interface allows a
user to create a new block, construct the label for this block, and then afterwards use a separate
define
block to determine what code will be run by the custom block.
Scratch
has a “Make a New Block” popup to construct the label of a custom block where
a user can build the label for a block using segments of text or various inputs. The users can then
define
custom blocks in the scope of a particular sprite (the Scratch equivalent of a Breed) in
their project.
For sharing custom blocks across projects, Scratch
has the concept of a block pack. Block
packs are projects that contain custom blocks for use in other projects. These block packs function similar to libraries in languages such as Java, Python, and C.
Scratch
custom blocks are meant to represent procedures, functions, or methods as
described by the Scratch
wiki. The design of custom blocks for Scratch is largely meant to allow
for “reuse of a sequence of blocks in different parts of code, without duplicating the blocks each usage [6].”
The custom block creation system in Scratch
is similar to defining procedures in a
text-based programming language. This can be useful in helping Scratch
users transition into
useful more conventional textual languages, however it can be difficult for novice programmers to learn. The concept of naming parameters in a label to be used in the implementation of a custom block can be confusing and does not appear anywhere else in Scratch
.
Additionally, Scratch
custom blocks only exist within the scope of the sprite they are
created in. This means there is no confusion about custom blocks that contain variables that depend on one sprite being copied to another sprite. However, there is a large drawback of this implementation that requires users to duplicate their custom block definitions within every sprite that needs to use the same functionality as a sprite cannot directly access and use a custom block from a different sprite.
With custom blocks being defined locally within sprites, Scratch
also does not provide
the option of hiding the implementation of a custom block. The definition of every custom block sits within the programming space for a sprite alongside the blocks that call them.
4.3.2 Snap!
Snap! is another block programming language that has implemented custom blocks.
Instead of a “define” block that exists in the scope of the project, Snap!
opens up a block editor
that allows users to define custom blocks with a global scope.
Figure 21: Snap Block Editor
To share these blocks, Snap!
provides an option for users to select blocks they would like
to export. Snap!
saves the selected blocks in a file in xml format. To add these blocks to another
project, a user can import the xml file to a different project.
Snap!
follows a similar pattern of block creation to Scratch where the label of the block is
created before the implementation. It differs in that the user can choose to define a global or a local custom block that exists in a separate “Block Editor” window. This provides the benefit of
being able to reuse the same custom block across different sprites without confusion as the implementation of these blocks no longer sits within the page for a particular sprite.
In Snap!
users can right-click on a custom block to pull up the block editor window and
edit the implementation of the block. In addition to allowing for globally defined custom blocks, this also reduces clutter on the programming pages for sprites as the definition for a custom block is temporarily hidden unless a user chooses to access it. However, this also can introduce some confusion about what editing a custom block will do. Being able to right-click every instantiation of a custom block to edit it can make it seem like there is a one-to-one relation between the instance of the custom block the user is editing and the block stack that appears in the block editor that opens. Users might fail to realize that editing one instance of a block will change the functionality of every instance of it. Despite this drawback, we feel that Snap!
’s
method of temporarily hiding the implementation in another window is very powerful and is something we can improve on in StarLogo Nova.
4.4 StarLogo Nova Custom Blocks Design
Taking ideas from both Scratch
and Snap, we hope to improve on them in our design of
custom blocks for StarLogo Nova.
4.4.1 How does a user create a custom block?
One of the first topics we thought about was what the flow for creating a custom block should be for a user. This decision boils down to what metaphor are we using for our custom blocks. Do custom blocks represent a replacement of a stack of blocks similar to a C-style Macro or do they represent a call to a block implementation defined as a Procedure? It seems that in
Scratch
procedure. In this case, the custom block creation process reflects the process of creating a procedure. Creating a label is similar to defining a procedure with a name that is more human readable. Within the label, we can leave gaps for parameters to be passed. Then a stack of blocks is created to represent the code that the procedure will execute. Scratch
and Snap! both follow
this mental model of creating a custom block as if defining a procedure. In both Scratch
and Snap!, a user clicks on a “Make a Block” button which allows them
to start by building a label that combines pieces of text and then sockets for user input. Then after building the label, they can begin building out the functionality of the custom block. Defining functionality for the custom block is done by dragging blocks underneath a new “hat” block which they call the prototype for the custom block [7].
This process mimics defining a procedure in a text-based programming language. First users begin by naming a function, and then they write the functionality. Designing a process similar to Scratch
and Snap! was the first option we considered for how users could create
custom blocks. There is a clear entry point to the creation process with a single “Make a Block” button and is similar to coding procedures in textual languages which can help users learn this general concept of procedures in the transition from block programming to learning text-based programming.
Figure 22: Scratch Block Customization Sequence
However, for users not already familiar with concepts of procedures and abstraction, the process of defining a name and then functionality for a procedure might not be the most natural. Often, a programmer will think of the functionality first for a piece of code before creating an abstraction for it by defining it with a name and parameters. Even after a programmer defines a procedure, he might need to go back after implementing the procedure and correct the number of parameters that need to be passed in. It is possible that this “label before implementation”
method of procedural abstraction causes confusion among novice block-programmers. An exploratory data analysis of 233k nonempty and shared Scratch
projects was
conducted in 2016 by Auvaloglou and Hermans[8]. They found that only 7.7% of these Scratch projects used custom blocks with the majority of these custom blocks only ever being called
once while 5% were never called at all. The majority of custom blocks were defined with no parameters while almost 20% had only one [12]. A recent study of how procedure declaration blocks are used in App Inventor, a block-programming language used for building Android apps, found similar results in the use of procedure declaration blocks within App Inventor. In this study conducted by Turbak and Mustafaraj it was found that fewer than 20% of the projects created by prolific users contained any procedure declarations while 10% of procedures within those projects were never called [12]. Additionally, the majority of procedure declaration blocks had one or no named parameters. It seems that it is not always clear to users that a call block is needed for a procedure declaration, and named parameters are also unintuitive to use. The need for a call block and named parameters comes partly from the “label before implementation” method of creating procedures in App Inventor and custom blocks in Scratch
and Snap!. Turbak
and Mustafaraj suggested that one improvement App Inventor can make to increase usage of procedure declarations would be to recommend that users turn a stack of blocks into a procedure whenever they copy a large stack of blocks rather than always having users start from defining a label. We expanded on this concept in our design of custom blocks.
Instead of imitating the procedure-like metaphor used by Scratch
and Snap! We decided
on a different method for creation of custom blocks based on the idea that it is more intuitive for users to think of functionality first and then define a procedure to capture that functionality. Rather than a user initiating the custom block creation by defining a block label and then dragging the block to it to define functionality, they can instead take a stack of blocks from the
Workspace
and then convert the functionality of the already existing stack of blocks into a
macro where a custom block directly represents a stack of blocks and is replaced by that stack wherever it appears.
Figure 23: Right-Click Menu for Block Customization
In addition to being a more intuitive process, this method of creating custom blocks can also simplify the labeling of the new block. As the implementation of the custom block is already built before the label is created, we already know what parameters can be used based on what parameters there are in the implementation. This way we do not need a complicated label creator that requires users to define different named parameters and their types and then ask them to drag those named parameters into their block implementation like it is done in Scratch
and Snap!.
Instead, we can just provide them with a list of the already existing arguments in the block that they can use as parameters for their custom block. For example, if a user chose to customize a stack of blocks consisting of a forward block followed by a turn block, we could provide the user with a list of possible parameters consisting of the (number of steps)
argument from the forward
block and the (degrees to turn)
argument from the turn block. Then the user could create the
custom block “move forward (number of steps)
steps and then turn (degrees to turn) degrees.”
They could also choose not to use the provided arguments as parameters to their custom block as well. A “move forward 5 steps and then turn (degrees to turn)
users, this method used for mapping arguments from the implementation directly to the label could be much more straightforward than the usual named parameter method mentioned earlier.
This method of custom block creation also means that users can create and test their implementation for their custom block in the Workspace
first before defining the label for the
new custom block. This way a user can know that their custom block should function correctly the moment the actual block is formed.
Figure 24: StarLogo Customization Process
There are of course a few tradeoffs in this strategy of creating the label after first creating the block implementation though. For one, this means that recursion will not be supported by custom blocks. If the implementation of the blocks is created before the label is, there is no actual way to call itself within the implementation. It is possible to work around this by having a placeholder name by which to refer to the custom block before the label is actually created. However, the first implementation of custom blocks likely will not support this. StarLogo Nova’s original procedure call blocks will still support recursion if it is needed.
Another tradeoff is that with this method of customization, users may end up associating a custom block with a specific stack of blocks. They might imagine a custom block just being a certain stack of blocks collapsed. In this case, if they edit the block, they could potentially not realize that it will modify every instance of that custom block. A possible solution is to have the
custom block added to the Drawer
along with the Workspace when it is created and then only
allow editing of the custom block through the Drawer
. In this case, it will be clear that editing
the custom block will affect every copy of it.
However, overall this implementation of the block customization process feels fluid to other members of the development team who saw early prototypes, but further user testing still needs to be done to see if this design is also intuitive to less experienced programmers.
4.4.2 Custom Block Compilation
The next issue to tackle after deciding how the custom block creation flow should work is determining how the custom blocks will compile. We can cosmetically replace a stack of blocks with a new custom block with a different label, but it also needs to be able to execute the code properly. First I’ll go over current way StarLogo Nova compiles a block program.
4.4.2.1 StarLogo Nova Compiler
In StarLogo Nova, the blocks that users interact with sit at the highest level. One level down, an Abstract Syntax Tree is constructed from the blocks that exist on the upper level. Each block is associated with a single node of the Abstract Syntax Tree (AST), and the hierarchy of the tree is decided by how the blocks are associated. When the “Run Code” button is pressed, the compiler walks through the ASTs, and each node emits Javascript depending on which block that node represents. This Javascript code is put together so that we can now run what is essentially a Javascript program.
