User Tools

Site Tools


adapting_an_existing_on-campus_course_for_berkeleyx

This is an old revision of the document!


Overview

BerkeleyX uses the open source EdX platform to deliver various kinds of online courses. “EdX Edge” is a platform on which anyone can offer a course, internal or external; a separate process is used to recommend that some of the best Edge courses be featured on the flagship site EdX.org.

Before you start, you should “enroll” in an EdX MOOC to understand the student experience of taking such courses, since you'll be preparing your materials to match that experience. Go to EdX.org and enroll for one or more courses, watch a few video segments, and try out some assessments.

EdX Edge courses can be offered in various ways, at the instructor's discretion:

  • Limited enrollment: anyone can enroll, but size is restricted
  • Enrollment by invitation: instructor chooses who may enroll. This is useful, e.g., if you want to use EdX technology to enhance your on-campus course but aren't yet interested in offering the course externally.
  • Unlimited enrollment public courses (MOOCs).

In all cases, adapting a polished, mature on-campus course for EdX delivery involves the following. The notation “Pro” indicates the opportunity to do something beyond what is built into the platform, but which requires advanced and/or programming skills to do.

  1. Determine course scope and length. Shorter courses (3-7 weeks) seem to work better, so consider splitting up your on-campus course into self-contained sub-courses. An online course is organized into units; typically 1 unit can be completed in 1 week, and includes some combination of lectures, readings, homework assignment deadlines, and quizzes/exams.
    • Tip: You can also choose to create a module, which is a self-contained subset of a course that can be either publicly-available or limited access, and build your way up to a full course.
  2. Structure your lectures as self-contained segments. Each segment should correspond to 7-12 minutes of lecture delivery time and be accompanied by one or two short-answer self-assessment questions (see Short-Answer Autograders below).
    • Tip: If you plan to deliver your lectures live rather than separately pre-recording, you can use these questions for peer instruction by giving out inexpensive colored flash cards.
  3. If you use copyrighted imagery or content in your lectures, you will need to ensure that you have the permission of the copyright owner or that your use of the materials is otherwise covered by Fair Use. (A pointer to more detailed information and how-to is coming soon.)
  4. Lecture capture. Arrange for screencast and/or video capture and postproduction of your live lectures, or if you are planning on pre-recording lectures before the course begins, identify the resources and arrangements you'll make.
  5. Autograding. Determine what kinds of machine-gradable assessments the course will include.
    • Short-answer autograding (see below) is built in to the platform, as are tools for creating short-answer-autogradable assessments.
    • (Pro) You can also create arbitrarily sophisticated custom autograders for specific assignment types (circuit diagrams, essays, etc.) and plug them into the EdX platform. This requires programming knowledge. See Custom Autograders below.
  6. MOOC TA. Identify a teaching assistant to monitor the forums and otherwise keep an eye on the course. The first time you offer the course, expect to require 20-30 hours per week of TA time just for the MOOC (i.e., in addition to any TA resources for your concurrent on-campus course).
    • Tip: We have found that strong undergraduates who have mastered the course content do fine in this role. On subsequent MOOC offerings, you can recruit volunteers from the current cohort to help do this job for future cohorts - see below.
  7. Prerequisites and materials. Prepare a description of the course, including length of course, prerequisites, required books or other materials, and (important) approximate hours per week students should expect to spend.
    • Tip: For open-access courses, it's useful if the required material(s) are free or low cost, or if free or low-cost alternatives are available.

Timeline

Here is a suggested timeline, using the NASA convention of T=0 being the day your course begins online.

(Timeline TBD)

Tutorials, Best Practices, etc.

Autograding

The edX platform has built-in support for grading many problem types including “short answers” (multple choice, fill in blanks, numerical answer with range, etc.), circuit diagrams, math equations using MathJax, and more, and the list is growing all the time; you can prepare such questions using a user-friendly course authoring GUI. See Getting Started With EdX Studio.

You can also create your own autograders for more sophisticated course-specific use cases, and integrate them with edX. In this scenario, you're responsible for creating and deploying the autograders (see below). The external autograder API provides the following three RESTful API calls. (If you don't know what a RESTful API call is, stop reading now—you will need to work with a programmer who is familiar with this technology.)

  1. get_queuelen: return the number of items waiting in queue
  2. get_submission: get single student submission
  3. put_result: give the queue the results of submission

Here's how it works:

  1. Your autograder must run as a standalone process or collection of processes wherever you want (cloud, etc). (TBD: AWS support for this?)
  2. The autograder uses HTTP to poll a specific queue on an edX server to retrieve an assignment to grade. (Each portion of an assignment that has a distinct autograder associated with it gets its own queue.) If the queue is empty, the autograder should sleep for a few minutes and try again later. (Eventually, auto-start and auto-sleep will be supported by the edX platform itself.)
  3. If there is an assignment to be graded, the autograder receives a student submission (in whatever format that means for the assignment) and an ID identifying the student.
  4. The autograder must grade the assignment and produce a scalar score and optional textual feedback for the student. The feedback could be some text or HTML, or just a URL pointing to a grading report hosted online somewhere.
  5. The autograder uses HTTP to post back the score and text to the queue server, along with the student ID.
  6. If the autograder fails to post a score within 15 minutes for an assignment it pulled from the queue, that assignment is automatically returned to the queue for another autograder instance to pick up.

At the moment, you are responsible for launching and maintaining the autograder process(es), but in the future this management will be part of the platform.

Example autograder skeleton code:

  • Ruby autograder used for CS169
  • an example of the pull-from-queue API (and uploaded student submission retrieval) built around the 6.00x grader from MIT
  • More examples in other languages to follow
adapting_an_existing_on-campus_course_for_berkeleyx.1358265275.txt.gz · Last modified: 2018/02/28 17:02 (external edit)