OEP Suggestion: Display XBlocks as Course Tab

[eug...@opencraft.com]

Hello world!

Background: OEP is a new (suggested) format for proposing changes to Open edX platform. More details: https://github.com/edx/open-edx-proposals/blob/master/oeps/oep-0001.rst

Idea: Allow XBlocks to be displayed in a course tab (like Progress, Discussion, etc.)

Motivation: 

• In order to completely pull out discussions from edx-platform. discussion XModule is (almost) converted to an XBlock. The next step would be to replace course discussion tab with discussion XBlock-based solution.
  
• This might be useful for building instructor tools (example of a tool that could benefit from this). This is related to other thread on mailing list - kind of alternative implementation.

Tentative implementation details: 

tl;dr: XBlockTab (working name) will be similar to existing StaticTab (powers "Custom Page" feature) and use nested XBlocks concept to allow using any XBlock (component?) in a Tab.

Overall, it would work like that:

• "Pages" page in Studio will have "Add XBlock Page" button added; this button will cause XBlockTab to be added to a course
• In studio XBlockTab will expose UI for adding XBlocks and (most likely) other components (problems, video, etc.), similar to one found in course Outline editor (Unit page). At a glance it looks like it could be exact same UI, but it is not 100% clear yet.
• Components added to an XBlockTab will be persisted to the modulestore using the same mechanism to allow nested XBlocks.
• In LMS, XBlockTab will render its children (nested) components sequentially - much like "Unit" (aka vertical module).

I'm about writing an OEP this week, so feedback and ideas are very welcome.

Regards,

Eugeny

@Opencraft

[Peter Pinch]

How would this affect course import and export?

I believe unrecognized blocks are ignored on import, but that may be harder to do with tabs, since they are specified in policy.json.

I'd also want to make sure that there is some meaningful logging and error messaging to the user when a course is imported and the proper XBlockTab hasn't been installed. 

--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/ad852782-b1e2-46ba-85bc-8d93db72048a%40googlegroups.com.

[Ovnicraft]

On Tue, Jun 28, 2016 at 8:13 AM, Peter Pinch <pdp...@gmail.com> wrote:

How would this affect course import and export?

I believe unrecognized blocks are ignored on import, but that may be harder to do with tabs, since they are specified in policy.json.

In fact question could be extended to: in future any xblock can add a tab ?

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/CFAAC85C-CE8E-4A56-819C-F1610A0C730A%40gmail.com.

--

		Cristian Salamea about.me/ovnicraft

[eug...@opencraft.com]

HI Peter!

Thank you for really quick feedback.

Looks like I've failed to express that, but the idea is to have generic XBlockTab living in edx platform (or in separate repo always installed with edx platform), so there would be exactly one XBlockTab (not one specific tab per XBlock). In such case the tab itself should not cause any import-export trouble.

Contents of the tab could, but that's just the case with normal course content, so I believe the same approach should be taken here (unrecognized blocks ignored). I believe we can extend/improve it to actually fail import or notify user more aggressively if some XBlock is not available.

And I've just looked into course Export XML - some work might be needed there, but nothing really problematic as far as I can tell.

To sum up: with proper implementation from author perspective import-export should not change at all. From developer perspective, export format won't change too - but maybe a bit extended. Code to perform export and import might need some alterations too, but nothing really complex.

Regards,

Eugeny

@Opencraft

[eug...@opencraft.com]

My current understanding is that XBlockTab will just provide a "place" where you can put any XBlock or component, so that it would be displayed in tab.

Theoretically it would mean that any XBlock could be added there, and that XBlock would work exactly the same in tab or in unit. Practically - I don't know yet - there might be a need for an XBlock to implement some interface to be able to work in tab, and in that case only certain XBlocks will be available for tabs. But I would like to avoid that and have a truly generic solution.

In two words: the suggested XBlockTab lives in edx-platform and only "hosts" XBlocks.

Regards,

Eugeny

@Opencraft

[Calen Pennington]

Eugeny,

Another approach that we've talked about in the past around this same problem is that rather than having a specific tab type for housing an XBlock, we'd allow XBlocks to expose a course_view, which the XBlock could use to render any course-level content (perhaps configuration details, perhaps something like the Discussions tab, perhaps other uses). Those tabs could be rendered for any XBlock type that appeared in the course.

Questions I have about your proposed implementation:

• what will the XBlock usage_key would be?
• where will the XBlock content (scope.content) would be stored in OLX?
• How does an XBlock define a view that's specific to the tab?
• For instance, I assume that the Discussion block would have a different display in the tab than it would inline.

-Cale

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/70e847c6-b42e-470f-8ea2-9ffba6d81e2f%40googlegroups.com.

[eug...@opencraft.com]

Cale,

• Usage_key - the same as normal blocks have. I don't think usage_key includes block's parent, so it won't be affected by adding it to a tab vs vertical. Is there any caveat I'm missing?
• OLX - if I do recall right XBlocks in Units are stored in "vertical", one unit per file. For a tab it makes sense to reuse the same approach; the only question is where to put that tab XML file. At a glance it should be located in "tabs", as StaticTab stores it's contents there. But it is derived from how HTML module works, so we don't have to replicate it. I don't have final answer on this, but "tabs" folder seems like a correct place.
• There might be three approaches:
• It doesn't - "student_view" is always rendered - this is slightly simpler to implement and has more flexibility, but might be limited.
• Convention-based - we define a new "predefined" view (i.e. "course_tab_view") to be used for course tab. This view might be "abstract", or can just default to "student_view".
• Configuration based - export some decorator for XBlock to mark "course_tab_view" explicitly.

To me, it looks like convention-based approach with "student_view" fallback is the most efficient one, so if there are no other considerations I would try implementing it first (and structuring the rest of conversation with that assumption in mind).

Regards,

Eugeny

@Opencraft

[Calen Pennington]

For OLX, I can see the content being exported to the `tabs` directory, but I'm a bit concerned about where the links to those tabs will live. In general, having XBlocks that are detached from the course tree has caused us more pain than they've been worth, in the past, so I'd love to see an explicit reference to the tab usage key somewhere (maybe from the Course block?)

-Cale

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/4dd69f54-5ead-45ea-bf29-3b7ffce6be64%40googlegroups.com.

[eug...@opencraft.com]

Ok, concern noted, I'll keep it in mind. Also, if there are any written outcomes of "caused us more pain than they've been worth" it would be great if you could share them somehow.

Actually, we might want to follow the approach StaticTab uses - it stores url_slug in policies.json and actual content in tabs/${url_slug}.xml - is that something similar to what you have in mind?

Regards,

Eugeny

@Opencraft

[Andy Armstrong]

Hi Eugeny,

This is a much requested feature, so thanks for sending out the proposal. FYI, there's a pre-existing ticket that I created a while back in JIRA:

https://openedx.atlassian.net/browse/TNL-2319

I think a good place to start would be to enumerate the different use cases that this solution could help with. In general, having a custom tab that the author can add blocks to would be very flexible, and much more powerful than the current static tab. In fact, it might be better to replace the static tab with your new tab, because it is straightforward for the author to add an HTML block to it, and then they can easily extend it by adding videos or any other content they might have. In some ways, it is as if they are adding a unit directly as a tab, rather than within a section of the course.

An important point to consider is that adding a discussion block to this custom tab wouldn't work by default, as it would render an inline discussion. The block would have to know that it was being rendered 'outside the course', or it would need an advanced setting, or there would need to be a different class of discussion block. The last two options seem to me that they would be confusing for the author.

IMO for a feature like discussions it would be ideal to register that it wants to automatically add a tab, rather than requiring the course author to explicitly add a new XBlock. This is how the XModule works today using the CourseTab extension point:

https://openedx.atlassian.net/wiki/display/AC/Adding+a+new+course+tab

As Cale mentioned, we've been thinking about allowing XBlocks to be able to provide course views for themselves (both course-level student views, and course-level instructor views). I've written more about this here:

https://openedx.atlassian.net/wiki/display/AC/Feature+Plugins+for+edX+Platform

I hope this is helpful. Let's keep the conversation going.

 - Andy

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/e68f5731-3dfd-43c6-a15f-a08babc0d51f%40googlegroups.com.

--

Andy Armstrong

edX | UI Architect  | an...@edx.org  

141 Portland Street, 9th floor

Cambridge, MA 02139

http://www.edx.org

[Колпаков Евгений]

Hi Andy,

First of all, thank you for very thoughtful and detailed feedback!

I think a good place to start would be to enumerate the different use cases that this solution could help with.

Makes sense, I'll try to list them on the https://openedx.atlassian.net/browse/TNL-2319

In general, having a custom tab that the author can add blocks to would be very flexible, and much more powerful than the current static tab. In fact, it might be better to replace the static tab with your new tab, because it is straightforward for the author to add an HTML block to it, and then they can easily extend it by adding videos or any other content they might have. In some ways, it is as if they are adding a unit directly as a tab, rather than within a section of the course.

Exactly!

An important point to consider is that adding a discussion block to this custom tab wouldn't work by default, as it would render an inline discussion. The block would have to know that it was being rendered 'outside the course', or it would need an advanced setting, or there would need to be a different class of discussion block. The last two options seem to me that they would be confusing for the author.

This problem is caused by the fact inline discussion and course discussion have quite different UI, dictated by different use cases. Solutions use two different discussion XBlocks (codenames DiscussionXBlock and DiscussionCourseXBlock) for inline and course discussions, and so far it worked for them - we can follow that approach, if all else fails. However, it looks like introducing "course_tab_view" I mentioned earlier would be able to solve the problem. In two words: XBlockTab will ask XBlocks to render "course_tab_view", and by default that view will just fallback to "student_view"; XBlocks that need to look different in a tab will override it.

IMO for a feature like discussions it would be ideal to register that it wants to automatically add a tab, rather than requiring the course author to explicitly add a new XBlock.

I'm not sure I fully understand this idea, so please correct me if I'm wrong. Is this about automatically adding a XBlock discussion tab to a course if discussion XBlock is installed into platform? I can see four issues with this approach:

1. Implicit action - it might be confusing to course authors to see new tab appearing out of the thin air. Also, to avoid having two discussion tabs we'll have to hide one - probably old discussion tab; in this case it might be not obvious what happened.
2. If I do recall right, XBlock is not supposed to import anything from platform, and base class for course tabs (CourseTab) lives in edx-platform.
3. No obvious update plan for existing courses - I wouldn't in life figured out that refreshing tab list can be achieved by updating "Advanced Module List". And it looks like it is the only way to make Discussion XBlock tab to appear in existing courses in this scenario, unless we go into trouble of creating a migration script/management command.
4. (Very minor) If generic XBlockTab is implemented (the one that allows adding any XBlock/XModule to a tab), having dedicated tab for discussion XBlock would be confusing.

Generic XBlockTab + DiscussionXBlock have drawbacks too:

1. Authors must manually add it to a course - might not be a drawback at all. It requires a bit more interaction than current version, but (arguably) we could mimic current behavior by always adding XBlockTab + discussion XBlock when course is created.
2. Upgrade for existing courses is slightly less trivial - there are two options: either allow authors to opt-in for new mechanism and let them manually migrate courses, or automatically migrate everything with management command (but this options have the drawback of being non-obvious to course authors)
3. DiscussionXBlock needs to be updated to know it is in the tab - this could be done using "course_tab_view"

So, IMO, XBlockTab + DiscussionXBlock would be a more elegant solution; it might require a bit more work from course authors (unless we take care of them by autocreating tab+XBlock), but also will provide them some flexibility (i.e. slap an HTML block with instructions on top of course discussion).

Again, this is all a very valuable ideas, thank you or sharing!

Regards,

Eugeny

@Opencraft

среда, 29 июня 2016 г., 0:14:36 UTC+3 пользователь Andy Armstrong написал:

[eug...@opencraft.com]

Per discussion on Slack architecture channel, OEP is not needed for this kind of change. Instead an empty PR is sent: https://github.com/edx/edx-platform/pull/12896 - it will eventually contain implementation.

This ML thread is mentioned on the PR, so I believe the discussion could continue here, or move to PR, or just go in parallel in both places.

Regards,

Eugeny

@Opencraft

P.S. previous message is from me too - I accidentally posted it from my personal email

[Braden MacDonald]

Adding my $0.02:

Another approach that we've talked about in the past around this same problem is that rather than having a specific tab type for housing an XBlock, we'd allow XBlocks to expose a course_view, which the XBlock could use to render any course-level content (perhaps configuration details, perhaps something like the Discussions tab, perhaps other uses). Those tabs could be rendered for any XBlock type that appeared in the course.

That makes sense, but only if we also implement course-scope fields at the same time. (Which is something I really want to see).

Would it be expensive to determine the set of XBlock types that appears in a course?

Also, one downside of this is that it doesn't support the use case where an author might want to add a particular XBlock as a tab (e.g. a course-wide forum) but not add it to the course content (e.g. no inline discussions). Though one way around that would be to have a course advanced setting for "additional tab types", which is a list of XBlock types to render as tabs even though they're absent from the courseware.

 

adding a discussion block to this custom tab wouldn't work by default, as it would render an inline discussion. The block would have to know that it was being rendered 'outside the course', or it would need an advanced setting, or there would need to be a different class of discussion block. The last two options seem to me that they would be confusing for the author.

I'm not advocating for this, but: If it were a different class of discussion XBlock (which we did for the solutions fork), I don't think that would be confusing because I think it would make sense to have a different list of XBlock templates presented to an author who clicks "Add component" to add a new XBlock to a tab context. e.g. I don't think it makes sense to add CAPA problems, drag and drop, etc. so those wouldn't be on the default list of blocks to add to a tab. Likewise, the inline discussion block wouldn't be an option to add to a tab, and the course-wide forum block wouldn't be an option to add to the course content.

I've heard a few people ask about how this will look in the OLX. I think we also need to consider the related question of how it would look in the modulestore and the course DAG/tree.

Currently, as far as I know, tabs are defined via a field called "tabs" on the root "course"-typed XModule:

course (CourseDescriptor with various fields including "tabs")
  |
  + chapter
  |   |
  |   + sequential
  |        |
  |        + vertical
  |            |
  |            + html
  |            + problem

If we use Cale's suggestion that "XBlocks to expose a course_view... Those tabs could be rendered for any XBlock type that appeared in the course", then we don't have to worry about much other than where to store course-scope fields, which is another topic (I think they should be attached to the root of the structure, i.e. the course). But if XBlocks can be arbitrarily added by authors as first-class tabs, then they'll need to be persisted to the modulestore and they'll more or less need to have a place in the course tree. One option is having a "tabs" type XBlock (much like the "course" XModule or the "chapter" XModule), and every child of it would be a separate tab in the courseware:

course (CourseDescriptor)
  |
  + chapter
  |   |
  |   + sequential
  |        |
  |        + vertical
  |            |
  |            + html
  |            + problem
  |
  + chapter ...
  + tabs
      |
      + html (XModule/XBlock representing the "Info" tab)
      + discussion_forum (XBlock implementing the Forum)  

      + vertical (Custom tab with custom title and potentially multiple child XBlocks) 

Though I'm personally liking the "course_view" approach and course-scoped fields much more.

--

Braden

@OpenCraft

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/ff1916be-7f37-4e5a-ab56-c39d89d661ba%40googlegroups.com.

[eug...@opencraft.com]

Hi all!

I don't think it makes sense to add CAPA problems, drag and drop, etc. so those wouldn't be on the default list of blocks to add to a tab.

I've added a list of potential use cases for the feature to https://openedx.atlassian.net/browse/TNL-2319 - one of the ideas I had is to provide sandbox for complex problem types, like circuit/chem/protein builder. So, authors might actually want adding CAPA problems from "Advanced" list. But that's just my opinion, I don't have any significant proofs. On the other hand I agree that it does not make any sense to add simpler CAPA problems to a tab.

One option is having a "tabs" type XBlock (much like the "course" XModule or the "chapter" XModule), and every child of it would be a separate tab in the courseware.

That's an option too. My initial idea was to still use "tabs" field in "course"; each record in that field would point to a "course_tab" block, and that block would have one or many child blocks. Roughly like that:

course (CourseDescriptor)
  |
  + chapter
  |   |
  |   + sequential
  |        |
  |        + vertical
  |            |
  |            + html
  |            + problem
  |
  + chapter ...

  + course_tab
  |   |
  |   + html (Forum instructions, docs, etc.)

  |   + discussion_forum (XBlock implementing the Forum)  

  | 

  + course_tab

      |
      + html (XModule/XBlock representing the "Info" tab)  

That makes sense, but only if we also implement course-scope fields at the same time.

I would love to hear more about course-scope fields. Also, what benefits course_view + course-scope fields have over XBlockTab + course_view? (Note: looks like "course_view" is exactly the same as "course_tab_view" I used earlier. IMO "course_tab_view" is a slightly better name, but I'll stick to the terminology used by others for now).

Regards,

Eugeny

@Opencraft

[Braden MacDonald]

I would love to hear more about course-scope fields. 

A great example of the need for this is the LTI Consumer XBlock. Instructors need a way to configure the available LTI tools that should be embeddable in their course. For each tool, instructors want to enter the URL* and authentication credentials only once. Currently, the URL must be entered separately on each LTI Consumer XBlock, and the credentials are entered once via "advanced settings" in Studio and stored on a field of the course XModule (which creates a weird coupling between the "Course" XModule and the LTI Consumer XBlock).

What I think would be much better would be if the LTI XBlock could just declare a course-scoped field called "lti_providers" which contains a list of LTI providers (name, URL, credentials). Then authors configure that once, and it gets applied to all LTI Consumer XBlocks in the course, with no duplication of data and no need to authors to enter things like the "URL" or "lti_id" every time they want to add another instance of an LTI tool in the course.

For a discussion XBlock, a course-scoped field could be "allow voting" which enables/disables the upvoting/downvoting feature on a per-course basis.

There are a couple ways to implement course-scoped fields. One would be a new type of BlockScope, called CONTEXT or COURSE or something, halfway between USAGE and TYPE scopes. Then XBlocks can define fields that can be set at a course level, and could also save/load data at a course level ("your score is 3 compared to the current course average of 2").

I think it would also be important to allow the default value of a normal usage-scope field to be inherited (default is the same for all blocks of that type in a course), but still overridable per usage. This would allow instructors to do things like say "All problems in this course should allow 5 attempts", but change that on a per-block basis as necessary. Currently, AFAIK, there is no way for instructors to change some setting like that for all blocks in a course.

 

 what benefits course_view + course-scope fields have over XBlockTab + course_view? 

I think:

• course_view would generally result in a system where "things just work" for instructors - new tools/reports/components appear at the course level automatically when needed, compared to the other system where instructors need to explicitly add XBlockTabs
  
• course_view would have a simpler UI - just need a way to toggle the course_view on/off for each XBlock type, compared to a UI for building out tabs as pages (though maybe for vertical/html tabs, that would still be necessary to implement; also, implementing a UI for course-scoped fields could be a lot of work)
• I suspect upgrading, import, and export would be simpler with the course_view approach, compared to embedding blocks in the course structure.
• There would be no need to run a one-time management command to, say, convert all discussion tab references to DiscussionForumTabXBlock usages.
• I think it's important the courses from older versions of edX could be imported into newer ones, and if you've (for example) converted the discussion tab to be a discussion XBlock that gets stored into the course XBlock DAG somewhere, then you need some substantial import code to check when importing an older course, and create the new DiscussionForumTab XBlock as needed. With the course_view approach, you wouldn't necessarily have to do anything on import, and you'd just ignore mentions of "discussion" in the course tabs list.

* Depending on the tool, sometimes the URL changes for each particular component you want to embed, in which case it would be only the "base URL" that would be the same per unit.

 

--

Braden

@OpenCraft

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/b5b5952a-5899-492f-b676-c9a7743157a0%40googlegroups.com.

[David Ormsbee]

On Thu, Jun 30, 2016 at 3:04 PM, Braden MacDonald <bra...@opencraft.com> wrote:

What I think would be much better would be if the LTI XBlock could just declare a course-scoped field called "lti_providers" which contains a list of LTI providers (name, URL, credentials). Then authors configure that once, and it gets applied to all LTI Consumer XBlocks in the course, with no duplication of data and no need to authors to enter things like the "URL" or "lti_id" every time they want to add another instance of an LTI tool in the course.

Huge +1 for a course scope. The CourseModule is a dumping ground of all kinds of settings info for different block types, just because there is no other place to store that kind of information today.

I also completely agree with your points about favoring a course view for the data migration aspect.

I think it would also be important to allow the default value of a normal usage-scope field to be inherited (default is the same for all blocks of that type in a course), but still overridable per usage. This would allow instructors to do things like say "All problems in this course should allow 5 attempts", but change that on a per-block basis as necessary. Currently, AFAIK, there is no way for instructors to change some setting like that for all blocks in a course.

I'd shy away from having content and usage scoped fields arbitrarily inherit from course scoped ones. While it's a powerful idea, I think that there's potential for confusion there, particularly when interacting with fields that are inherited from parent to child already. Right now, if you set "max_attempts" to 5 on the root course module by editing the XML, it will inherit down into all of the leaves. Allowing arbitrary overrides might mean that a Capa problem gets a max_attempts attribute set on it because it was inherited down from a sequence that had a course-scoped field of the same name. It also adds complexity because for the first time, we'd have the same field name mapping to multiple scopes.

I think that we can get much of the same effect in a simpler way by using the course scope for explicit default values stored under a different field name or names (e.g. a course scoped field named "defaults"). That way, we don't have to worry about weird inheritance interactions at all, or wondering where the value of a certain field really came from.

All that being said, I really feel like grading policy stuff should be in its own API (say a runtime service), just because it would help us with more dynamic content. But that's another big discussion, and probably not something we're going to get around to for a while.

As a side note, one thing I want to be careful of in this discussion is the "Tab" naming convention. Tabs are a UI implementation detail, and they don't necessarily carry over to things like Mobile. When we talk about tabs, we're talking about a number of logically different things: the root of the courseware DAG, things that are still course content but aren't necessarily under the root, course level block views that don't directly tie to def/usage scoped fields, admin functionality like the instructor dashboard, etc. It would be good if we could refine our vocabulary for these concepts, and not constrain ourselves to a UX decision made during the prototype days of 2012.

Take care.

Dave

[Braden MacDonald]

I think that we can get much of the same effect in a simpler way by using the course scope for explicit default values stored under a different field name or names (e.g. a course scoped field named "defaults"). That way, we don't have to worry about weird inheritance interactions at all, or wondering where the value of a certain field really came from.

I agree. I didn't say this explicitly, but I was assuming that we would use some sort of namespacing like that to avoid conflicts between different types of scopes. We wouldn't want confusion or any chance of unintentionally overriding field values.

As a side note, one thing I want to be careful of in this discussion is the "Tab" naming convention. 

+1, which is why I do prefer "course_view" instead of "course_tab_view".

Though it's worth pointing out as well that some people are interested in using XBlocks in contexts that are not courses, such as content libraries, XBlock SDK workbench scenarios, "microcourses", LTI consumers, blog posts, etc. But I know that these semantic questions are part of the reason we haven't had course-scoped fields yet, so I'm in favor of creating something simple for the main use case (courses) rather than trying to make something really generic and complex.

--

Braden

@OpenCraft

--

You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/CAO_oFPyeCRUCjL%2BjC3AcjUaD_sMR245TcDt%2Bjot0eDyBsTgy0w%40mail.gmail.com.

[eug...@opencraft.com]

Ok, the discussion is kind of stopped here, so I'm going to sum up main points:

• Looks like "course_view" + course-scoped fields provide more value in general, while my initial suggestion is tailored to single use case, seems simpler to implement, but maybe slightly harder to maintain.
• Since discussions (my primary use case) are going to be rewritten soon it seems to make more sense to follow "course_view" approach.
• Additional benefit is that "course_view" are relatively orthogonal to discussion rewrite, so we won't step on each other toes implementing them in parallel.

So, suggested implementation is as follows (Braden and David, correct me if I'm wrong):

• XBlocks will provide special "course_view".
• LMS and Studio will use that view to render XBlock content as "course tab" page.
• XBlocks providing course_view will be automatically displayed as tab when they are enabled in Advanced Settings - it won't require course authors to actually add an instance somewhere. However, they will be displayed in "Pages" UI, and allow hiding the tab.
• If an XBlock requires some configuration in "course_view", config data will be stored as course-scoped fields (new feature); UI to set them up will be shown in Studio on "Pages" UI (???). This will likely require secondary "studio_course_view" (similar to existing studio_view)

The only concern I have about this implementation is that jquery.xblock dependent solution won't be able to use such course_views, as there are no actual XBlock created - we'll have to adapt jquery.xblock and/or APIs that back it up on edx-platform side.

Regards,

Eugeny

@Opencraft

[Braden MacDonald]

If an XBlock requires some configuration in "course_view", config data will be stored as course-scoped fields (new feature); UI to set them up will be shown in Studio on "Pages" UI (???). This will likely require secondary "studio_course_view" (similar to existing studio_view)

As a long term goal, I think it'd make sense for most of those course-scoped settings to be marked for inclusion in an auto-generated editor UI (just as XModule usage fields are today, or XBlock fields with StudioEditableXBlockMixin), and then we could replace the existing Studio "Advanced Settings" page with a new UI that iterates over all enabled block types and displays an editor for their scope-scoped fields (at least the ones that also have User scope NONE).

The only concern I have about this implementation is that jquery.xblock dependent solution won't be able to use such course_views, as there are no actual XBlock created - we'll have to adapt jquery.xblock and/or APIs that back it up on edx-platform side.

That's a good point. We need to figure out what URL would represent the request "Hey LMS, please render the course_view of XBlock type discussion in course CourseID and return the result as JSON". The most analogous current URL is the render-xblock-usage-as-JSON URL, which is  "courses/{course_key}/xblock/{usage_key}/view/{optional_view_name}". So the question is if that view should have a UsageKey (almost definitely not, though conceivably we could have a usage key with a standard block ID like "course"). I think a reasonable option would be to use a BlockTypeKey, so the URL to get the course_view as JSON would be "courses/{course_key}/xblock/{block_type_key}/view/{view_name}", e.g. "courses/course-v1:org+course+run/xblock/block-type-v1:xblock.v1:discussion/view/course_view". I think the other option is a new type of Opaque Key that contains a course ID and a block type but no ID - however I don't want to contribute to the proliferation of key types if we don't have to.

Since the return value of that API would presumably be identical, I hope it wouldn't be too hard to adapt jquery.xblock to be compatible.

 

--

Braden

@OpenCraft

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/633dbbae-4ffc-4fb2-a2d5-04fc4c07e627%40googlegroups.com.

[Piotr Mitros]

Thank you for bringing this discussion back; I was travelling during the original one. I just wanted to mention that the way we had planned to do this in the past would have hierarchies that are a little bit different:

course (TabbedCourseDescriptor)

  |

  + AccordionXBlock

  | + chapter

  |   |

  |   + sequential

  |     |

  |     + vertical

  |       |

  |       + html

  |       + problem

  + html (XModule/XBlock representing the "Info" tab)

  + discussion_forum (XBlock implementing the Forum)  
  + vertical (Custom tab with custom title and potentially multiple child XBlocks)

A single platform extension could be implemented as multiple XBlocks. In the same way as forums access both the same data from the courseware as from the forums tab, a peer grading extension might have e.g. XBlocks in the courseware for submission, and a top-level tab for peer grading. We've generally tried to maintain a split where the OLX generically defines the course and course structure, while the non-OLX parts of the tarball are edX extensions (most, but not all, of which would hopefully eventually merge into the OLX).

We had defined an incremental path to get there too. I could find or reconstruct it, if this were of interest. 

Conceptually, I'm a little concerned about having multiple XBlock hierarchies in the course. I'm also a little concerned about presuming the structure of the course in the way that the chapter/chapter/tabset hierarchy does. I'm also concerned about having a child in the navigation not be so in the hierarchy. Tabs are parallel to the accordion, not the chapters. 

Piotr

[eug...@opencraft.com]

Piotr, welcome on board :) Jokes aside - thank you for bringing up that info.

Having incremental update path is good, so it definitely makes sense to try to find/reconstruct it. Even if we choose different structure, we might borrow parts of that plan, or at least take some inspiration from it.

Regards,

Eugeny

@Opencraft

[Andy Armstrong]

Hey Eugeny,

I'm back from vacation now, so I'd love to pick this up again. What is your current thinking? Would it be helpful for me to reply to this thread, or has the design moved on?

Thanks,

 - Andy

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/5363559a-5780-419b-9b68-3a94c6f7c7a5%40googlegroups.com.

[Braden MacDonald]

From my perspective, the next steps should be to write up an OEP for course-scoped fields (this is something I hoped to do myself this week but it got bumped due to other priorities - should be coming soon), and to sketch out a prototype of the course_view approach for implementing XBlock tabs, as discussed in this thread, and use that as a basis for continuing the discussion.

--

Braden

@OpenCraft

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/CAG2ZmnAMohtNiX-G9iN7YuMaWJJVt1d%2BDdvHFBaouhDLVSvuZw%40mail.gmail.com.

[Andy Armstrong]

Thanks, Braden. Those steps sound good to me, so I'll wait to review the proposed approach when it is available.

 - Andy 

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/CAEyJbEa5tTT-pHj4xAbWxADid7i5iZm02LXqQ%3DJKupjnFu47vA%40mail.gmail.com.