Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Introduction

Students have long been used to discussions in a brick-and-mortar classroom. Even if a formal discussion doesn't occur, there is always a bit of informal time with their teacher and classmates to discuss and gauge their understanding of the class material. Understandably, discussions have to be an integral part of digital learning and enable flexible & independent learning and knowledge construction.

There are multiple applications for discussions in a digital learning context, such as: discussions specific to certain topics, content, courses, or discussions that happen on an event like an exam, seminar, etc, or scheduled discussions where an expert is available for a specific duration. Discussions in sunbird platform should be generic and extensible to model & create different types of discussions.

Enabling discussions via Groups

The “discussions” micro-service should expose APIs that can be used to build different types of discussions experiences. For example, it should be possible to link a discussion to course batch where all users enrolled to the batch become participants of the discussion. Similarly, it should be possible to create a subject wise discussion forum at a platform level that runs forever and all users on the platform have access to this forum.

As the first use case of discussions, we want to enable the capability of attaching the “discussions” to a “group” of users and allowing all users of the group to participate in the discussion.

Groups

There are problems such as lack of learners’ focus and inadequate reflection in a digital learning environment. Good quality learning content alone is not enough for an effective digital learning experience. There is a need for multiple learning tools that should be available for learners, teachers, parents & other users for creating effective nudges and enabling effective learning. Examples of such tools are:

  • Progress Report: which can be used by teachers, parents or tutors to see how the learners are progressing in a course and create a course correction based on the learners' progress.

  • Quiz: to conduct a quiz for a set of learners to test their understanding, help them revise or for practice purposes

  • Leaderboard: a tool that helps learners to see where they stand with respect to their peers

  • Discussions: to enable collaboration between learners, teachers, tutors or any group of users

Such learning tools will be enabled via “groups” in Sunbird platform. The premise for “groups” and enabling learning tools via groups is that anyone should be able to assist any learner in learning, i.e. teachers, tuition teachers, parents, siblings, peers, senior class students, mentors or any one who is capable should be able to help any learner.

To achieve this, any user in Sunbird will be able to create a group and add users to the group (though with the acceptance of the user). Based on the needs of users in the group, the group creator can pick and add one or more learning tools to the group.

Design Thoughts

As mentioned above, learning tools should be built like plugins that can be added to a group for enabling a certain capability for the group users.

A plugin should be configurable while adding to the group and the plugin configuration for a group should be stored as part of the group data. Each plugin can use one or more sunbird micro-services or external services.

Thus, there are primarily two components to be designed and developed for enabling discussions in Sunbird:

  1. Discussions Service: A generic micro-service that can be used to model different types of discussions. This service should expose APIs that will be used by the discussions plugin. And this service should not have an understanding of the groups or how the plugin is implemented.

  2. Discussions Plugin: This plugin should expose a configuration that can be configured while adding to a group, have a user interface that is embeddable within groups UI and use the configuration to render the discussions for a group.

Discussion Service

As mentioned above, this service should be built in a generic way and expose APIs that enables different types of discussions. A few thoughts (random and not in any specific order) that need to be considered for designing the discussions service:

  • There are various dimensions to discussions: its Character, Category, Content, Community, Purpose, Usage, Lifecycle, Administration, Supportability

  • Discussions can be a question, feedback, comment, dialogue (lengthy, threaded interaction between 2 or more parties), forum

  • Discussions can be marked public, or between groups, or by invitation only

  • Depending on whether it is a question, feedback, comment etc., its association with content, community, usage, experience, lifetime and administration can be different.

  • Discussions can be at a Platform Level (general questions about usage, enrolment, feedback, complaints, issues etc..) or at a course level or across courses

  • Discussions Initiated by - Student, Faculty, Tutors, automatically initiated…

  • There could be discussion forums which are time bound like forums for courses which are started at the beginning and are over (archived) at the end of the course or open forever like platform level general forums

  • Discussions that are specific kinds - discussions that happen on an event - for example, end of the module (review) discussions or a quiz.

  • There could be forums specific to certain topics - assignments, submissions, clarifications, supplementary content, general help etc.

  • Specific Forums that are scheduled discussions  - scheduled say every Saturday and ends on Monday where all questions are guaranteed to be answered. Or between Tutor and Student groups where all questions have to be answered and monitored. Or Faculty appearance Forums/Discussions where the Faculty come be online for 2 hours every week - what kind of discussions are these?

  • Forums created for a set of students - student groups, for a very specific discussion/purpose - i.e. targeted discussions between a group of students.

  • Moderated and Unmoderated Forums

  • Actions on Discussion Items

  • Repost them, close them, delete them, link to it from somewhere else, promote it, best discussions, best question, best answer, Auto generate FAQs (can we associate a FAQ to content elements)

  • HashTags, Search on Tags, Search by Keywords etc. 

  • Send a discussion item to somewhere else. For example, link a discussion to some other course, if it is relevant

  • Administration: Monitor the Discussions, Participation, Turn Around Times (if the tutor has to respond to something with in certain time, how does this get monitored and ensured?)

  • Administration: Detection of spurious, frivolous, obscene, unacceptable content.

  • Administration: Dealing with emotions, language used, arguments et

  • There can be lot of problems - content relevancy - how to purge trivial stuff, how to archive/promote good stuff, convert a discussion into a learning content?

  • how does this service identify users that are part of sunbird platform? do we need SSO or integrate with user service/keycloak for verifying the user?

  • how to backup, archive your own discussions, email to self, share with others, etc..

  • Life time, time duration of a discussions and forums

  • Given so many dimensions - how do we distinguish them, characterise them (categorisation, content length, time, etc). for example what is the behaviour of Moderated and Unmoderated forums other than assign some moderators?

Another design recommendation is that Sunbird discussions service should have its own API interface definition, even if an existing tool like discourse or nodeBB is used for the implementation. This is mainly for two reasons:

  1. The underlying implementation can be changed from one tool to another or to a custom implementation without impacting the plugins and apps using this service.

  2. Any customisation required to be done on top of the underlying tool (like discourse) can be implemented in the API layer.

Discussion Plugin

  • No labels