Course presentation: More robust summary page architecture

Submitted by juho.jaakkola on Wed, 08/30/2017 - 13:05
juho.jaakkola's picture
Forums: 
Feature requests

There have been several questions and feature requests for the summary slide of the Course presentation content type.

The questions are basically asking how to either:

  • Hide something from the slide
  • Add something new to the slide
  • Change how the existing features work


Here are some examples:

Most people ask for a setting for hiding/showing the features. Altering the slide through settings will however easily result in a feature creep and a bloated setting page.

My own initial though would to achieve the goals by refactoring the summary slide to be pluggable. That way content and behavior could be altered by installing/removing libraries. Someone wanting to get rid of the "Share to Twitter" button could simply remove the library that adds it.

There may of course be a need to enable individual features only to specific contents, so some content specific settings would still need to exists. A wild (?) idea is that perhaps the contents of the summary slide could be put together using similar tools that are being used also on the other slides. However instead of adding "Fill in the blanks" , "Drag & Drop", etc, the content admin could choose elements like "Share to Twitter", "Total result percantage" , "Slide specific results", "Try again button" and some of the editor's default ones "Text", "Link", etc.

I'm not yet familiar with the architecture of the summary page, so at this point I'm just gathering a list of known feature requests and throwing in some ideas. It would be great to hear some thoughs of what would be needed to achieve the goal, and what are the easiest ways to approach the problem.

Content types: 
Course Presentation
0
0
Supporter votes Members of the Supporter Network can vote for feature requests. When the supporter network has generated sufficient funding for the top voted feature request it will normally be implemented and released. More about the H5P Supporter Network
fnoks's picture

fnoks

Thu, 08/31/2017 - 09:37

Hi,

Thank you for your great thoughts :)

The pluggable architecture you are talking about here, is what we call add-ons in our roadmap. There is no specification for this yet - it is currently on the conceptual level.

Before specifying this feature, I think we should have a long list of user stories / examples. Then we will be capable of making something that will fit in many contexts.

Best,
Pål

 

juho.jaakkola's picture

juho.jaakkola

Thu, 08/31/2017 - 09:41

Shall I gather the use cases to this thread, or would Github issue be a better place?

falcon's picture

falcon

Thu, 08/31/2017 - 12:30

Maybe a new forum thread would be good, and then we could use it to create Jira issues later.

From the start we've been planning to add two concepts to the architecture:

  1. Contracts - so instead of a content type listing all the content types, it supports it just lists one or more contracts. Quiz may for instance list that it supports all libraries that implement the "H5P.Question 1.0" contract. The summary page may list that it supports all "H5P.CoursePresentationSummaryItem 1.0" items.
  2. AddOns - instead of a library defining that it supports other libraries, other libraries may choose to add itself to a list of libraries. These may be themes, it may be a rendering engine like MathJax or may also be plugins altering specific parts of a library, for instance, the summary page. Some of them will use APIs provided by for instance CoursePresentation. APIs may be xAPI events, resize events, DOM change events or custom events.

There will be overlap between AddOns and other libraries, but I think typically if you want the author to be able to turn on and off things perhaps contracts or existing concepts is better. If you want site wide changes then add-ons may be better. There will be a UI for toggling add-ons as well, but perhaps not available for anyone. There are still many details to be sorted out and everything is subject to change, so getting as many user stories/scenarios as possible when planning the implementation will be incredibly useful.