14 Years of a Learner-Centered Python IDE

I recently discovered that the latest version of our Python IDE for learners, JES (Jython Environment for Students), passed 10,000 downloads (see count here) — 10,562 when I started writing this post. We created JES in 2002 in support of our Media Computation course at Georgia Tech, which is a required course for students in our colleges of Liberal Arts, Business, and Design. Schools that adopted our Python Media Computation textbook have also mostly adopted JES, or used options that support the same libraries, such as Pythy or Pyjama. The current download count is probably an underestimate of users, since some schools download JES only once and then distribute it across campus.

Most student Python programmers use IDLE, the integrated development environment (IDE) provided with Python. While Python is more learner-centered than many languages used by professionals (see principles for choosing learner programming languages), the IDE should also be tailored for learners. Learners have different goals and needs than professional programmers. They need programming environments that take a learner-centered design approach, like JES or DrPython.

JES is likely one of the most-used pedagogical programming environments for Python, and the fact that it's still frequently used at the ripe old age of 14 suggests that it's been pretty successful. It's probably worth considering why it's worked. As lead on the team that built it and maintained it for the last 14 years, I am not a good judge for why it has worked.

Instead, I offer four brief stories about JES's development and maintenance over the last 14 years.

Keep It Simple: From DrScheme and DrJava, we took the principle to keep it simple. We didn't want an interface with many options for many kinds of uses. We wanted an interface that worked very well for learners.

In JES, you can only edit one file at a time, with an interaction pane (a REPL) for testing and running code. Most Python programs by professionals use multiple files. We opted to design for the beginner who could get lost in a sea of files. Having more than one file open requires some interface for switching files. One file means no additional interface. You can build bigger things in JES, but we optimized for the most common learner case.

Imagineering Media Computation to be Normal Python: We built JES to facilitate students programming in Media Computation. Students can program anything in JES — it's a full Python implementation. We added additional features to JES to facilitate Media Computation with a minimum of cognitive load.

We imagineered a community of practice around Media Computation (a story we told in this paper). In JES, it is normal for Python to know how to make pictures with makePicture, access individual pixels with getPixels, change colors with setRed, and access sound samples with getSamples. Invisibly, we load libraries for the student so that JES is a Python that supports programming with multimedia from first moment of class. In normal Python, you can print anything to get its value. In JES, you explore any picture or sound to open an explorer to see color values in pictures or to visualize the samples in a sound.

Later on, we tell students that there are libraries and how JES is automatically loading them. But on Day One, JES is a friendly Python that knows about pixels and pictures, sounds and samples, and frames and videos. No imported libraries, no dots, no extra details.

Sometimes, you explain errors after they occur. When we first started teaching Python to non-technical majors at Georgia Tech, students struggled with indentation errors. Even today in our ebooks, indentation problems in Python are among the most common and the most difficult for students to fix.

We decided to add a small feature to JES to help with indentation errors. We wanted indentation to be salient and obvious. JES draws a small blue box around the lines in the same block as the current line (containing the cursor).

Now, when students come to me with indentation errors, I ask them "Where's the blue box?" And they invariably ask, "What blue box?" I point it out to them. "Ohhhh — that blue box! Yeah, that's useful." Until students realize that they have to attend to indentation, they don't see the support we're providing. Telling them that indentation is important and pointing out the blue box is not nearly as effective as encountering the error once.

Over the years, remove features. The original 2002 JES had more features in it than the most recent version. Two examples:

• We used to have a menu item to automatically turn in homework. It worked for awhile at Georgia Tech, but then we changed how we handled homework. Other schools have always had their own mechanisms. And most schools try to make it easy to turn in homework. We dropped that.
• We worried about students loading a function from their homework file, then deleting the source code (by accident). The program might work correctly for them, but the file would be incomplete when grading. So, we wrote complicated code that compared the internal namespace to the source code, but that complicated code often caused problems of one sort. We decided it wasn't worth a big maintenance task for a rare error case, so we simply removed all of that complicated code.

The lesson here is Yogi Berra's famous quote "It's tough to make predictions, especially about the future." Some of the issues that seemed critical in the beginning simply weren't all that important in actual practice later. The features with more staying power were the ones that we added in response to learner behavior. Our most successful features were the ones we added to meet real learner's needs, not what we initially imagined the needs to be.