Welcome to the edX blog

Posted in: Open edX

This post originally ran on the edX Engineering blog on Nov. 6, 2014.

Earlier this year, the course discussion engineering team at edX decided to revisit our decision to build a custom discussion platform. In the course of investigating alternatives, we determined that support for the unique usage patterns of our users (both course staff and students) and deep integration with our courseware are key differentiators for edX. This determination led us to the decision to continue to invest in our own platform rather than integrate a third-party platform. Now that the dust has settled from that decision and we have delivered some significant improvements on edX course discussions, we thought it would be useful to take a step back and share with our developer community and users some detail about how we got to where we are today.

At the beginning of the year, we were focused on stabilizing the discussion feature and making it sufficiently scalable to handle the growth that we expected over the course of the year. As we wrapped up that work, we took a hard look at the feedback that we had been receiving from our users. Naturally, many comments drew comparisons between our functionality and that of other discussion platforms. They frequently requested features such as a reputation system (like Stack Exchange) and infinite reply depth (like reddit or Discourse). All of these comparisons led us to wonder whether we should change direction and integrate a different open source discussion platform instead of continuing to build our own.

We started the decision process by building an extensive feature comparison matrix. Based on activity levels and technologies used, we selected a short list of options that might fit our needs. We then began to list important features (both existing and desired) and estimate the implementation cost for each candidate platform. However, through this process, we gained a few key insights that turned out to be more important and decisive than a structured comparison.

The first of those insights is that the role of an edX course team is more expansive than that of a traditional discussion moderator. In most discussion platforms, the moderator’s primary job is to deal with abuse or other forms of conflict. Course teams fill that role but also provide expertise and have a strong desire to ensure that students receive the help they need. While students are often able to help each other work through problems, advice from the staff is especially sought after. Some course teams also evaluate their students based on discussion participation. Thus, our discussion platform must facilitate a many-to-few communication pattern in addition to a many-to-many pattern, whereas other platforms are generally focused solely on the latter.

Another feature that sets our course discussions apart is the embedding of discussions in context within the courseware. Most discussion platforms are built around the idea of a single site that is wholly dedicated to discussion. In contrast, we place discussions within the courseware to allow students to easily talk about about the specific elements of the course that are on that same page. EdX also needs each course’s content to be private and for course teams to be able to configure topics within their courses. While it would be technically possible to implement our desired experience with a different platform, it would be very difficult to do so seamlessly.

Finally, we have observed that students use the edX course discussions for two distinct purposes: to get help with specific problems and to share ideas. Science and math courses, in which students tend to focus on finding the right answer to a problem, generally have more of the former. Humanities courses, in which students tend to focus on examining different viewpoints, have more of the latter. That said, both kinds of conversations happen in all courses. For example, students in a humanities course might need technical support for some aspect of the courseware. Likewise, students in a computer science course might want to discuss their preferred code editor. As a side note, BerkeleyX CS169.1x: Software as a Service ran a pilot that involved setting up a Stack Exchange site for the course, and one of the students noted the tensionbetween Stack Exchange’s focus on answering questions and the desire of students in a learning context to share other kinds of thoughts with each other.

Given this unique set of needs, we decided to continue investing in our existing software so that we can provide a user experience that is optimized for online learning.

Having made that decision, we wanted to act on the insights that led to it, so our first major focus was to address students’ two distinct use cases. As you may have read previously on our blog or seen yourself as a user, we created a feature that enables a post author to distinguish between posting a question to get help and starting a discussion to share ideas. We also provided separate interfaces tailored to each post type and added a filter to view unanswered questions. We believe that these changes will help students and course staff members spend their time in course discussions more effectively, leading to a better discussion experience for all of our users.

We hope you have enjoyed this peek behind the scenes at edX engineering, and we look forward to showing you more of what we can do with a custom discussion platform.

By Greg Price, edX Software Engineer