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 <http://opencraft.com> On Thursday, June 30, 2016 at 8:11:50 AM UTC+3, Braden MacDonald wrote: > > 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 <http://opencraft.com/> > > On Wed, Jun 29, 2016 at 2:36 AM, <[email protected] <javascript:>> > wrote: > >> 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 <http://opencraft.com> >> >> P.S. previous message is from me too - I accidentally posted it from my >> personal email >> >> >> On Wednesday, June 29, 2016 at 11:53:05 AM UTC+3, Колпаков Евгений 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/ff1916be-7f37-4e5a-ab56-c39d89d661ba%40googlegroups.com >> >> <https://groups.google.com/d/msgid/edx-code/ff1916be-7f37-4e5a-ab56-c39d89d661ba%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/b5b5952a-5899-492f-b676-c9a7743157a0%40googlegroups.com.
