Mark
Initial code review - General Questions
by Mark Lynch - Tuesday, 3 September 2013, 9:17 AM
 
  1. Do we have the ability to remove some of the course navigation structure, could we remove all levels and go straight into the page - essentially no navigation?
  2. What is the process behind creating our own custom components, could we reuse some of the attributes of other components?
  3. What is the process behind publishing a course? We noticed that there is a template.js in the menu folder this seems to override/compile the handlebars files
  4. Are we missing some files in /src - the grunt file has references to js files in there?
  5. Was there a reason behind using non-standard html elements for checkboxes/buttons and so on?
  6. What does the "navigation" -  "settings" , search", "accessibility", "resource do? We could not seem to get it to do anything
  7. What does the guide section in the json do?
  8. Can you give us a guide/document to each of the properties, for e.g. what does dynamic in the text input do (most stuff is self-explanatory)?
  9. We could only see left/right and full as layout properties for components, could we place 3 components inside a block and expect them to get 33% of the width, in desktop mode?

(Edited by Admin User - original submission Tuesday, 3 September 2013, 9:03 AM)

me
Re: Initial code review - General Questions
by Sven Laux - Tuesday, 3 September 2013, 9:46 AM
 

Hi Mark,

thanks for your post and congratulations on the first ever post!

Daryl and Fabien will respond in more technical detail but I wanted to add the following thoughts on custom components in particular:

As we mentioned, one of the first things for us to do is to design and plug-in architecture. This will help lower the barrier to entry for developers in particular and we'd like to encourage everyone to build components (interactions), without necessarily having to know the complete Adapt codebase.

This means that whatever the structure of components is right now, it will almost certainly change and I'd be keen to hear your thoughts on how this could work best.

Ultimately, I would like components to be plug-ins, which could be added to the authoring tool on the touch of a button. Examples of this are the Ubuntu Synaptics package manager and the most recent changes to Moodle. 

This means that each component/interaction would consist of at least two parts: 

  • the data entry bit (i.e. the bit, which plugs into the CMS and tells it what data is required and how to capture this)
  • the output renderer (i.e. the part of the output framework, which takes the data and renders it as part of the e-learning package)

Further to this, I would like the package to contain metadata, e.g. the technical requirements such as which browsers the component works on, who maintains it, what the dependencies are etc.

There would be two types of interaction components:

  • Core Adapt Learning components (core meaning authoring front end + output framework), i.e. components which are shipped directly with the base install/package of adapt and maintained centrally. These would have to adhere to an agreed tech requirements spec e.g. in terms of browser capability etc.
  • Community components, i.e. components, which have been created by the developer community and are available as plug-ins to the core but not directly part of it. Much like with how the Moodle community works, these components may be integrated into the core over time or stay community plugins.

I hope this makes sense.