A few weeks ago, I started putting together a document with some thoughts around the current state of the XBlock framework, its limitations, and various issues we’ve encountered over the years. I’m posting this Lessons Learned doc in case it’s of interest to anyone in this group. Comments and suggestions are welcome, but please keep in mind that this document summarizes many of my personal opinions. This is not an official edX position or a peer-reviewed OEP-like document.
@dave This is great, it certainly explains a lot about XBlocks.
One thing I’d add just from the author support perspective is that XBlocks also don’t have much of a shared philosophy for how the authoring interface should behave in Studio. You’ve got XBlocks that require people to write XML (a bunch of the older ones), XBlocks that have multiple pages (Drag and drop), XBlocks with multiple tabs (ORA), XBlocks where the save button is on the modal, XBlocks where the save button is in the body of the editing window, XBlocks that contain XBlocks… it’s a non-standard mess.
xblock-utils goes a long way towards helping with that author experience, but even with it, when you go beyond the need for a certain level of customisation when building something complex like a drag and drop or ORA, the user experience falls apart.
I’m a firm believer that a stronger UX for authors in studio leads to better courses, and there’s a ton of other places it needs dramatic improvements, but it’s definitely something about XBlocks that I feel the framework could assist with more, or even enforce.Inconsistency is always going to be an issue with this sort of thing, but it’s the wild west out there, even between XBlocks that are fully supported by edX.org