Learner data store

Feature Ideas
1

I have a way to store learner-specific data in edX with Javascript. You can see a live-development thread here on this forum, slides from a presentation that I’ve given at the Open edX conference, and instructions in the JSInput repo. We refer to it as the “backpack”. It’s a messy workaround that would make Rube Goldberg proud, but it’s the only way to do it. I’d love to have this be easier.

Here’s how it could work:

  1. Provide a few javascript functions within the course page: setStudentData({keys: values}), getStudentData(key), getAllStudentData(), clearStudentData(key), and clearAllStudentData(). Those would store, retrieve, and erase info as stringified JSON.
  2. Everything on the page should have access to that - all HTML and problems, for example.
  3. They should store things on a per-learner per-course basis. No learner should be able to see another learner’s data. Staff masquerading as a particular learner should be able to retrieve their data with the get functions.
  4. Data can be limited to 100k per learner per course. That’s the current limit my tool has, and we haven’t run into it yet. I run a small amount of compression (LZW) on it.
  5. Obviously, those functions would be available in the learners’ browser consoles. If they can read their data, that seems fine to me. If a learner messes up their data, they stuck their hand in the hornet’s nest and it’s their problem now.
  6. You can rate-limit it to prevent DoS-type attacks (or just someone accidentally creating an infinite loop). The current approach does this by, and I’m not kidding, submitting a problem each time setStudentData() is called, and you have to wait for the problem to reload in order to call set again. This could maaaaybe be done better if we had a less ridiculous approach.

What have we already done with this?

  • The frequently-requested “Buzzfeed Quiz”: Answering a set of questions and getting a combined response that categorizes the learner in some way. Used in our Path to Happiness course.
  • Bringing back previous responses so learners can see what they wrote before.
  • Building on that to create a rich text editor (using Summernote) that lets learners save their writing and revise it later. Used in Rhetoric.
  • Progress tracking to provide information separate from the edX Progress page. Used in an upcoming run of Data Wise.

Why haven’t we done more with the tool as-is? Only because it’s a pain to implement. There are two of us at HarvardX who can do it, and one of them is me, the guy who designed the process in the first place.

1 Like