RFC: proposing new course-level XBlock views

[Jim Abramson]

A discussion has begun among some of us at edx.org about adding course-level views and functionality to XBlock, and to Open edX's learning / authoring runtimes.

By course-level, we mean exposing new views of a block as top-level course elements, so that course authors, admins, and learners can interact with the content they expose across the entire run of a course.  The driving usecase for this, in terms of the present courseware UX, is to dynamically generate tabs in a top-level view of the course, driven by the XBlocks installed in the course.  The added functionality would also be used to provide administrative views.

This hackathon proposal explains more about the problem area, and provides a few use cases that are very relevant to projects presently under way at edx.org.  Quoting Andy from that page: "we should think of xblock as being a platform plugin capability, rather than purely a way to build components for units."

The change would have three parts:

1. Naming and implementing support for some new XBlock views that can appear in new places: as a courseware "tab", as an instructor-only tab or section, in an authoring tool (e.g. studio).
2. Implementing support in both LMS and Studio to identify and present blocks specially, depending on whether or not the author has chosen to enable a tab/dashboard/config view. 
3. Introducing a new, third scope:  CourseScope.  This refers to a *course run* (i think it's ok if we prefer to name it CourseRunScope).  Its value may be NONE or ONE.  Everything we have in mind for this feature would use ONE.  This makes explicit that we want to have certain data scoped across all usages of a type of block, within a specific course run.


We're just starting to talk about how we'd do this and obviously there are many details to nail down.  It would be great to hear from anyone out there with ideas for / criticisms about this direction for XBlocks or Open edX.


Thanks,
Jim

[David Ormsbee]

I'm concerned that we're trying to stretch XBlock too far here, and some of the elements described would be better suited to full fledged Django apps adhering to some set of conventions. The big thing that XBlock has going for it in terms of displaying course content is the ability to arbitrarily nest rich content apps that are largely independent of each other. As a general web framework for building bigger applications, it still has a number of shortcomings -- the tight coupling of every view to the model, the lack of support for more complex shared model access across multiple students, lack of visibility in monitoring like New Relic, no asset pipeline, etc. When you're talking about something that takes a full tab, controls all its contents, presents multiple views, and has data that crosses student boundaries (like the forums), I feel like it's playing to all of XBlock's weaknesses and none of its strengths.

I'm supportive of adding CourseScope, though I think we have to be careful about what goes there. I think we overuse scoped vars because they're there, and often resort to them when we should instead be asking questions of the runtime. Take due dates for instance. Individual due date extension is a very pragmatic feature that builds on our existing framework and checks for a student state scoped due date that would override the one set on the problem -- but every XBlock has to explicitly do that check or they won't support IDDE. If XBlocks didn't use inherited due date fields at all but always asked the runtime when they were due, IDDE could have been implemented there and hidden away from XBlock authors.

Take care.

Dave

[Jim Abramson]

Hi Dave,

Thanks for responding.  I especially appreciate your point about playing to XBlock's weaknesses.  I have not yet been through any serious trial by fire with XBlocks, and I know you have.

Until recently, I was thinking along the lines that the best approach to adding an independent suite of functionality to the LMS (that would include both course components and administrative / course-level features) would be to structure it as a Django app and design its views at some composable grain, such that XBlocks could import and utilize its views/helpers to render contextual bits of application into the course structure.  So in this model, XBlock and Django app interface are used independently as adapters, to integrate a shared library of views/models/features into courses.  I believe this integration model is viable, but I believe it comes with its own, perhaps less desirable shortcomings:

* it's necessary to develop / test your stuff both in XBlock-world and in Django-world.
* the need to generalize for two types of integration ends up requiring a third generalization now (views or at least resources that can render in a straight Django app, as well as in an XBlock).
* you still end up with run-time dependencies from your host LMS to your external functionality - INSTALLED_APPS to begin with, but in practice much more, since you need to integrate navigation and look-and-feel somehow, both in your courseware and authoring environments.
* did i mention: you are explicitly coupled to Django.  Obviously not a dealbreaker, but certainly limits portability.

Based on what I understand today I think making XBlock *the* way of integrating with courseware is better.  While none of the shortcomings you've mentioned are trivial challenges, there is nothing preventing us (edx.org, the OSS community) from building out the capabilities presently lacking in XBlock, should we elect to invest the effort.  I realize that's an idealistic statement, but a feature built half in XBlock and half outside is, in my opinion, going to be a much more clunky and convoluted affair.  I don't think there's a point in having XBlock if it fails to deliver on our hopes for a cleaner and more modular system, let alone if it makes things harder.  If there is one right way to integrate with the platform, then we can at least be sure efforts will be focused on making that way work optimally.

I'm not as worried about the kinds of applications we have in mind for the tabs being unsuitable for XBlock.  In most cases I think we are just shipping a javascript application to the frontend and waving goodbye to it.  (This does underscore the urgent work we need to do on asset pipelining, js dependency management, and so on.)  We want the host environment to call the shots as far as basic infrastructure, appearance/theming, and lining up our runtime services for us.  I just think it will be bad if we have to have two different ways to do roughly the same thing - one for blocks, one for Django apps.

Specifically regarding forums, there are no plans to use student-scoped Field data.  Forums data is too big and complex for what Fields are designed to do, and we need more transparent access to that data.  We'd instead expose our content APIs as a runtime service, and in addition, lay in whatever other runtime services necessary to filter/authenticate requests for that content.  Fields *do* seem like a great fit for course-wide configuration of a block, or across all blocks of a given type in a course, and that use case goes hand in hand with the course-level proposal.

In general I agree that authors should be favoring the runtime - but we also have to put more useful runtime services out there, both as enabling functionality and as example material.

Sorry for the long essay.

Best,
Jim

[Don-edX Mitchell]

I still remain a bit confused about this proposal. Would the runtime have to detect whether there's any xblock instances in the course's xblock tree which have this CourseScope and thus have to load every xblock in the course or would there be a different mechanism to gain that awareness or would it just be lazy: upon presenting the first such xblock to the user, the tab or whatever appears and it doesn't appear until then? If the latter, then when the student comes in next time and doesn't render that given xblock, the tab would not render? If there are multiple instances of the given xblock type which adds the CourseScope, would they share that field value (I assume that's the proposal)? If so, I can imagine instances overloading this scope with a partitioning so that some may want to use the value stored as variant_a whereas others want variant_b kind of like split tests do w/ experiments.

Perhaps rather than introducing new scopes and fields, the studio view for the given xblock should have the authority to injecting a new field or configuration on the course root xblock which would persist with that course xblock (and thus only be added during authoring not lms rendering).

[Calen Pennington]

I would expect the tabs to be explicitly defined, just like they are now. It's just that we would have a tab type (or have all tab types) render XBlocks, rather than using django views. I think the addition of a CourseScope to explicitly scope data inside a course is an orthogonal question.

Regarding using django/XBlocks vs pure XBlocks: I think if we should look at the shortcomings, and see if it makes sense to address them. For instance, the 1-1 view to model coupling is something we've talked about changing for a number of reasons (supporting different clients like mobile, for instance, as well as allowing customized frontends to consistent data). Likewise, data that cuts across students is something that's thought to be useful inside courseware as well as outside, so I don't see that as a blocker to top level tabs. Instead, I just see the top level tabs case as another motivating instance to fix the deficiency.

-Cale

[Ned Batchelder]

I agree with Cale that current XBlock shortcomings shouldn't be a reason to design another mechanism for putting code in tabs.  One way to look at XBlocks is that they are web applications a div at a time.  That sounds perfect for adding new tabs to a course.  XBlocks solves questions like, "how does the third-party code provide HTML to become part of the page," and "how do events from the browser get routed back to my code".  These are also things you can do directly in Django, but only if you have the cooperation of the surrounding application, ideally in the form of a stable API.

But why create another extension point for tabs?  True, there are things in XBlock tabs don't need, and there are things missing from XBlocks that tabs do need.  For the first point, there's no rule that says you have to use all of an API.  For the second, those missing things are also needed by in-course learning components, so let's identify them and add them to XBlock.

--Ned.

[Don-edX Mitchell]

Ah, I may have completely misunderstood Jim's proposal. I thought it was dynamically adding tabs such as a discussion tab base on the fact that there's a discussion xblock deeply nested in the tree. Thus, if the author removed the last discussion xblock, the tab would automatically go away. If the author adds the first discussion xblock, the tab would appear.

[Don-edX Mitchell]

Same for CourseScope. I thought he was saying that if an xblock deep in the course set a field w/ scope CourseScope that somehow other xblocks also nestled in the course would get the same value for that field.

[David Ormsbee]

Hi folks,

XBlocks are a very useful hammer, but I get concerned when I see it characterized as the "one right way to integrate with the platform", as Jim did earlier in this thread. I know that's not really how the statement was meant -- we're all aware of JS Input, external graders, new REST APIs, potential extension points in ora2, analytics, etc. But I think that because we haven't really defined what XBlocks *won't* do, it's easy to at any point envision one more feature to enable XYZ, and I worry about what that implies for the long term design focus.

As Ned said, the top level tab integration is something that can be done in Django with some cooperation from the surrounding application. You extend a template, maybe call a helper method to fill in parts of the context that you remain ignorant about, and you can pretty much go about your business. There's more to it than that, but the level of effort is not that large, and you don't have to do without all the Django amenities or try to reinvent them in XBlock.

I don't want to extend XBlock with features just to make the forums tab easier to implement, because established web frameworks like Django already do those things, and will for the foreseeable future do them better. With our limited resources, we should dig into and expand on the areas and challenges that make XBlock unique. No other framework that I know of lets you so richly stitch together such completely different pieces of dynamic content. There is a list a mile long of very domain-specific work that could be done: remote XBlock execution so that we can have entirely separately scalable installs with different dependencies, JS isolation, figuring out how XBlocks cooperate to handle mobile in both online and offline modes, namespaces in the XML definition, formalizing the interchange format, etc.

I realize there may be overlap there, and that's great. I just don't think that enabling top level tab functionality should be a major motivating factor. Those requirements should come from the core of what we do with XBlock (courseware) and we should weigh the opportunity cost very carefully.

Honestly, I'm even skittish when it comes to adding support for data across students. I think that some carefully defined APIs for things like sharing answers or passing messages would be fine, but large scale querying or outright SQL table support feels like it would be going too far. At that point, I think we're better off just saying that you want to write a full blown application and use XBlock as a course content porthole into it via service calls (which is essentially what edx-ora2 does). Given that there is a viable path for these projects, I'd rather punt on this feature entirely rather than build something that will be a burden to maintain.

Again, it comes down to the question of where we want to draw these lines. Nothing in the XBlock design inherently limits it to rendering courseware, but that is its primary mission today. Two years from now, I would rather see XBlock be perceived as amazing for that one purpose, rather than to have it be seen as a passable NIH framework that we use for everything in edx-platform.

Take care.

Dave

On Wed, Jun 11, 2014 at 1:57 PM, Ned Batchelder <n...@edx.org> wrote:

[Jim Abramson]

Don,

In my thinking the presence / absence of a tab view for the block would be driven by explicit action of the course author.  Something along the lines of: 1 - a certain block is installed as a course component by the author.  2 - at install time, recognizing (somehow) that there's an available tab implementation in the block, the host authoring system registers that and either enables or disables it by some default.  3 - the authoring system presents some interface to toggle enabled/disabled for this tab view, optionally also providing a means to change its relative position among other tab views already known/registered.

This assumes that installing an "advanced component" (in the Studio parlance) is a course run lifecycle event capable of carrying out such logic, and also that the underlying physical data model is capable of persisting this in some reasonable and backward-compatible way, neither of which I assume to be true without your input :-)

Thanks,

Jim

On Wed, Jun 11, 2014 at 2:38 PM, Don-edX Mitchell <dmit...@edx.org> wrote:

[Jim Abramson]

Cale,

Thanks, yes, CourseScope is basically orthogonal, though conceptually important - it's meant to define something that (in my understanding) is undefined now, which is whether BlockScopes DEFINITION / TYPE / ALL should only apply to a certain course+run in the system, or to all of them.

I would be equally open to a further clarification of BlockScopes on this question, as I think the simplicily of keeping only two scopes would be pretty attractive.

Jim

On Wed, Jun 11, 2014 at 12:18 PM, Calen Pennington <ca...@edx.org> wrote:

[Jim Abramson]

Dave,

I think the contention here may come down to how far away we see XBlocks from being able to support the tab/course-level functionality we're talking about.  I say this because I end up agreeing with your points and your reasoning; I just don't see as much of a gap from what XBlock already is.  I think what we're talking about boils down to what we could call dashboard capability for XBlocks.  Even though I'm pushing on this today because I think it's the best fit for Forums, it's not unique to that piece.  ora2, for example, is looking for the same capability.

Really, all we want is another way to navigate to a block - by its type rather than its location.  The rest, to me, feels like runtime implementation details, or formalization of things previously left undefined (CourseScope).  I'm thinking it might be best to validate/disprove this impression in the form of a PR, so we'll have something more concrete to work with.

I suppose it is useful that we are now forcing the conversation about what XBlocks won't do.  My involvement in their conception/design has been negligible, so I look forward to watching more sparks fly :-)  But the use case I most want to emphasize is that, as a developer/contributor, I'd prefer not to have to implement a second, wholly separate integration in order to make my XBlock capable of displaying a course-level dashboard in Open edX, because that seems arbitrarily cumbersome.

Jim

[Xavier Antoviaque]

Something else to consider - XBlocks aren't only displayed in the LMS, they can also be embedded in other applications. If things like the forum threads listing is not implemented as an XBlock, it will also prevent from using the same strategy for integrating the forums thread listing there, and require a whole different information flow for something which is pretty similar in terms of functionality.

 

--

Xavier.

 

[Kolpakov Eugeny]

Hi guys!

Sorry for kind of necro-posting, but this thread perfectly suits the question I have.

I'm working to move discussion xblock into edx-platform repository (PR) and it got to the point where some decision and insight on this topic is required. In two words, there are basically two discussion XBlocks: one intended to use in inline mode and one to be put in discussion tab. Both provide functionality identical to discussion XModule and actually use same css/sass/js/coffee assets. 

So, the questions are: 

• What was the final decision on having course-level XBlocks?
  
• Is/was there any effort to implement them? If yes, are there any code I can use as an example?

Regards,

Eugeny Kolpakov

вторник, 10 июня 2014 г., 0:40:27 UTC+4 пользователь Jim Abramson написал:

[Piotr Mitros]

It's a little hackish right now, but the profile page in https://github.com/pmitros/edX-Insider is an XBlock in its own tab. You can view this at: 

  https://edge.edx.org/courses/edX/edX_Insider/Ongoing/about

Note that this is designed as an edX-internal course, and has a _lot_ of prototypes and pilots in it (which are not production-ready with respect to accessibility, i18n, test coverage, etc.). 

The general proposed technical path is to treat subsections as top-level pages (as they appear right now), and then to slightly decouple them from how they are placed in the course navigation. The proposed implementation flow was:

1. Allow chromeless XBlocks (turn on/off things like accordion and tabs). This is required regardless of whether we allow XBlocks at the top level (a lot of XBlocks need full window real estate). 
2. Provide functionality for XBlocks to be able to specify/override their location in the navigation scheme (accordion and tabset) from just what is specified in the course.xml hierarchy. This is needed for behavior similar to tutorials in 6.002x (go to 6002x.mitx.mit.edu to see what I'm talking about).  
3. Convert existing tabs to have XBlock implementations, where it makes sense. 
4. Do a permutation of OLX/edXML where we can specify the tabset in course.xml rather than platform-specific JSON. In other words: <tab><course></course><html></html> ... </tab>. Rely on normal inheritance to propagate location in hierarchy, whether to show accordion, etc. 
5. Continue to rethink how to decouple high-level navigation from the details of the portions of the course. By default, the organization should be identical to what is in course.xml, but there should be ways to e.g. have blocks in multiple places, have semantic descriptions of course structure (so you can browse by deadline, by subject, etc.), etc. 

By step 2 (all of which I build) we can already do top-level XBlocks as an ugly hack. We already have functionality to allow us to hide sections. We add a hidden section, override location to be in the appropriate tab, and make the tab link to it. This is what the edX Insider course does. Minor next step: It'd be great if this could be a course-relative link, rather than a hard link, so it worked with import/export/etc. 

Piotr