Refactor course model: move sections to collection

[brylie]

From @brylie on March 23, 2015 7:25

Sections in courses were designed poorly, in code. They are currently stored in the lesson object as an array or arrays:

course = {
  sections = [
    [ 'lessonId', 'lessonId' ],
    [ 'lessonId', 'lessonId' ]
  ];
};

Task

Refactor lessons to be stored in their own collection.

Copied from original issue: Crowducate/crowducate-next#97

[brylie]

From @Rahbaran on March 23, 2015 8:42

Maybe I misunderstand this issue but I'm not sure if this is a good idea. Any learning platform has a kind of section (e.g. called 'stage' at treehouse, 'level' at codeschool or 'section' at udemy) to structure the courses. This is also helpful for gamification purposes as it gives the user a milestone resting point.

[brylie]

I can see the benefit of resting point, e.g. Khan Academy also breaks long courses into sections.

Are we assuming that long courses are default? What about "Microlearning" courses?

I believe we should remove the current 'sections' model for two main reasons:

• User experience feedback
• Code maintenance / simplification

User experince

We received puzzled looks and a bit of friction when users initially added a section after creating a new course. They seemed to expect to add lesson content at that point, but had to re-orient themselves to the notion of 'course section' (1, 2)

Code simplification

The current 'section' code is a bit 'half-baked'. Admittedly I am new to programming, so I implemented a course model that treats courses and lessons as first class objects (having their own collections). For course sections, I opted to store an array of arrays. Each section is an array of course IDs, so that we could do a 'relational' query.

This is not optimal, and may lead to difficulties if/when we decide to implement features such as drag-and-drop sorting. It also leads to complexity when considering how to do cascading deletion of content with sections, etc.

For simplicity sake, I really think removing the current sections would be beneficial.

Some possible solutions

• Treat sections as first class objects
  • Give them their own collection
• Remove sections for now
  • Consider how to replace them when we explore the learning components model further
• Keep sections as they are
  • Figure out how the array of arrays will impact code maintainability
  • Consider how drag-and-drop reordering will work
  • Consider how to provide in-context signifiers so users understand what to expect

Additional perspective

I am also intuitively drawn to simplify the system based on experiences with Moodle and Joomla!.

Joomla!, prior to 2.5 if I recall, had two levels of classification for each Article: Categories and Sections. To create an article, you first had to create a section, then create a category, then create your article (or something to that effect). They seem to have subsequently resolved that.

Moodle has a 'sections' course format. A creator must specify the number of sections they want for the course in advance, then populate the sections with learning resources. To change the number of sections, the user must navigate to an administrative section and change the number, then go back to managing content.

[brylie]

From @Rahbaran on March 23, 2015 22:20

How big is the sample of the user research? I’m asking because omitting levels/sections/steps (or whatever you call it) is a very atypical move as all the major players in the academic (edX, coursera, iVersity) and skill based (codecademy, duolingo, code.org, udemy) divide the content into groups. So, we really need some good data.

reg. Code simplification:
maybe the images help. the old repo also uses separate collections for sections.

Here illustrated with RoboMongo.

I think courses.coffee and sections.coffee might also help form the old repo. Or maybe this link?

https://github.com/Crowducate/crowducate-platform/issues/20

Maybe some inspiration from Udemy can help (still WIP, I'll finish it tomorrow) https://crowducate.hackpad.com/Open-Education-audit-97TwvJ5ARPs#:h=Udemy

[brylie]

This refactoring might make issue #90 easier, as it is currently blocked by related difficulties. Specifically, course sections are currently stored inside of the course object, so it becomes necessary to use ´Template.parentData´ when saving new sections to the course object from sub-templates.