forked from openedx/edx-platform
-
Notifications
You must be signed in to change notification settings - Fork 3
Five ways to extend edX
Ned Batchelder edited this page Mar 13, 2014
·
11 revisions
(Originally written by Sef Kloninger, transcribed by Ned)
I can think of five ways that someone could extend edX. Here they are in order of difficulty:
- jsinput
- LTI
- custom grader
- XBlock
- hack on core code
I can imagine a grid scoring each one. Here’s my initial atttempt, but I’m sure there are more rows that we’d want to consider:
JSInput | LTI | Grader | XBlock | Core Mod | |
---|---|---|---|---|---|
Cost | Low | Low | Med | Med | High |
Language | JS | any | any | Python | Python |
Need dev environment | no | no | yes | yes | yes |
Self-host component | no | yes | yes | no | no |
Need edX involvement | no | no | yes | yes | yes |
Interop with other sys | no | yes | no | no | no |
Clean UI integration | yes | no [1] | yes | yes | yes |
Mobile friendly | no | maybe | yes | yes | yes |
Server Side Grading | no | yes | yes | yes | yes |
Usage Data | no [2] | no | limited | yes (?) | yes |
Notes:
- [1] Only LTI components delivered via https can be iframed in Many are served over http only. And even then they usually have their own look and feel. For example, Piazza can be iFramed in, but has its own navigation elements and their color scheme (see http://networking.class.stanford.edu/ for an example).
- [2] JSInput really only exposes the getState, putState, getGrade methods. But is there any reason why we can’t also document / publish the tracking endpoint (/events/user_track I believe)