Closed brylie closed 9 years ago
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.
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:
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)
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.
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.
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
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.
This issue was moved to Crowducate/crowducate-platform#93
Sections in courses were designed poorly, in code. They are currently stored in the lesson object as an array or arrays:
Task
Refactor lessons to be stored in their own collection.