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:
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.
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.
Discussions 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:
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.
Any customisation required to be done on top of the underlying tool (like discourse) can be implemented in the API layer.
Discussions Plugin
The main idea of plugins is to allow new functionality to be built independently of the core development. Plugins can be installed into a Sunbird instance and run as part of the core application. This enables an ecosystem of developers to develop & contribute plugins to sunbird market place (similar to wordpress marketplace). And thereby providing the agency to users to create a variety of learning experiences.
A Plugin can be composed of both server and client functionalities. Server side of a plugin can be treated as a micro-service. And on the client side, a plugin will have UI components that can be dynamically launched (with a config) by the core components (e.g groups UI component) in the client apps like portal & mobile app. Such plugins can be easily integrated and provides greater flexibility. A plugin may have only a server side component or only a client side component or both depending on the purpose for which the plugin is developed. In case of client only plugin, the plugin may use one or more of sunbird core micro-services (users, courses, etc).
Discussions plugin can be built as a client side plugin and uses APIs provided by discussions service and other services.
Configuration
Plugin configuration should provide enough options for users to configure different types of discussions within their groups. Examples of configurations are:
Allow moderated or un-moderated discussions
List of users who can play a moderator role, if moderated discussions are enabled
Enable replies on comments, enable Q&A mode, etc.
Discussions plugin will be configured differently by each group and the group component provides the group specific configuration to the plugin while launching the plugin within a group. The plugin should interpret the config to invoke the discussions service APIs appropriate for the config.
Additionally, the plugin can expose a set of configuration templates that have pre-defined configurations. This makes it easier for users to use discussions plugin by selecting a template.
UI Components
Discussions plugin should have its UI components (using Angular) which is also driven by the configuration. Different controls and actions within the UI should be enabled/disabled or act differently based on the configuration.
The UI components can be completely custom-built or embed the UI of the underlying tools (like discourse) if it is feasible, configurable (themes, actions, etc) and extensible.
Plugin Lifecycle
An important design problem for plugins is the life cycle of a plugin and the events/actions at each stage in the life cycle. We need to identify these stages and design the plugin implementation. Here are some of the life cycle events for discussions plugin (not final, just as inputs for the design):
Init: when the plugin is added to a group: At this stage, plugin may need to create required entities in discussions service (like forum, groups, users, etc) and store those details as part of the plugin configuration.
Start: when the plugin is launched within a group: Plugin uses the config to fetch the relevant data from discussions service and render the UI components.
Stop: when the plugin is closed: Do any required clean up activities.
Update: when the plugin config is updated: update the related data in discussions service.
Destroy: when the group is closed or plugin is removed: clean up/archive the related data in discussions service.