Creation of Self Assessment from Workspace

Problem Statement:

Currently, an Assessment is created as a two-step process and most of the activities are done in the back end. Content is created with type as "Resource" which is reviewed and published and later the content type is changed to "Self-Assess” and made available to the user. Instead, the whole creation and publishing process should happen from the portal 

Solution 1:

Handling on editor side(adding summary slide into content)

Whenever the content editor will create content as self-assessment content, we will extend the ECML with a new stage block which contains the summary plugin.

If content editor edits the same content we will hide the stage from the content editor and after saving we will add the stage again.

<stage w="100" x="0" h="100" y="0" id="3a52e8ee-349c-49de-b5da-a6a47b268218">
        <config>
            <![CDATA[{"opacity":100,"strokeWidth":1,"stroke":"rgba(255, 255, 255, 0)","autoplay":false,"visible":true,"color":"#FFFFFF","genieControls":false,"instructions":""}]]>
        </config>
        <param name="previous" value="59e8bd17-86ad-4043-b340-18c9d9862a5c"></param>
        <org.ekstep.summary rotate="0" z-index="0" w="77.45" x="4.61" h="125.53" y="-29.38" id="45ecdc54-ce1d-48cd-a5a4-808c03ee12e2">
            <config>
                <![CDATA[{"opacity":100,"strokeWidth":1,"stroke":"rgba(255, 255, 255, 0)","autoplay":false,"visible":true}]]>
            </config>
        </org.ekstep.summary>
        <manifest>
            <media assetId="summaryImage"></media>
        </manifest>
  </stage>

Pros:

• This will take less development time and no other changes in the existing flow.

Cons:

• For new content types we are adding forcefully adding new stage programmatically, what if some other content types introduce in the future.

Solution 2:

Handling on consumption side as a end-page plugin(mergeing summary plugin & endpage)

we can club the summary and end page plugin which will behave as an assessment end page plugin. Based on the config received by the player we will switch the end page.

Pros:

• We do not need to change content editor code for a new content type, just a plugin change will suffice this requirement.

Cons:

• We will be handling two endpage plugins based on the different type of content type [ not a cons though ]