<Proposed capability name. Should describe the capability in max 4 words. e.g. Creating Merit Certificates>
<Summarize the capability by answering the questions ‘Why are you developing the said capability?’ i.e. what problem is the capability trying to resolve, and ‘What is your proposed solution?’>
<Sample text:
States and organizations feel the need to motivate and recognize deserving learners.
To address this need, States/organizations can issue Merit certificates from DIKSHA. However, since the criteria for merit cannot be standard, we propose to make the merit criteria (rules) configurable. The parameters that States/organizations can set are:
...
who will get the certificate (all users or select few),
...
when (on completion of assessment or based on a score, or both)
...
Groups & DF >>Notifications - To notify users on important Groups and DF actions
Users should be notified on important group actions so that they can be on top of it and also manage it effectively (through in-app notification). These notifications will be triggered by certain contextual triggers - for eg. when a user has been added to a group or when an activity is assigned to the group. This will use the new notification service that is built in a generalized manner that can be integrated in any context (Groups, DF, events etc.,). This will also replace the existing notification service that is used for certificate (while ensuring the workflows are retained as it is)
Groups>>To build Groups as an NPM module
Currently Groups is part of the over all consumption experience and cannot exist on it own. For example, if an adopter wants to use Groups feature, the entire Portal needs to be integrated or if they do not want to use Groups, it is not possible as this is part of SB’s default features. Once this is externalized or made as an NPM module and plugged in any context/use case like learning cohorts, Vidyadaan
DF>>User’s context to be carried forward (on refresh, user experience should be retained)
When a user refreshes a page, ideally s/he should be retained in the same page. However currently when a user refreshes from any one of the DF related pages, the context is lost and the user is taken to portal home page or some other page which is not related to DF. The design review for the solution was completed in 4.3.0 and the actual implementation will be done in 4.4.0
DF>>Functional monitoring and alerts
It is crucial to monitor all the key functional flows in DF (courses & Groups context) so that issues in production can be identified upfront before the customer reports and pro actively resolve them. This will be done by the operations team who will monitor all the key flows via alerts and report back to the respective team who can address the issue. This becomes mandatory especially, to support and maintain the system at scale. As part of this, the below will be implemented:
Logging of key functional flows/user actions to be monitored
Dashboards to monitor issues in production
Alerts to be triggered for key events/user actions
Chatbot>> To enable portal workflows via UCI Architecture
Currently the portal chatbot is global where users across all states see the same workflows (though they see the relevant state’s content). However going forward, there will be one global workflow for all the states + default state workflows + state specific workflows. States can create/customize their own workflows via admin console and enable it on both portal and whatsapp in addition to global and default workflows. Note: This capability for whatsapp will be productionized in 4.4.0.