<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 >>To ensure Groups and DF is accessible compliant on both portal and mobile app
Every potential user including people with disabilities should have a decent user experience and be able to easily access Groups and DF on portal and mobile app. The accessibility feature aims at ensuring the following:
Compliance to https://www.w3.org/WAI/standards-guidelines/ and GIGW guidelines from an accessibility point of view.
Ensuring the apps allow navigation using assisted devices
Ensuring content can be played using assisted devices & tools
Note: Groups accessibility compliance on portal was completed in 4.3.0 and the remaining is being done in 4.4.0
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>>Tech item-To ensure APIs are secure from being misused
All DF API’s should be secure enough so that it can be misused/hacked using any API tools. For example, a user who is not related to the course in any way, can participate in the discussion without enrolling into the batch. Also, a user who is not part of a group can participate in the discussions without the adding adding him/her to the group. There are various such scenarios in which the misuse can happen and that needs to be prevented
DF >>Tech item-Liveness & readiness probes on DF service pods to support scale
With DF turned on for all tenants, there are 4 active pods now serving the requests. However when one pod is 70% utilized, the request goes to the fifth pod that is getting ready. Before the new pod is fully ready, the requests are currently being sent to this new pod which results in users getting error messages (502 error). To avoid this, Health check APIs needs to be implemented that will verify if the pod is ready or not to serve - if its ready, the requests goes to the new pod, else the requests are sent to the existing pods, there by avoiding the errors.
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