>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 <http://opencraft.com/> On Tue, Jul 19, 2016 at 2:27 PM, Andy Armstrong <[email protected]> wrote: > 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 > > On Wed, Jun 29, 2016 at 4:53 AM, Колпаков Евгений < > [email protected]> wrote: > >> 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 <http://opencraft.com> >> >> среда, 29 июня 2016 г., 0:14:36 UTC+3 пользователь 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: >>> >>> <http://goog_576435595> >>> >>> https://openedx.atlassian.net/wiki/display/AC/Feature+Plugins+for+edX+Platform >>> >>> I hope this is helpful. Let's keep the conversation going. >>> >>> - Andy >>> >>> On Tue, Jun 28, 2016 at 11:41 AM, <[email protected]> wrote: >>> >>>> 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 <http://opencraft.com> >>>> >>>> On Tuesday, June 28, 2016 at 6:15:51 PM UTC+3, Calen Pennington wrote: >>>>> >>>>> 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 >>>>> >>>>> On Tue, Jun 28, 2016 at 11:11 AM, <[email protected]> wrote: >>>>> >>>>>> 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 <http://opencraft.com> >>>>>> >>>>>> On Tuesday, June 28, 2016 at 5:10:45 PM UTC+3, Calen Pennington wrote: >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 28, 2016 at 9:41 AM, <[email protected]> wrote: >>>>>>> >>>>>>>> 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 <http://opencraft.com> >>>>>>>> >>>>>>>> On Tuesday, June 28, 2016 at 4:30:00 PM UTC+3, Cristian Salamea >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jun 28, 2016 at 8:13 AM, Peter Pinch <[email protected]> >>>>>>>>> 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 ? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> On Jun 28, 2016, at 9:06 AM, [email protected] wrote: >>>>>>>>>> >>>>>>>>>> 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 <https://github.com/edx/edx-platform/pull/12582>. 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 >>>>>>>>>> >>>>>>>>>> <https://github.com/open-craft/problem-builder/blob/master/problem_builder/instructor_tool.py>). >>>>>>>>>> This is related to other thread on mailing list >>>>>>>>>> <https://groups.google.com/forum/#!topic/edx-code/Zd2sKQaMhHI> - >>>>>>>>>> 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 <http://opencraft.com/> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>>>> <https://groups.google.com/d/msgid/edx-code/ad852782-b1e2-46ba-85bc-8d93db72048a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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/CFAAC85C-CE8E-4A56-819C-F1610A0C730A%40gmail.com >>>>>>>>>> <https://groups.google.com/d/msgid/edx-code/CFAAC85C-CE8E-4A56-819C-F1610A0C730A%40gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> [image: Cristian Salamea on about.me] >>>>>>>>> >>>>>>>>> Cristian Salamea >>>>>>>>> about.me/ovnicraft >>>>>>>>> <http://about.me/ovnicraft> >>>>>>>>> >>>>>>>> -- >>>>>>>> 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/70e847c6-b42e-470f-8ea2-9ffba6d81e2f%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/edx-code/70e847c6-b42e-470f-8ea2-9ffba6d81e2f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> >>>>>>> -- >>>>>> 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/4dd69f54-5ead-45ea-bf29-3b7ffce6be64%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/edx-code/4dd69f54-5ead-45ea-bf29-3b7ffce6be64%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>>>> -- >>>> 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/e68f5731-3dfd-43c6-a15f-a08babc0d51f%40googlegroups.com >>>> <https://groups.google.com/d/msgid/edx-code/e68f5731-3dfd-43c6-a15f-a08babc0d51f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> >>> -- >>> >>> *Andy Armstrong* >>> >>> edX | UI Architect | [email protected] >>> >>> 141 Portland Street, 9th floor >>> >>> Cambridge, MA 02139 >>> http://www.edx.org <http://www.edxonline.org/> >>> >>> [image: >>> http://www.e-learn.nl/media/blogs/e-learn/edX_Logo_Col_RGB_FINAL.jpg?mtime=1336074566] >>> >> -- >> 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/5363559a-5780-419b-9b68-3a94c6f7c7a5%40googlegroups.com >> <https://groups.google.com/d/msgid/edx-code/5363559a-5780-419b-9b68-3a94c6f7c7a5%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > > -- > > *Andy Armstrong* > > edX | UI Architect | [email protected] > > 141 Portland Street, 9th floor > > Cambridge, MA 02139 > http://www.edx.org <http://www.edxonline.org/> > > [image: > http://www.e-learn.nl/media/blogs/e-learn/edX_Logo_Col_RGB_FINAL.jpg?mtime=1336074566] > > -- > 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/CAG2ZmnAMohtNiX-G9iN7YuMaWJJVt1d%2BDdvHFBaouhDLVSvuZw%40mail.gmail.com > <https://groups.google.com/d/msgid/edx-code/CAG2ZmnAMohtNiX-G9iN7YuMaWJJVt1d%2BDdvHFBaouhDLVSvuZw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEyJbEa5tTT-pHj4xAbWxADid7i5iZm02LXqQ%3DJKupjnFu47vA%40mail.gmail.com.
