Greetings!

Over the last two years, I've been working at a non-profit organization called PhET Interactive Simulations. I'd love to tell you all about it! This is a first of a two-part blog series about my experience at PhET.

Introduction

What is PhET?

PhET Interactive Simulations is a popular, award-winning project that creates free ed-tech science simulations used worldwide.

How did I find out about PhET?

I actually remember the first time I was exposed to one of their simulations. I was in 8th-grade earth science, learning about the carbon cycle, when my teacher presented a simulation called The Greenhouse Effect.

I distinctly remember how much better I could comprehend the carbon cycle just by simply engaging with the simulation. By literally seeing invisible photons from the sun interacting with the earth, I could conceptualize how something completely invisible creates what we call the greenhouse effect.

Since then, many of my physics, chemistry, biology, and even math classes have used PhET simulations to teach foreign concepts. Fast-forward a few years, when I found out the project was based at my local public university, I immediately reached out; I had been eager to apply some of my newly acquired programming knowledge. Strap in as I take you through my internship experience at PhET!

Vector Addition

My task for my first summer at PhET was to "convert" the legacy Adobe Flash Player simulation titled "Vector Addition" to HTML5.

The legacy version of Vector Addition, which probably won't run 😔

Brief Historical Context

PhET had actually originally written all their simulations in Java because of its compatibility with popular operating systems of the time. Java quickly became outdated on newer systems (e.g. iPads and Chromebooks don't even run Java at all), so PhET then started writing simulations with Adobe Flash, which was quickly picking up in popularity.

However, as security issues with Flash were exposed, it slowly lost popularity, development stopped, and modern browsers dropped support. Finally, in 2013, the PhET project switched all development to HTML5.

HTML5 - Misunderstood

At PhET, HTML5 refers to the general idea of writing simulations that run natively in the browser. It does not refer to language that was necessarily used. In fact, throughout my two years at PhET, I did not write a single line of HTML; it's viewed as an entry point into Javascript, which handles all simulation element generation.

"Conversion"?

My jaw dropped when I first saw the design document for the HTML5 version of "Vector Addition." The HTML5 version was hardly a "conversion" at all — it was rather an entire rewrite of the flash version of "Vector Addition." With multiple screens and features like a draggable origin, vector components, vector equations, different vector/coordinate representations, and so much more.

Understandably, "converting" platforms sounds like I just tediously copied the source code and changed the syntax. But in reality, it was more of a "redo" than a "conversion"; in fact, I rarely even referred to the legacy code when I wrote the HTML5 version. Also, many of the software patterns and standards had significantly changed since the legacy version was first created. So I decided to start completely from scratch — as if the legacy version didn't even exist.

Features

The "Equations" screen of the final version of Vector Addition.

Screens

In a PhET Simulation, a "screen" refers to one of the tabs at the bottom of the simulation.

Carousel at the bottom of the simulation that allows you to select between screens.

Each "screen" is essentially a separate embedded simulation with different features and pedagogical purposes.

Here's a brief overview of the screens for "Vector Addition":

1. Explore 1D - visualize how vectors add together in 1D.
2. Explore 2D - visualize how vectors add together in 2D and explore rectangular and polar representations of vectors.
3. Lab - interact and compare how vectors add within two separate sets of vectors.
4. Equations - discover vector coefficients (like how $3\vec{v}$ scales $\vec{v}$). Then, discover vector equations (including subtraction!) like $2\vec{d}-3\vec{e}=\vec{f}$.

Scenes

Unfortunately, this is where the terminology gets confusing. A "scene" can be thought of as simply a screen within a screen.

For vector addition, every screen has different "scenes." For Explore 1D, there are "scenes" for horizontal and vertical vector addition. On every other screen, there are "scenes" for polar and rectangular representations of vectors.

Polar vs. Rectangular "scene" buttons, which appear on the bottom-left of every screen except "Explore 1D."

Implementation

Model-View-Controller

The central architecture that is used to implement a PhET simulation is called Model-View-Controller (MVC).

Essentially, the source code is split into three distinct categories.

1. Model - data and logic of the simulation. A model can be thought of as a representation of the entire simulation and a framework for what is rendered. It can do everything that the simulation can do and is the central component of the simulation. The model is the first thing that is instantiated when the simulation starts up.
2. View - presentation of the model to the user. In other words, a view's responsibility is to display what the model's state is in the viewport (the browser).
3. Controller - communication between model and view (e.g. handling user input and updating the model).

Flow chart of the Model-View-Controller architecture.

Some of the benefits of this framework are:

• Changing styling doesn't require touching application logic.
• Support for multiple view representations for a single model (the model is oblivious of the view).
• Improved maintainability with more modularized code and a distinct separation of concerns.

Basic MVC Overview for Vector Addition

Here's an outline of the core files that are a part of the MVC architecture for Vector Addition.

Model

• Graph - models the bounds and tracks "graph"-like attributes, like the orientation and the coordinate system. These attributes are essentially the different scenes!
• Vector Set - groups vectors and the sum vector as a unit.

You can see the full model implementation here.

View

• GraphNode - view representation of a Graph.
• VectorSetNode - view representation of a Vector Set.

You can see the full view implementation here.

Vectors: Models and View

One of the things I left above is the actual vectors, which were one of the most interesting things to implement.

One of the reasons was how many different types of vectors that appear within the simulation.

1. Interactive "Main" Vectors - the vectors you drag around and interact with, which compose the sum.
2. Component vectors. In the implementation, "main" vectors are thought to be composed of two component vectors, which can be displayed for learning purposes.
3. Sum vector - A vector that represents the sum of a set of vectors.

Additionally, on the equations screen, there are many new features, which introduces two new vector "types":

1. Equations vectors - can scale based off a coefficient, like $3\vec{v}$.
2. Base vectors - the "original" vector of an equations vector (e.g. the base vector for $3\vec{v}$ is $\vec{v}$), which is needed and shown for pedagogical purposes.

To account for all the different types of vectors, a class hierarchy was created.

The model class hierarchy for vectors.

The view class hierarchy for vectors.

Accounting for Screen Differences

One of the biggest challenges for the implementation of Vector Addition was accounting for seemingly minor screen differences. Each screen is similar, so much of the code for the entire simulation is located in the /common directory. The challenge was to put as much generalized code into this directory and leave as little screen-specific functionality in the directories for each screen as possible.

Vector Creation

To illustrate this, I wanted to give an example: the vector creation system. In the simulation, the user can create new instances of vectors by dragging them from the toolbox.

Vector Toolbox Panel, shown for the "Explore 2D" screen.

However, there are fundamental differences in how this process works for each screen. The biggest difference is that for Explore 1D and Explore 2D, the panel has three fixed vectors that aren't replaced. In the image above, once vector $\vec{b}$ is taken from the panel slot, that slot is empty.

Vector Toolbox Panel, shown for the Lab screen.

But for the Lab screen, each slot has an infinite supply. Additionally, there are two different vector sets (orange and blue), and the panel needs to account for this.

The equation screen differs entirely in that it doesn't even have this panel at all. Vectors are created at the start and can neither be destroyed nor created.

The visual appearance of the panel also differs from screen to screen.

In summary, A slot can differ in:

• The supply of the slot (containing one vs. infinite supply).
• The icon and initial components of the vector (vectors on Explore 1D are horizontal/vertical).
• Only Vectors in Explore 1D and Explore 2D are created with a symbol (like $\vec{a}$, $\vec{b}$, or $\vec{c}$)
• Other visuals, such as color and size.

Yet, the system for how vectors are created was generalized for the Explore 1D/2D and Lab screens despite the differences. You can find most of this implementation logic here.

What I Learned

Before the summer, I hadn't been exposed to what it was like to develop software professionally. This was the first time I was exposed to many industry standards. I learned about common practices like linting, code reviews, testing, etc.

The biggest thing that I appreciate about development at PhET was how rigorous and thorough their processes are. Seriously, I still cannot get over how well documented the code base is. It's actually borderline absurd. This was a huge shock for me considering my experience level at the time. I saw first-hand how prioritizing well-written documentation pays off and makes the development experience so much more enjoyable. And yes, this was a mentality that took time to buy into. I would say that before PhET, my mentality was quite the opposite. But eventually, working with it hands-on shifted my perspectives, and I embraced the obsessiveness in quality that characterizes the entire code base.

I was also amazed by how much thought was put into the infrastructure around testing and developing. For example, it is common to test changes with fuzz tests, which are incorporated into every simulation. In fact, PhET even has an automated server that tests changes to all of their simulations on the cloud, using puppeteer. It truly amazed me how much thought goes into ensuring the user experience of the end-user.

Acknowledgments

I want to give a huge thank you to Ariel Paul, my manager, and Martin Veillette, my mentor and coworker, for this amazing experience. Ariel has always welcomed me with open arms and has always been willing to accommodate my ever-changing interests with side projects and such. He's also not just a great leader, but someone who I feel comfortable chatting about life with outside of work. Martin was always teaching me about software engineering and answering all my questions. He was also an amazing coworker and put me in a position to succeed and take over the project.

Stay Tuned

Thank you for sticking with me! I'd like to remind you that this is the first of a two-part series about my PhET Internship experience!

Stay tuned for my next post, where I'll be outlining the rest of my work at PhET and discussing why ed-tech truly matters!

- Brandon