Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Easy to implement. A simple change on the content creation side(editor).

  • Any summary plugin fixes will reflect on the new/edit contents immediately. (without user concern)

Cons:

  • We are adding this plugin for every self-assess content. It will increase the size of the ECAR file.

  • Any fixes of the summary plugin requires plugin publish & will work only for new contentthe contents creating after plugin publish. Older contents need to edit & republish to get fixes of the summary plugin.

  • This is the core plugin changes(Stage plugin), any issues will have a huge impact on other contents as well.

  • If the user explicitly adding this plugin to the last stage, then he will see 2 stages with the summary plugin. Which he doesn’t have any info why it is showing twice.

  • We should know how many contents created with this plugin(using telemetry). So that any update of the plugin can be updated to all the contents.

Note:

Existing contents have to fix(remove the last slide). Else edit/copy of any existing will be having duplicate slides of the summary plugin.

Solution: Manually fix the content body(because of limited contents <10) or write patch script on editor to handle these contents.

Solution 2:

Handling on consumption side as an end-page plugin(merging summary plugin & end page)

...

  • For old content migration, we will have to remove the summary plugin from existing content [ Migration task size will be a function of total content ]

  • Any fixes of summary plugin will be available only in the updated version of the app. Because summary plugin is the core plugin of the content-player.

We can look for hardcode push option to push summary plugin changes directly wihtout app update.